使用Japanese_Unicode_CI_AS的VARCHAR列中的日语字符

Question

我正在加载一个表，其中包含CSV文件中的日文名称，这些名称正在转换为问号为SQL。存储这些值的表是一个varchar列。我知道varchar列不是Unicode，这就是它将一些字符更改为??的原因。

然而，为什么用日语编写的现有值存储在varchar中，而理想情况下它应该在nvarchar中呢？

有办法将nvarchcar转换为varchar吗？

数据库超出了我们的控制范围，我们无法更改架构。

Answer 1

作为提博尔，Japanese_Unicode_CI_AS排序规则(实际上是所有Japanese_*排序规则)可以将日语字符存储在VARCHAR列中，因为Windows代码页932是一个双字节字符集(DBCS)。我相信有7800个日本字符映射到Windows932代码页。然而，Unicode包含超过7800个日语字符。

为了缩小问题范围，了解一些事情是非常有帮助的(甚至是必要的)：

1. 您是如何导入CSV文件的。您使用的是BCP还是BULK INSERT / OPENROWSET(BULK...)？
2. 正在转换为??的至少一个日文名称的示例
3. 您说“CSV文件中的日文名称正在更改为问号”和“它正在将一些字符更改为??"，因此：
   1. 所有的日本字都变成问号了，还是只有一些呢？
   2. 日文是变成一个问号( ? )、两个问号( ?? )，还是每个问号都变成一个问号？

在不知道这些问题的答案的情况下，我可以说有两种主要的可能性：

1. (导入为?的所有日语字符)：您没有告诉导入工具CSV文件的编码是什么。它是否编码为Windows932(或者可能是Windows31J)？或者是Unicode编码，如UTF-8或UTF-16 (根据工具的不同，它们可能被列为"UCS-2“或"Unicode”)？如果您正在使用BCP，则需要使用用于Windows932的-c -C 932命令行选项或用于UTF-8的-c -C 65001命令行选项。通过将工具设置为使用正确的代码页，这个问题应该是可以解决的。
2. (一些以?或??形式导入的日文字符)：如果您告诉导入工具文件的正确编码，在Windows932代码页中仍有未编码的日文字符。例如：--删除表##BCP；创建表##BCP (价值 VARCHAR(50)整理Japanese_Unicode_CI_AS)；插入##BCP (价值)值(N‘ヤ：：㋾:：')；从##BCP选择*；返回:ヤ：？只有执行以下操作之一才能解决此问题：
   1. 将列的数据类型更改为NVARCHAR (虽然您说过不能更改架构)
   2. 更改列的排序规则以使用UTF-8排序规则(即以_UTF8结尾的排序规则名称；在Server 2019中引入)

有关使用排序规则/ Unicode /编码的信息，请访问：校对信息

Answer 2

在校勘和亚洲语言方面，我远不是专家。

但是我的猜测是，您有一个日文排序规则(例如Japanese_CI_AS)，并且由于您没有使用nvarchar/Unicode，所以您最终得到了一个双字节字符集(DBCS)。因此，您的varchar列中存在日语字符。

但是当您加载数据时，您的工具(无论您使用什么来加载数据)都没有在源和数据库中进行正确的转换--这就是您的问题所在。也就是说，您需要深入了解用于加载数据的任何工具的文档，并确保该工具能够正确读取和解释CSV文件，并正确地与SQL Server接口(考虑到您有一个varchar，可能是日语/DBCS排序规则)。

当然，“正确”的做法是去Unicode/nvarchar，但正如Paul在一条评论中提到的那样，我假设您的意思是“不能”，在您说"can“的地方。

此外，我在这里发现了所罗门关于这个主题的一个很好的说明：将日语字符存储在表中

Answer 3

您是如何加载数据的？它是进入数据库中的现有表，还是创建一个新表？

如果它是一个已经定义为VARCHAR列的现有表，那么如果您无法更改模式，那么您就无能为力了。

如果每次加载数据时都要创建一个新表，那么这将取决于导入数据的方式。例如，如果您使用的是数据库导入向导或平面文件导入向导，则都可以提供一个步骤，您可以手动调整列的数据类型，并且应该能够为该列选择NVARCHAR。

如果您正在编写导入脚本，那么它将取决于您的SQL脚本，但您也应该能够将列数据类型指定为NVARCHAR。