PostgreSQL与SQL Server NVARCHAR的等价物是什么？

如果我在Microsoft SQL Server数据库中有NVARCHAR（或NTEXT）数据类型的字段，那么PostgreSQL数据库中的等效数据类型是什么？

我非常确定postgres varchar与Oracle/Sybase/MSSQL NVARCHAR相同，尽管手册中没有明确说明：

编码转换函数如下所示：

例如：

create table
nvctest (
utf8fld varchar(12)
);
insert into nvctest
select convert('PostgreSQL' using ascii_to_utf_8);
select * from nvctest;

此外，Postgresql代表还提出了一个类似的问题：

我们所有的文本数据类型都是 支持多字节，前提是 已正确安装PostgreSQL。
这包括：文本（推荐） 瓦查尔

---

它是varchar和text，假设您的数据库采用UNICODE编码。如果您的数据库采用非UNICODE编码，则没有特殊的数据类型可以为您提供UNICODE字符串-您可以将其存储为bytea流，但它不会是字符串。

标准文本数据类型非常适合它。

简短回答：没有与SQL Server NVARCHAR等效的PostgreSQL

不同数据库上的NVARCHAR（N）的类型不同。 该标准允许广泛选择字符排序规则和编码/字符集。在处理unicode时，PostgreSQL和SQLServer属于不同的阵营，不存在等价性

这些不同于w.r.t

长度语义

代表性内容

排序顺序

填充语义

因此，将数据从一个DB系统（或编码/字符集）移动到另一个DB系统可能会导致截断/内容丢失

具体来说，PostgreSQL（9.1）字符类型和SQL Server NVARCHAR之间没有等价物

您可以将数据迁移到PostgreSQL二进制类型，但会失去文本查询功能

（除非PostgreSQL开始支持基于UTF-16的unicode字符集）

1） 长度语义 根据数据库和编码，N的解释不同（字符、字节，2*N=字节）

Microsoft SQL Server使用UCS2编码，VARCHAR长度解释为UCS-2点，即长度*2=字节长度（）：
他们的NVARCHAR（1）可以存储1个UCS2字符（2个字节的UCS2）。 Oracle UTF编码具有相同的语义（以及内部CESU-8存储）

Postgres9.1只有一个Unicode UTF-8字符集（），类似于 Oracle（采用AL32UTF8或AL16UTF16编码）可以存储1个完整的UCS32代码点。可能高达4个字节（参见 其中明确说明nvarhar2（50）列可能最多占用200字节）

当处理基本多语言平面之外的字符时，差异变得显著，这些字符在utf8 ucs32（go、char、char32_t、PostgreSQL）中被视为一个“字符单元”，但在UTF-16中被表示为两个单元的代理项对（Java、Javascript、C#、ABAP、wchar_t、SQLServer）

e、 g。 U+1F60A带微笑眼睛的笑脸将耗尽SQL Server NVARCHAR（2）中的所有空间。 但在PostgreSQL中只有一个字符单元

经典的企业级DBs将提供至少一个类似UTF-16语义的选择（SAP HANA（CESU-8）、带排序规则的DB 2、SQL Anywhere（CESU8BIN），…） 例如，Oracle还提供了他们误导性地称之为UTF-8排序规则的内容，实际上是CESU-8。 这与UTF-16（=Microsoft SQL Server）具有相同的长度语义和可表示的内容，是基于UTF-16的企业系统（如SAP R/3）或Java应用服务器下使用的合适排序规则

注意，一些数据库可能仍然将NVARCHAR（N）解释为字节长度限制，即使使用可变长度的unicode编码（例如SAP IQ）

2） 不可呈现的内容 基于UTF-16/CESU-8的系统可以表示半代理项对，而 基于UTF-8/UTF-32的系统不能。 此内容在此字符集中不可表示，但在基于UTF-16的企业系统中经常出现。 （例如，Windows路径名可能包含此类非utf-8可表示字符，请参见例如）。 因此，UTF-16是UTF-8/UTF-16的“超集”，在处理基于这种编码（SAP、Windows、Java、JavaScript）的企业/操作系统数据时，UTF-16通常是一个杀手级标准。注意，Javascript JSON编码特别注意能够表示这些字符（）

（2） 和（3）在迁移查询时更相关，但不适用于数据迁移

3） 二进制排序顺序： 请注意，CESU-8/UTF-16的二进制排序顺序不同于UTF-8/UTF-32

UTF-16/CESU-8/Java/JavaScript/ABAP排序顺序：

U+0041  LATIN CAPITAL LETTER A
U+1F60A SMILING FACE WITH SMILING EYES
U+FB03  LATIN SMALL LIGATURE ffi 

U+0041  LATIN CAPITAL LETTER A
U+FB03  LATIN SMALL LIGATURE ffi 
U+1F60A SMILING FACE WITH SMILING EYES

UTF-8/UCS-32（go）分拣顺序：

U+0041  LATIN CAPITAL LETTER A
U+1F60A SMILING FACE WITH SMILING EYES
U+FB03  LATIN SMALL LIGATURE ffi 

U+0041  LATIN CAPITAL LETTER A
U+FB03  LATIN SMALL LIGATURE ffi 
U+1F60A SMILING FACE WITH SMILING EYES

4） 填充语义

---

填充语义在数据库上有所不同，尤其是在比较VARCHAR和CHAR内容时

请不要假设每个人都知道MS SQL中的“NVARCHAR/NTEXT”是什么。如果你想得到真实的信息，你必须提供更多的信息，这个数据类型是什么。我个人不知道这个数据类型是什么，它可以存储什么（我猜是文本），它的限制是什么，等等。@depsz-对不起，它们是Unicode字符串。有关定义，请参阅。此答案是错误的。请尝试使用例如o=JSON.parse（“{”a:“\\uD83D”，“b:“\\uDE01”}”）；o、 浏览器控制台中的a+o.b。然后尝试将单独的属性o.a和o.b存储到postgres TEXT/VARCHAR和SQLServer NVARCHAR中。检索它们（或在数据库中连接它们）并检查结果。支持多字节并不意味着能够存储半代理项对，因为Postgres只提供UTF-8字符集。请参阅下面的长篇文章。