Maison  >  Article  >  base de données  >  SQL Server 2005 中的 Unicode 支持

SQL Server 2005 中的 Unicode 支持

WBOY
WBOYoriginal
2016-06-07 15:04:311319parcourir

Unicode 支持 是 SQL Server 2005 中多语言 支持 的基

  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。

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn