在表中存储日语字符

hud*_*hud 7 sql-server collation unicode

我正在使用 SQL Server 2008 R2 并且我想将日语字符存储在我的表的列之一中。

说我想存储日语名字,我怎样才能做到这一点?有没有简单的方法?

Sol*_*zky 13

您需要使用NCHAR(1 - 4000)NVARCHAR,作为NVARCHAR(1 - 4000)NVARCHAR(MAX)用于存储从 4001 到刚好超过 1,073,741,822 个字符的任何位置(如果存储如下所述的任何补充字符,则可能更少)。

从技术上讲,如果您使用与代码页 932 相关联的排序规则,您可以VARCHAR字段中存储日语字符Japanese_*。但是,这被认为是“传统”方法,仍然会给您带来一些问题。处理此问题的适当方法是使用上面提到的 Unicode 数据类型。有关 的详细信息,请参阅最后的更新部分VARCHAR

您还需要指定日语排序规则,以便数据按预期进行比较和排序。您可以使用以下方法找到可用的日语排序规则:

SELECT * FROM fn_helpcollations() WHERE name LIKE N'Japanese%';
Run Code Online (Sandbox Code Playgroud)

并且您在字段规范中使用该值,例如:

CREATE TABLE dbo.test
(
  JapaneseText NVARCHAR(3000) COLLATE Japanese_CI_AS_KS_WS
);
Run Code Online (Sandbox Code Playgroud)

请参阅MSDN页面的下面部分以获得更多信息使用整理和什么每个的CI/ CSAS/ AIKSWS平均值,以及BIN/BIN2SC(上面没有显示):整理

根据您需要存储的字符,您可能需要密切注意以SC(即“补充字符”)结尾的排序规则。默认情况下,NCHAR/NVARCHAR数据存储为UCS-2,这与 非常相似UTF-16,但UCS-2始终为每个字符 2 个字节。另一方面,UTF-16为了支持超过 65,536 个字符(最大大小为 2 个字节,或UInt16.MaxValue+ 1)可以存储 4 个字节的字符(称为“代理对”)。有关更多详细信息,请参阅以下 MSDN 页面上的排序规则和 Unicode 支持(“补充字符”部分)


万万不能使用NTEXT。自 SQL Server 2005 出现以来,这已被弃用!使用它没有任何好处/理由,事实上,它有几个缺点。


更新

虽然不理想,但可以在CHAR/VARCHAR字段和变量中存储日语字符。这样做需要将数据库的默认排序规则设置为与代码页 932 (Shift-JIS) 关联的排序规则。您可以通过运行以下查询找到该排序规则列表:

SELECT * FROM fn_helpcollations() WHERE name LIKE N'Japanese%';
Run Code Online (Sandbox Code Playgroud)

我通过使用该列表中的条目创建数据库并运行以下语句进行了简单测试:

CREATE TABLE dbo.test
(
  JapaneseText NVARCHAR(3000) COLLATE Japanese_CI_AS_KS_WS
);
Run Code Online (Sandbox Code Playgroud)

这是有效的,因为代码页 932 是双字节字符集 (DBCS),它不同于也是双字节的 UCS-2 / UTF-16。DBCS 字符集是 8 位编码中的双字节字符集(如扩展 ASCII 代码页)。您可以在最后一个查询看到DATALENGTH的是字符两次LENGTH数据是在一个VARCHAR类型,因为没有N对字符串文字前缀和CONVERTVARCHAR,没有NVARCHAR。Windows / SQL Server 支持 4 个 DBCS 代码页:

  • 932 = 日语(Shift-JIS)
  • 936 = 简体中文 (GB2312)
  • 949 = 韩文
  • 950 = 中国繁体 (Big5)

仅在您绝对需要时才使用这些,例如支持与遗留系统的交互。当然,排序规则仍然可以使用,但将数据存储在NVARCHAR而不是VARCHAR.