SQL Server是否以某种方式强制执行或控制VARCHAR
列的编码?我浏览过的文档没有明确区分排序规则(排序和比较规则)和编码(给定字符的字节表示)。
我有一个SQL Server实例,其中所有内容都是Modern_Spanish_CI_AS
(包括数据库,表和列),我的印象是Windows-1252
。数据库也由使用Windows-1252的应用程序填充。最近,使用UTF-8的配置错误的应用程序已经写了一段时间的数据,令我惊讶的是,SQL Server很高兴接受完整的Unicode目录,不仅如此,我尝试过的其他客户端似乎正确地读回数据无论表格属于哪种应用程序。
当我转向十六进制时:
SELECT foo, CAST(foo AS VARBINARY(MAX)) AS hex
FROM ...;
...我看到不同的编码取决于表所属的应用程序:
第一个应用:
€Á 0x80C1
第二个应用:
€Á 0xAC20C100
...但原始字符显示正确。
SQL客户端如何知道源编码?
修改:如果两个应用都写入同一个表格,我会发现:
€Á 0x80C1
ۈ 0xE282ACC381
答案 0 :(得分:0)
这只是一个猜测,但似乎我的测试和各种文档浏览支持。除了特殊的二进制排序规则外,SQL Server只考虑两种类型的字符串数据:
预计旧版数据将在基础Windows系统配置使用的任何代码页中进行编码。 Unicode不是一个问题,因为字符库大部分是相同的。在任何一种情况下,客户端使用的驱动程序是负责转换的驱动程序(如果有的话),而通常的驱动程序配置只包含一些反映这一事实的选项(例如raw,ANSI,UTF-8)。由于这个原因,SQL Server没有设置或指令来选择其他DBMS所具有的字符集,您只需要选择通常含义的排序规则(排序和比较规则)。
关于如何区分两种可能的编码,这一切都取决于列类型:
CHAR
,VARCHAR
,TEXT
...暗示ANSI NCHAR
,NVARCHAR
,NTEXT
...暗示Unicode 如果您对给定的列类型使用了错误的编码,那么您只会像€Ã
一样垃圾。