SQL中文编码

管理 Unicode 服务器与非 Unicode 客户端之间的数据转换

社区内容

本节内容

统计批注 (0)

单击此处以展开

全部折叠

语言筛选器

: 全部

SQL Server 2005 联机丛书（2008 年11 月）

管理Unicode 服务器与非Unicode 客户端之间的数据转换

本主题介绍了当服务器端数据以Unicode 存储，而与数据交互的客户端应用程序使用的却是特殊代码页时，如何保持字符数据的完整性。

数据输入

当把客户端发送的非Unicode 数据以 Unicode 存储在服务器中时，如果具备下列条件之一，则来自任何客户端的任何代码页的数据都可以正确地存储。

?字符串作为远程过程调用(RPC) 的参数发送到服务器。

?字符串常量以大写字母N 开头。无论客户端应用程序是否能够识别Unicode，必需这样做。如果没有字母N 前缀，则 SQL Server 会将字符串转换为与数据库的默认排序规则相对应的代码页。此代码页中没有的字符都将丢失。

数据检索

如果客户端应用程序不支持Unicode 而将数据检索到了非 Unicode 缓冲区，则客户端只能检索或修改客户机代码页可以表示的数据。这意味着ASCII 字符始终可以检索，因为ASCII 字符的表示形式在所有代码页中都是相同的，而任何非ASCII 数据是否可以检索则取决于代码页间的转换。

例如，假设有一个当前仅在美国(U.S.) 运行却在日本使用的应用程序。由于 SQL Server 数据库能够识别Unicode，因而，即使未修改该应用程序以便处理Unicode 文本，也可以将英语和日语文本存储在同一个表中。只要应用程序符合上述条件之一，日语用户就可以使用非Unicode 应用程序输入和检索日语数据，美国用户就可以输入和检索英语数据。来自这两组用户的所有数据均将完整地存储在数据库的同一列中，并且以Unicode 表示。这样，便能够部署可以生成完整数据集的报表且支持Unicode 的报表应用程序。但是，英语用户无法查看日语行，因为应用程序无法显示任何其代码页(1252) 上没有的字符。

如果这两组用户不需要查看对方的记录，则此情形是可以接受的。如果某个应用程序用户必须能够查看或修改单一的代码页无法表示的文本记录，则只能修改应用程序以便能够使用Unicode，除此之外，别无选择。

基于Web 的应用程序

如果客户端程序是基于Web 的或者是连接到动态服务器页(ASP) 页，则在客户端HTML 页和服务器端ASP 页上都存在元数据规范。必须制订这些规范来指定字符串应如何在服务器、ASP 引擎和客户端浏览器之间转换。

在客户端HTML 页上，META 属性必须通过 CHARSET 代码来指定字符集数据应该转换为客户端的编码架构。例如，下面的HTML 页将big5指定为CHARSET代码，指示客户端将字符数据转换为950（繁体中文）代码页。若要查看META 属性的字符集代码，请访问Microsoft 网站Microsoft网站。

复制代码

在服务器端的ASP 页上，必须将客户端浏览器所使用的代码页告知 ASP Web 应用程序。您可以指定Session.CodePage属性或@CodePage 指令。这些方法将处理从服务器到客户端的数据的转换以及GET 和 POST 客户端请求。以下是将两种方法用于指定与客户端的代码页（950，即繁体中文）之间的转换的示例。

复制代码

<%@ Language=VBScript codepage=950 %>

<% Session.CodePage=950 %>

最后，必须记住给任何字符串文字加上字母N 前缀。

请参阅

概念

管理客户端/服务器代码页之间的数据转换

管理 Unicode 编码方案之间的数据转换

管理客户端/服务器代码页之间的数据转换

更新日期：2006 年7 月17 日

本主题介绍了当数据库不使用Unicode 数据类型来存储字符数据时，以及当客户端交互数据的应用程序也不能识别Unicode 时，如何保持字符数据的完整性。在这种情况下，数据存储的代码页和客户端应用程序的代码页必须相同。如果代码页不相同，则客户端和服务器之间的转化有可能导致某些字符丢失。

不支持通过禁用 SQL Server ODBC 驱动程序的AutoTranslate 功能来插入由服务器上其他代码页定义的数据。而且，即使禁用了 AutoTranslate，也不能防止 SQL 语言事件进行代码页转换。其结果是，如果客户端和数据库的代码页不匹配，将对所有发往（或发自）服务器的非Unicode 字符串进行代码页转换。

如果可以，应尽量避免这种情况发生。具有特殊代码页的服务器最好是仅和使用相同代码页的客户端通信。其次是使用另一种字符集大致相同的代码页。例如，代码页1252 (Latin1) 和代码页850 (Multilingual Latin1) 存储的字符集几乎完全相同，因此这两种代码页中的大部分字符可以相互转换而不会丢失数据。

如果您必须使用不同的代码页和客户端通信，则可采用的解决方案是将您的数据存储到Unicode 列中。如果这些选项中有任何一个不可行，则替代方法是使用binary、varbinary或varbinary(max)数据类型，将数据存储在二进制列中。但是，二进制数据只能以二进制顺序来进行排序和比较。这使得它的灵活性不如字符数据。

管理Unicode 编码方案之间的数据转换

本主题说明了当服务器端数据存储和与数据交互的客户端应用程序都支持Unicode，但使用不同的Unicode 编码方案时，如何保留字符数据的完整性。SQL Server 将Unicode 存储在UCS-2 编码方案中。但是许多客户端在另一个编码方案中处理Unicode，此方案通常是 UTF-8，它经常发生在基于Web 的应用程序中。

由于实质上仍然是从一个编码方案转换为另一个编码方案，因此在本主题中讨论的解决方案许多都是在管理Unicode 服务器与非Unicode 客户端之间的数据转换和管理客户端/服务器代码页之间的数据转换主题中也讨论到的。发送到服务器的Unicode 字符串常量前面必须加上大写字母N。对于基于Web 的应用程序，应指定客户端HTML 页的META 属性下的 CHARSET 代码。例如，如果Unicode 编码方案为UTF-8，则指定 CHARSET = utf-8。在服务器端，应使用Session.CodePage属性或@Codepage 指令来指定客户端的编码方案。例如，codepage = 65001 指定了 UTF-8 编码方案。如果按照这些指示进行操作，Internet信息服务(IIS) 5.0 或更高版本将会流畅地处理从UTF-8 到 UCS-2 的转换并返回（而不在客户端进行其他操作）。

在 Visual Basic 应用程序中，将在UCS-2 编码方案中处理字符串。因此，无需明确指定这些应用程序与SQL Server 实例之间的编码方案转换。

编写国际化Transact-SQL 语句

更新日期：2006 年7 月17 日

如果遵循以下指导原则，则使用 Transact-SQL 语句的数据库和数据库应用程序将变得更易于在语言之间移植，或者将支持多种语言：

?使用nchar、nvarchar和nvarchar(max)替换使用的所有char、varchar和text数据类型。

这样做，您就不用考虑代码页转换问题。有关详细信息，请参阅使用Unicode 数据和使用Unicode 的服

务器端编程。

?当执行月份和星期的比较与操作时，请使用数值日期，而不要使用名称字符串。不同的语言设置返回的月份和工作日的名称也不同。例如，当语言设置为美国英语时，DATENAME(MONTH,GETDATE()) 返回May，而当语言设置为德语时，返回Mai，语言设置为法语时则返回mai。应使用以数字而非名称表示月份的函数，如 DATEPART。在生成显示给用户的结果集时，请使用 DATEPART 名称，因为日期名称通常比数值表示

形式更有意义。但是，编写逻辑代码时不要使用任何依赖于特定语言显示的名称。

?当指定用于比较的日期，或者指定用于 INSERT 或UPDATE 语句的输入的日期时，请使用对于所有的语言设置解释方式都相同的常量：

?ADO、OLE DB 和ODBC 应用程序应使用下列ODBC 时间戳、日期和时间转义子句：{ ts'yyyy-mm-dd hh:mm:ss[.fff] '}，例如：{ ts'1998-09-24 10:02:20' }

{ d'yyyy-mm-dd'}，例如：{ d'1998-09-24'}

{ t'hh:mm:ss'}，例如：{ t'10:02:20'}

?使用其他 API 的应用程序或Transact-SQL 脚本、存储过程和触发器都应使用未分隔数值字符串。例如yyyymmdd为 19980924。

?使用其他 API 的应用程序或Transact-SQL 脚本、存储过程和触发器在进行date和smalldate数据类型与字符串数据类型之间的所有转换时应使用带有显式样式参数的 CONVERT 语

句。例如，以下语句对于所有语言或日期格式连接设置的解释方式都相同：

复制代码

SELECT *

FROM AdventureWorks.Sales.SalesOrderHeader

WHERE OrderDate = CONVERT(DATETIME, '19960719', 101)

有关详细信息，请参阅CAST 和 CONVERT (Transact-SQL)。

如何修改 MSSQL2005 的默认编码（字符集）？

guest

dsf

等级:19

竹币:0

省:湖北省 市: 松

市

发短消息

铜牌会员

1 #

大 中 小 发表于 2008-05-17 11:15:00

RT ！sql 是中文企业版的，但是

保存的中文全部都是??????！该怎么改呢？谢谢！

使用nvarchar

建议在联机丛书中查看 国际化..一章. 看看系统的默认字符集是否是COLLA TE Chinese_PRC_CI_AS SSMS-->数据库引擎-->数据库-->数据库属性-->选项-->字符集,修改为中文字符集就行了,

SQL code USE [master] GO ALTER DATABASE [CSDN] COLLATE

Chinese_PRC_CI_AS

GO

谢谢楼上的朋友已经解决了！！！

楼上的朋友，你是如何解决的。我将字符集改成

Chinese_PRC_CI_AS 后，保存汉字还是问号

SQL Server 2005 中的Unicode 支持

2007-10-13 09:00作者：佚名出处：msdn中国责任编辑：幽灵

Unicode支持是SQL Server 2005中多语言支持的基础。Unicode 是由Unicode Consortium(一个提倡为所有语言使用单一字符集的组织)创立的一项标准。SQL Server 2005 支持Unicode 标准 3.2 版。Unicode 标准的3.01 版与ISO-10646(一项与Unicode 中的所有码位均相符的国际标准)完全相同。

Unicode 的工作方式是，为每个字符提供一个唯一的码位，该码位与平台、程序或语言无关。支持Unicode 的程序可以处理任何语言的数据。因为其设计宗旨是涵盖世界上所有语言的所有字符，所以不需要让不同的代码页来处理不同的字符集。

因为所有Unicode 系统都统一使用相同的位模式来表示所有字符，所以从一个系统转到另一个系统时，不会出现字符转换不正确的问题。

管理国际数据库中的字符数据的最简单方法是始终使用Unicode nchar、nvarchar 和nvarchar(max) 数据类型，而不使用它们对应的非Unicode 数据类型：char、varchar 和text。这样，客户端与所有其他客户端所看到的数据中的字符将是相同的。如果所有使用国际数据库的应用程序还使用Unicode 变量来代替非Unicode 变量，则不需要在系统中的任何位置执行字符转换。

注意未来版本的Microsoft SQL Server 中将删除ntext 数据类型。

Unicode 码位及它们所代表的字符与用于可视呈现的“字形”是分开的。ISO 标准(ISO/IEC 9541-1)

将字形定义为“与具体设计无关的可识别抽象图形符号”。因此，一个字符不必总是由相同的字形乃至唯一的字形来表示。所选择的字体决定将使用什么字形来表示特定码位或一系列码位。

有关详细信息，请参阅Unicode Consortium 网站。

编码

Unicode 将码位映射到字符，但实际上并不指定数据在内存、数据库或网页中的表示方式。这便是Unicode 数据编码发挥作用的地方。有许多不同的Unicode 编码。多半选择一种Unicode 数据类型即可，不必为这些细节操心;不过，在以下情况下了解编码有重要意义：

?应对可能以不同方式对Unicode 进行编码的应用程序时

?向其他平台(非Microsoft Windows)或Web 服务器发送数据时

?导入其他编码的数据或将数据导出为其他编码时

Unicode 标准定义了其单一字符集的多种编码：UTF-7、UTF-8、UTF-16 和UTF-32。本部分对这些常见的编码进行说明：

?UCS-2

?UTF-16

?UTF-8

SQL Server 通常以UCS-2 编码方案存储Unicode。不过，许多客户端以另一种编码方案(如UTF-8)来处理Unicode。这种情况在基于Web 的应用程序中经常出现。在Microsoft Visual Basic 应用程序中，

字符串以UCS-2 编码方案来处理。因此，不需要显式地指定Visual Basic 应用程序与SQL Server 实例之间的编码方案转换。

SQL Server 2005 使用Unicode (UTF-16) 来对XML 数据进行编码。类型为xml 的列中的数据以内部格式存储为二进制大型对象(BLOB)，以支持XML 模型特征，如文档顺序和递归结构。因此，从服务器检索的XML 数据会以UTF-16 格式输出;如果想要为检索的数据使用其他编码，则应用程序必须对所检索的UTF-16 数据执行必要的转换。《SQL Server 2005 联机丛书》中的XML 最佳实践提供了如何为从varchar(max) 列中检索的XML 数据显式地声明编码的示例。

使用UTF-16 编码是因为它可以处理 2 字节或 4 字节字符，并且处理是依照面向字节的协议进行的。这些特性使得UTF-16 非常适合于遍历使用不同编码和字节排序系统的不同计算机。因为XML 数据通常在网络上得到广泛共享，所以在数据库中及在将XML 数据导出到客户端时保持默认的UTF-16 存储格式是有意义的。

UCS-2

UCS-2 是UTF-16 的前身。UCS-2 与UTF-16 的不同之处是，UCS-2 是一种固定长度编码，它以16 位值(2 个字节)表示所有字符，因此不支持补充字符。UCS-2 常与UTF-16 发生混淆，UTF-16 用于在内部表示Microsoft Windows 操作系统(Windows NT、Windows 2000、Windows XP 和Windows CE)中的文本，但UCS-2 受到的限制更多。

注意有关在Windows 操作系统中使用Unicode 的最新信息，请参阅Microsoft Developer Network (MSDN) 库中的Unicode。建议Windows 应用程序在内部使用UTF-16，仅在必须使用其他格式时再通过接口作为“薄层”的一部分进行转换。

在Microsoft SQL Server 2000 和Microsoft SQL Server 2005 中以Unicode 存储的信息使用

UCS-2 编码，无论使用的是哪个字符，该编码都将每个字符存储为两个字节。因此，对拉丁语字母“A”的处理方式与对西里尔文字母Sha ())、希伯来语字母Lamed (ì)、泰米尔语字母Rra (?) 或日语平假名字母E (?|) 的处理方式是相同的。每个字母都有一个唯一的码位(对于上述字母，码位分别为U+0041、U+0248、U+05DC、U+0BB1 和U+3048，每个四位十六进制数表示UCS-2 使用的那两个字节)。

因为UCS-2 只考虑了65,536 个不同码位的编码，其本身无法处理补充字符，只能将补充字符视为未定义的Unicode 代理项字符，这些字符组对后定义补充字符。不过，SQL Server 可以存储补充字符而不会有字符丢失或损坏的风险。通过创建自定义CLR 函数，可以扩展SQL Server 处理代理项对的能力。有关处理代理项对和补充字符的详细信息，请参阅本文后面的“补充字符和代理项对”部分。

注意补充字符定义为“具有补充码位的Unicode 编码字符”。补充码位的范围在U+10000 和

U+10FFFF 之间。

UTF-8

UTF-8 是一种旨在以与计算机上的字节排序无关的方式来处理Unicode 数据的编码方案。在处理ASCII 及其他要求使用8 位编码的面向字节的系统(例如，必须覆盖大量使用不同编码、不同字节顺序和不同语言的计算机的邮件服务器)时，UTF-8 会有帮助。尽管SQL Server 2005 不以UTF-8 格式存储数据，但它仍支持使用UTF-8 来处理可扩展标记语言(XML) 数据。有关详细信息，请参阅本文的SQL Server 2005 中的XML 支持部分。

其他数据库系统(例如，Oracle 和Sybase SQL Server)通过使用UTF-8 存储来支持Unicode。视服务器的实现方式而定，从技术上讲实现数据库引擎可能比较容易，因为服务器上的现有文本管理代码在一次处理一个字节的数据时并不要求进行重大更改。不过，在Windows 环境中，UTF-8 存储有几个缺点：

?组件对象模型(COM) 仅在其API 和接口中支持UTF-16/UCS-2。因此，如果数据以UTF-8 格式存储，必须始终进行转换。仅在使用COM 时会出现此问题;SQL Server 数据库引擎通常不会调用COM 接口。

?Windows XP 和Windows Server 2003 的内核均采用Unicode。UTF-16 是Windows 2000、Windows XP 和Windows Server 2003 的标准编码。不过，Windows 2000、Windows XP 和Windows Server 2003 都可以识别UTF-8。因此，在数据库中使用UTF-8 存储格式需要进行许多额外的转换。通常，转换所需的额外资源不会影响SQL Server 数据库引擎，但可能会影响许多客户端操作。

?执行许多字符串操作时，UTF-8 的速度可能都会较慢。排序、比较及几乎任何字符串操作的速度可能都会下降，因为字符的宽度不固定。

?UTF-8 往往需要 2 个以上的字节，并且增加的大小会占用更多的磁盘和内存空间。

尽管有这些缺点，但考虑到XML 已成为一项重要的Internet 通信标准这一事实，您可能希望考虑将默认编码设置为UTF-8。

注意早期版本的Oracle 和Java 也使用UCS-2，它们无法识别代理项。Oracle Corporation 在Oracle 7 中开始支持将Unicode 作为数据库字符集。Oracle 目前支持两种Unicode 数据存储方法：(1) UTF-8 作为CHAR 和VARCHAR2 字符数据类型以及所有SQL 名称和文字的编码;(2) UTF-16 用于NCHAR、NVARCHAR 和NCLOB Unicode 数据类型的存储。Oracle 允许同时使用这两种方法。

UTF-16

UTF-16 是Microsoft 的编码标准，在Windows 操作系统中UTF-16 是一个扩展，其设计用途是处理附加的1,048,576 个字符。对代理项范围的需要甚至在Unicode 2.0 发布之前就已意识到了，因为事实清楚地表明，仅使用65,536 个字符无法实现Unicode 的用单一码位表示每种语言的每个字符的目标。例如，某些语言(例如，中文)至少需要那样多的字符才能对历史和文学表意文字等字符进行编码，这些字符尽管很少使用，但对出版和学术有着重要意义。下一部分提供了有关代理项范围的详细信息。

UTF-16 与UCS-2 类似，也使用little endian 字节顺序，在Windows 上执行的任何操作都遵循该顺序。Little endian(与big endian 相对)意味着低位字节存储在内存中的最低地址处。在操作系统级别字节的排序有重要意义。SQL Server 以及运行在Windows 平台上的其他应用程序都使用little endian 字节顺序。因此，0x1234 这样的十六进制词语以0x34 0x12 形式存储在内存中。在某些情况下，可能需要显式地反转字节顺序以正确地读取字符的编码。SQL Server Integration Services 提供了用于转换Unicode 文本字节顺序的函数。有关详细信息，请参阅本文的SQL Server 2005 Integration Services 部分。

补充字符和代理项对

Microsoft Windows 通常使用UTF-16 来表示字符数据。使用16 位允许表示65,536 个唯一字符。不过，即使是这么多的字符也不足以涵盖人类语言中使用的所有符号。在UTF-16 中，某些码位紧接着前两个字节使用另一个码位，以将该字符定义为代理项范围的一部分。

在Unicode 标准中，有16 个字符“平面”，具有定义多达1,114,112 个字符的潜力。平面0(或称基本多语言块(BMP))可以表示世界上的大部分书面文字、出版中使用的字符、数学和技术符号、几何图形、所有100 级Zapf Dingbat 以及标点符号。

在BMP 之外，大部分平面中的字符仍未定义，但可以用来表示补充字符。补充字符主要用于历史和古典文学典籍，以协助处理中文、韩语和日语丰富文学遗产的编码。补充字符还包括古代北欧文字以及其他具有历史意义的文字、音乐符号等。

在UTF-16 中，一对码位(称为代理项对)用于表示主字符集(BMP) 之外的字符。代理项区是Unicode 中从U+D800 到U+DFFF 的一个范围，其中包含1,024 个低代理项值和1,024 个高代理项值。高代理项(范围U+D800 到U+DBFF)和低代理项(范围U+DC00 到U+DFFF)相结合可以表示超过一百万个可能的字符。

仅具有代理项对的一半将视为无效;高代理项必须始终跟有低代理项，才算有效。这使得代理项的检查变为范围检查，它比检测DBCS(双字节字符系统)字符所需的相当复杂的规则要简单。

尽管UCS-2 不能识别代理项，但SQL Server 2000 和SQL Server 2005 都可以存储代理项对。SQL Server 将代理项对视为两个未定义的Unicode 字符而非单一字符。此类应用程序通常称为“代理中性”或“代理安全”，这意味着它们不具备固有的与数据进行交互的能力，但至少可以做到存储的数据不会丢失。

作为对照，“能够识别代理项的”应用程序不仅可以识别代理项对，还可以处理组合字符和需要特殊处理的其他字符。编写良好的应用程序可以检测到分开的代理项，并且只通过几个子例程就可以将它们重新组合。可以识别代理项的应用程序包括Microsoft Word 和Internet Explorer 5 及更高版本。

在SQL Server 中处理补充字符时，请记住以下几点：

?因为代理项对被视为两个独立的Unicode 码位，所以nvarchar(n) 的大小必须是2，以容纳单一补充字符(换言之，代理项对所需的空间)。

?不支持在元数据(例如，数据库对象的名称)中使用补充字符。一般来说，元数据中使用的文本必须符合标识符的规则。有关详细信息，请参阅《SQL Server 2005 联机丛书》中的标识符。

?标准字符串操作不能识别补充字符。SUBSTRING(nvarchar(2),1,1) 之类的操作仅返回补充字符代理项对的高代理项。LEN 函数为遇到的每个补充字符返回两个字符的计数：一个计数对应高代理项，一个计数对应低代理项。不过，可以创建能够识别补充字符的自定义函数。《SQL Server 2005 联机丛书》的可识别补充字符的字符串操作中的StringManipulate 示例演示了如何创建此类函数。

?对补充字符的排序和搜索行为可能会随排序规则的不同而发生变化。在新的90_and BIN2 排序规则中，可以正确地对补充字符进行比较，而在早期排序规则和标准Windows 排序规则中，所有补充字符的

比较都视同所有其他补充字符的比较。例如，默认的日语和朝鲜语排序规则不处理补充字符，而Japanese_90 和Korean_90 则会进行处理。

有关Unicode 码位、设计可识别代理项的应用程序的最佳实践以及处理Unicode 数据的详细信息，请参阅循序渐进全球化：支持Unicode。有关Unicode 标准中支持的字符范围的信息，请参阅Unicode 技术标准#18 中关于Unicode 正则表达式的部分。

组合字符

“组合字符”是与其他字符一起使用以修改其外观或含义的字符。组合的字符会形成单一字形。例如，欧洲语言中使用的音调符号便是组合字符，可以作为字符加音调符号的形式或预构成字符的形式出现。

在.NET Framework 中，将组合字符的顺序视为文本元素，即显示为单个字符的文本单元。文本元素有别于排序元素。例如，在某些排序规则中，字母“CH”不是组合字符;它们是两个独立的文本元素，但可以将它们视为一个排序元素。

注意SQL 函数的做法有所不同，它通常将组合字符与补充字符一视同仁：它们将组合字符作为两个独立的Unicode 码位进行处理。有关如何创建能够更准确地对补充字符进行计数和比较的自定义函数的示例，请参阅StringManipulate 示例。

组合字符映射到排序元素的方式取决于Unicode 标准和排序规则这两者。某些组合字符始终被视为等同于它们的变体形式，无论它们包括多少不同的码位(例如，拉丁文字母加音调符号被视为等同于包括音调符号的预构成字符)，而在某些排序规则中，可以根据音调符号是否存在以不同方式对字符串进行排序或比较。

组合字符最初是在Unicode 2.0 中定义的。有关详细信息，请参阅论述“特殊区域和格式字符”的Unicode 4.0.1 规范部分。Unicode Consortium 还发布了专门针对组合字符及其处理的FAQ。有关在.NET Framework 中处理组合字符的方法的详细信息，请参阅《.NET Framework 开发人员指南》中的标准化。

对GB18030 的支持

GB18030 (GB18030-2000) 是中华人民共和国(PRC) 颁布的一项针对中文字符编码的独立标准。它对扩展代码页和与Unicode 的映射表都做了规定。官方要求从2006 年8 月 1 日起，在PRC 境内销售的所有软件产品都必须支持此字符集。GB18030 一致性包括对支持一些以前并不支持的语言(例如，藏文、蒙文、彝文和维吾尔文)的要求。

在GB18030 中，字符可以是1、2 或 4 个字节。代理项对用于支持GB18030 的 4 字节序列与Unicode 的映射。

SQL Server 2005 通过在采用GB18030 编码的字符从客户端应用程序进入服务器时对它们进行识别来提供对这些字符的支持。SQL Server 2005 会在本地对这些字符进行转换，并将它们存储为Unicode 字符。这些字符存储在服务器中后，在对它们执行的所有后续操作中均将它们视为Unicode 字符。GB18030 不具有系统区域设置;它只有一个代码页标识符，以实现与Unicode 之间的相互转换。Microsoft 针对

GB18030-2000 的代码页标识符为54936。

使用GB18030 字符时，请记住这些字符可以在排序和比较操作中使用，但如果使用的是SQL Server 90 之前的排序规则，将只能基于这些字符的码位而不能基于其他有语言意义的方式进行比较。因此，在ORDER BY、GROUP BY 和DISTINCT 等操作中使用GB18030 字符时，尤其是在同一操作中同时包括GB18030 字符和非GB18030 字符时，应谨慎行事。要支持有意义的使用GB18030 字符的字符串比较，请使用新的SQL Server 90 排序规则版本(以添加到其名称中的90 后缀表示)。例如，请使用

Chinese_PRC_90 排序规则，而不使用Chinese_PRC 排序规则。

要启用对GB18030 标准的支持，可以安装一个支持软件包，该软件包可以从Microsoft 产品帮助和支持门户下载，其中包括支持GB18030 与Unicode 之间转换所需的字体文件和库。该支持软件包是一个可以在Windows XP 或Windows 2000 上安装的单一全球二进制。不过，系统必须安装可选的东亚语言支持。Windows Vista 中包括了对GB18030 标准的支持，其中包括针对中国少数民族语言(如藏文、蒙文、彝文和维吾尔文)的字体和键盘布局。这些语言均使用中文(PRC) 区域设置。

注意Vista 中不支持某些将GB18030 字节转换为Unicode 字符的函数，如BytesToUnicode。在Vista 中将GB18030 字节转换为Unicode 字符时，请使用MultiByteToWideChar 函数。

看sqlserver的编码格式的sql语句！收藏

SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_K

S_WS', 'CodePage')

936 简体中文GBK

950 繁体中文BIG5

437 美国/加拿大英语

932 日文

949 韩文

866 俄文

65001 unicode UFT-8