<b>Microsoft SQL Server 2000 的国际化功效(1)</b>[MSSQL防范]

简介

Microsoft® sql server™ 2000 包含各种支持国际化操作和环境的强盛功效.扩大的多种语言功效使 SQL Server 2000 成为一种惹人注目的数据库产品和利用程序平台.本文将完好地概述在环球范围内利用这些功效的办法.除了列出一系列功效外,本文还将注释国际化/多种语言要求会怎样影响项目的各个方面.chin a i t p oe er . co msZSXwpB

什么是 Unicode?若何利用 Unicode?

Unicode 支持是 SQL Server 2000 多种语言支持的底子.Unicode 是一种尺度,旨在支持环球全部的脚本.无论是何种平台、程序还是语言,Unicode 为每个字符供应了一个唯一的代码数据点.支持 Unicode 的程序可以处理任何语言的数据.Unicode 3.0 可以处理多达 1,114,112 个字符.chin a i t p oe er . co msZSXwpB

Unicode 是由 Unicode Consortium 管理的行业尺度.该组织熟习到全部语言具有单一字符集的重要性.Microsoft 是 Unicode Consortium 的成员.大部份参与的公司与 Microsoft 都有相同的动机:在成立环球软件办理筹划之际,显现多种语言数据本领的重要性是显而易见的.其他很多公司和个人的加入是为了理解多种语言数据处理方面的问题和本领.chin a i t p oe er . co msZSXwpB

目前的 Unicode Standard 3.01 版平等于 ISO-10646,后者是继 Unicode 1.1 公布之后与 Unicode 中全部代码数据点匹配的国际化尺度.行业尺度和国际化尺度的有效结合后,可以避免任何个人因个人好处而违反这两种尺度的目标:成立实用于全部人的字符集!chin a i t p oe er . co msZSXwpB

有关具体信息,请拜候 Unicode Consortium 的 Web 站点.chin a i t p oe er . co msZSXwpB

编码

Unicode 将代码数据点映射到字符,但实际上对数据在内存、数据库中或 Web 页上的表示方法并不作具体阐明.这就是实际的 Unicode 数据编码的作用.Unicode 具有多种差别的编码.本节将阐明以下几种常用的编码: chin a i t p oe er . co msZSXwpB

• UCS-2
  
  
• UTF-16
  
  
• UTF-8

操纵本文供应的有关编码的信息,您可以更好地理解 Unicode 以及存储 Unicode 的一些办法.普通情形下,只需挑选一种 Unicode 数据范例便可,而没必要考虑这些细节.但在下列情形下,理解编码都是相当重要的: chin a i t p oe er . co msZSXwpB

• 正在处理大概用其他方法对 Unicode 举行编码的利用程序
  
  
• 必须向其他平台（非 Microsoft Windows®）或 Web 服务器发送数据
  
  
• 必须管理数据与其他编码之间的导入或导出

UCS-2

UCS-2 是 Microsoft Windows NT® 4.0、Microsoft® SQL Server™ 7.0 版和 Microsoft SQL Server 2000 所利用的主要 Unicode 编码.UCS-2 答应对 65,536 个差别代码点举行编码.存储在 SQL Server 2000 的 Unicode 中的全部信息均以这种编码举行存储,即无论所利用的是什么字符,城市用两个字节表示每一个字符.因此,拉丁字母“A”的处理方法与以下字母相同: chin a i t p oe er . co msZSXwpB

 chin a i t p oe er . co msZSXwpB

• 西里尔字母 Sha

   chin a i t p oe er . co msZSXwpB

   chin a i t p oe er . co msZSXwpB

• 希伯来字母 Lamed

   chin a i t p oe er . co msZSXwpB

   chin a i t p oe er . co msZSXwpB

• 泰米尔字母 Rra

   chin a i t p oe er . co msZSXwpB

   chin a i t p oe er . co msZSXwpB

• 日文平化名字母 E

 chin a i t p oe er . co msZSXwpB

每个字母都有一个唯一的代码数据点（关于这些字母,代码数据点辨别是 U+0041、U+0248、U+05DC、U+0BB1 和 U+3048,此中每个四位 16 进制数字都表示 UCS-2 所利用的两个字节）.chin a i t p oe er . co msZSXwpB

字节的排序在操作系统级中是至关重要的.由于 SQL Server 在 Windows 平台上运行,它利用的是 Little Endian 编码系统（指“小数在前”）.因此,象 0x1234 这样的 16 进制词将在内存中存储为 0x34 0x12.chin a i t p oe er . co msZSXwpB

UTF-16

UTF-16 是 Microsoft Windows 2000 所利用的主要 Unicode 编码.即便在 Unicode 2.0 公布之前,人们都已清楚地熟习到,仅用 65,536 个字符不能实现 Unicode 的目标（即支持每种语言中每个字符对应一个代码数据点）.关于有些语言（如中文）,仅是对罕用字符举行编码,就需求这么多的字符.因此,人们增添了对代理范围的支持,以处理额外的 1,048,576 个字符.UTF-16 是完好支持对原始尺度举行这种扩大的编码.有关代理范围的信息,请拜见主题什么是代理?chin a i t p oe er . co msZSXwpB

UTF-16 所遵守的是每个代码数据点两个字节的相同尺度.但是,关于 UTF-16,某些代码数据点会利用紧跟后来的另一代码数据点来定义字符.chin a i t p oe er . co msZSXwpB

与 UCS-2 类似,UTF-16 也以 Little Endian 的方法举行存储,就象在默许情形下在 Windows 上存储一样.chin a i t p oe er . co msZSXwpB

重要   固然 UCS-2 不辨认代理,但它不会破坏代理所在数据库中的实际数据,而是将它们当作两个单独（未定义）的字符.chin a i t p oe er . co msZSXwpB

固然 SQL Server 7.0 和 SQL Server 2000 可以毫无丧失地存储代理对,但它们却将代理对当作两个未定义的 Unicode 字符,而不是一个单独的字符.这样的利用程序普通会被描写为代理“中立”或代理“安全”,此中安满是指可以存储数据,即便本身并不能与其举行交互.目前,由于没有正式定义的代理字符,所以代理“辨认”利用程序相当少见.Microsoft word 2000、Microsoft Windows 2000 和 Microsoft Internet Explorer 5.0 以及更高版本就是几种代理辨认利用程序.chin a i t p oe er . co msZSXwpB

UTF-8

很多要求 8 位编码的 ASCII 和其他面向字节的系统（如邮件服务器）都必须超越多种利用差别编码、差别字节排序和差别语言的计算机.UTF-8 是一种与计算机上的字节排序无关的用于处理 Unicode 数据的编码架构.固然 SQL Server 2000 不以 UTF-8 情势存储数据,但它在至少一种关键情形下支持 UTF-8,即支持可扩大标志语言 (XML).有关具体信息,请拜见本文背面的利用 SQL Server 2000 的 XML 支持来处理多种语言数据.chin a i t p oe er . co msZSXwpB

其他许大都据库系统（如 Oracle 和 Sybase SQL Server）都支持利用 UTF-8 举行存储的 Unicode.按照服务器的实现办法,数据库引擎在技术上可以更为简单地实现这种支持（服务器上现有的全部文本管理代码每次只处理 1 字节的数据,因此不需求太大的更改）.在 Windows 环境中,UTF-8 存储具有以下缺陷: chin a i t p oe er . co msZSXwpB

• 组件对象模子 (COM) 在其 API 和接口中只支持 UTF-16/UCS-2.假如数据以 UTF-8 格局存储,则常常需求举行转换（只有在利用 COM 时才会呈现这种问题;SQL Server 数据库引擎普通不调用 COM 接口）.
  
  
• Windows NT 和 Windows 2000 的内核都是 Unicode,它们辨别利用 UCS-2 和 UTF-16.一样,UTF-8 存储格局需求很多额外的转换（如先前对 COM 的阐明一样,这不会给 SQL Server 数据库引擎造成转换上的问题,但大概会影响很多客户端操作）.
  
  
• 对很多字符串操作,UTF-8 大概会较慢.由于字符没有固定的宽度,排序、对比和几近任何字符串操作都大概会减慢.
  
  
• UTF-8 普通需求两个以上字节,但增添的大小会占用磁盘上和内存中的更大空间.

由于 XML 是较为重要的 Internet（它常常面向字节）通信尺度,所以它默许为 UTF-8 是很有原理的.chin a i t p oe er . co msZSXwpB

什么是代理?

代理区域是 Unicode 中从 U+D800 到 U+DFFF 的范围,它包含 1024 个低代理值和 1024 个高代理值.高代理和低代理可以举行组合,以供应对上百万个大概字符的拜候.假如只有一个代理对的一半,则将被视为无效.要成为有效,必须始终有一个高代理和一个紧随后来的低代理.与检测 DBCS（双字节字符系统）字符所需的复杂法则相对比,这使代理检测变成了简单的范围检测.chin a i t p oe er . co msZSXwpB

当公布 SQL Server 7.0 时髦不存在任何代理.公布 SQL Server 2000 后,唯一的代理字符是那些与纯文本中的语言标志相关的字符.chin a i t p oe er . co msZSXwpB

重要   如上所述,代理可以在不招致任何数据丧失风险的情形下举行存储,但是,当尝试利用 SQL Server 字符串处理函数来处理数据时,应非常当心.别的,Windows 2000 目前只支持代理字符的代码数据点排序.chin a i t p oe er . co msZSXwpB

在公布 SQL Server 2000 后,经过 ISO 和 Unicode 尺度组织的通力合作,更多的字符已增添到代理范围中,此中包含 40,000 个 CJKV（中文、日语、朝鲜语和越南语）象形文字.这些字符主要用于传统的和古典的文献,有助于对丰富的 CJKV 文学遗产举行编码.chin a i t p oe er . co msZSXwpB

SQL Server 2000 的数据范例

很明显,数据库的核心任务是数据存储.本部份将谈论在利用 SQL Server 2000 数据范例存储国际化数据时呈现的一些问题.chin a i t p oe er . co msZSXwpB

非 Unicode 文本范例:char、varchar 和 text

当处理以 char、varchar 或 text 数据范例存储的文本数据时,需求考虑的最重要的限制是只能存储单个代码页中的信息.切当的代码页取决于列的排序法则（假如不存在列级排序法则,则利用数据库的排序法则）.要肯定用于给定列的代码页,可以利用 COLLATIONPROPERTY 函数,以下例所示:chin a i t p oe er . co msZSXwpB

SELECT COLLATIONPROPERTY('Chinese_PRC_Stroke_CI_AI_KS_WS', 'CodePage')

936

SELECT COLLATIONPROPERTY('Latin1_General_CI_AI', 'CodePage')

1252

SELECT COLLATIONPROPERTY('Hindi_CI_AI_WS', 'CodePage')

0

上例中增添了印地语,以指出很多区域设置（如格鲁吉亚语和印地语）都没有代码页,因为它们是“仅 Unicode”的排序法则.这些排序法则不实用于以上数据范例.chin a i t p oe er . co msZSXwpB

无论什么时刻要将 Unicode 数据插入到这些列中,这些列城市利用 WideCharToMultiByte API 以及与排序法则相关联的代码页从 Unicode 举行内部转换.每当字符无法在给定代码页上显示时,它都将被替换为问号 (?);这样,不标准的问号便可以很恰本地指出因这种转换而被破坏的数据.别的,问号还会很恰本地指出您的确需求一个 Unicode 数据范例.假如您利用的是非 Unicode 范例的字符串字面量,则将首先利用数据库的默许代码页（从其排序法则派生）对其举行转换.chin a i t p oe er . co msZSXwpB

现代码页中并不包含您要支持的全部字符时,若要尝试存储数据,则大概碰到另一个问题.该问题的一个最好示例就是阿拉伯语脚本:它支持多种语言,包含伊朗语、柏柏尔语、波斯语、克什米尔语、哈萨克语、吉尔吉斯语、库尔德语、普什图语、信德语、Uighur 和乌尔都语等.以上全部语言都有作为 Windows 代码页 1256 底子的阿拉伯语所没有的附加字符.假如利用阿拉伯语排序法则在非 Unicode 列中存储这些额外的字符,这些字符将被转换为问号.之所以会产生这一问题,是因为在于大都情形下,Windows 会将某个特定代码页视作“最合适的”代码页.这意味着将无法保证您可以依靠该代码页来处理全部文本,不过它还是最合适的可用代码页.chin a i t p oe er . co msZSXwpB

Unicode 文本范例:nchar、nvarchar 和 ntext

SQL-92 标准定义了这些“N”（代表国家）数据范例,但没有分外要求将它们用于 Unicode,这些数据范例的实际定义将留待数据库平台或开辟人员来处理.在 SQL Server 7.0 和 SQL Server 2000 中,这些数据范例的定义平等于 UCS-2/UTF-16 Unicode.务必要紧记,这是针对 Microsoft SQL Server 而言的.当您利用其他数据库服务器（如 Sybase SQL Server）时,务必要知道“N”数据范例并不特指 Unicode.chin a i t p oe er . co msZSXwpB

关于复杂脚本（如印地语和泰米尔语）的存储,务必要注意数据的次序应当精确.很多种语言（如泰米尔语）实际上规定了某些字母在文本显现时必须重新排序,从而使文本在内存中存储时的逻辑次序差别于用户界面所显示的可视次序.关于任何一种复杂的脚本语言（包含全部的印度语、阿拉伯语、波斯语、希伯来语以及其他很多种语言）,数据都始终应当按照精确的逻辑次序举行存储.这些数据的实际显现是别的一个问题（请拜见本文稍后的用户界面中的多种语言数据）.chin a i t p oe er . co msZSXwpB

固然“N”列确切支持任何语言或语言组合的数据,但只能以一种排序法则对这些数据举行实际排序（该问题的意义和影响将在排序法则中进一步谈论）.本文先前所说起的代码页限制均不实用于 Unicode 列.chin a i t p oe er . co msZSXwpB

日期/时间范例:datetime 和 smalldatetime

实际的数据范例没有实际的国际化含义;它们表示具有以下定义的日期/时间值:chin a i t p oe er . co msZSXwpB

datetimechin a i t p oe er . co msZSXwpB

从公历 1753 年 1 月 1 日到公历 9999 年 12 月 31 日的日期和时间,精度为 1/300 秒（即 3.33 毫秒或 0.00333 秒）.chin a i t p oe er . co msZSXwpB

smalldatetimechin a i t p oe er . co msZSXwpB

从公历 1900 年 1 月 1 日到公历 2079 年 6 月 6 日的日期和时间,精度为分钟.29.998 秒或更小的 smalldatetime 值将下舍入到最接近的分钟数;而 29.999 秒或更大的值则上舍入至最接近的分钟数.chin a i t p oe er . co msZSXwpB

Microsoft SQL Server 不承受这些范围外的数据.实际数据在内部存储为两个整数（即 datetime 的 4 个字节整数和 smalldatetime 的 2 个字节整数）,它们表示所谈论的日期和时间.由于实际值关于特定于区域设置的格局转换并没有任何实际的意义,所以将由开辟人员按照需求来定义这种转换.chin a i t p oe er . co msZSXwpB

SQL Server 2000 支持多种差别的可在服务器上履行且特定于区域设置的转换,而不用依靠开辟人员供应的定制办理筹划.这些日期款式可以通过 CONVERT 函数来拜候,该函数包含一种数据范例、一个表达式和一种可选款式,以下表所示.chin a i t p oe er . co msZSXwpB

以下示例阐明了若何利用 CONVERT 函数:chin a i t p oe er . co msZSXwpB

SELECT CONVERT(char, GETDATE(), 100) AS [100]

Aug 16 2000 11:50AM

然后,您可以按近似的方法将数据从字符串转换为日期值:chin a i t p oe er . co msZSXwpB

SELECT CONVERT(datetime, 'Aug 16 2000 11:50AM', 100) AS [100]

值得注意的是,当利用 Style 130（科威特语或 Hijri）转换这些日期时,假如排序法则不是一种利用 Unicode 转换代码页 1256 的阿拉伯排序法则,那么在转换为 char 数据范例时便大概会破坏数据.下面的图解（图 1）阐明了这一问题.chin a i t p oe er . co msZSXwpB

chin a i t p oe er . co msZSXwpB

图 1:转换日期/时间的 Transact-SQLchin a i t p oe er . co msZSXwpB

注意,在 U.S. 客户端计算机上,尝试利用 char 数据范例会使阿拉伯字符转换为问号,并使 nchar 数据范例显现为阿拉伯字符.由于 SQL Query Analyzer 内 SQL 网格的限制,这种特别字符串仍旧不能显示精确的格局（象在阿拉伯文客户端计算机上那样）.下面的图解（图 2）阐明了实际的 Hijri 日期字符串应当若何显示.chin a i t p oe er . co msZSXwpB

chin a i t p oe er . co msZSXwpB

图 2:Hijri 日期字符串chin a i t p oe er . co msZSXwpB

由于复杂脚本（如阿拉伯语）具有必须利用的成形法则,所以数据可以精确地显现.在利用双向 (BIDI) 语言（如希伯来语）情形下,全部数据将被反转;其效果要比在利用阿拉伯语的情形下更为明显.这是因为字母的实际形状会按照四周的字母发生改变.Windows 2000 或支持阿拉伯语的 Windows 早期版本中不会呈现这种问题.chin a i t p oe er . co msZSXwpB

别的,返回的数据字符串自身会在需求它的双向语言环境中引发问题,因为象 Internet Explorer 或 Windows 2000 这样的利用程序所利用的双向语言文本的筹划法则会使日期以下面图解（图 3）中所示的情势显示.chin a i t p oe er . co msZSXwpB

chin a i t p oe er . co msZSXwpB

图 3:双向日期字符串示例chin a i t p oe er . co msZSXwpB

此可视次序 (dd hh:mi:ss yyyy mon :) 明显不是预期的次序;固然通过在字符串前增添呼应的 Unicode 掌握字符可以很简单办理该问题,但仍可以将该问题视作 CONVERT 函数中 130 款式的普通限制,如以下查询所示:chin a i t p oe er . co msZSXwpB

SELECT NCHAR(8207) + CONVERT(nchar, GETDATE(), 130)

NCHAR 函数返回一个基于传入 Unicode 代码数据点的字符.8207 或 16 进制的 0x200F 是从右到左的标志 (RLM),有助于精确显示字符串.chin a i t p oe er . co msZSXwpB

性能和存储空间

抱负的情形下,每列是利用此中一种 Unicode 数据范例举行定义的.但是,当您不需求支持多种语言数据时,这样做会造成与存储空间和速度相关的问题.chin a i t p oe er . co msZSXwpB

存储空间问题

Unicode 数据范例需求的实际空间量是每个字符两个字节,而非 Unicode 数据范例需求的空间量关于全部非 DBCS 文本而言是一个字节;关于利用 DBCS 的亚洲语言而言是两个字节.因此,假如您的数据不在某一亚洲代码页上,就要利用两倍的空间来存储数据.假如您要进级现有数据库或正在肯定新项目的精确数据范例,就必须考虑这个问题.假如您只在单个（非亚洲语）代码页的某列中存储数据,便可以不利用 Unicode,以便节俭磁盘上和内存中的空间.chin a i t p oe er . co msZSXwpB

速度问题

速度问题相当复杂.以下是这些问题: chin a i t p oe er . co msZSXwpB

• 假如您运行的是 Windows NT 或 Windows 2000,内核就应是 Unicode 数据,所以在大都情形下（如当您显示数据或利用操作系统服务时）必须转换非 Unicode 列.
  
  
• 当处理 DBCS 数据时,还必须考虑在装载大量数据时所需的额外时间.
  
  
• 假如您利用的是 Windows 95 或 Windows 98 客户端或服务器,那么当需求操作系统服务（如数据显示）时,很多信息也会需求从 Unicode 举行转换.
  
  
• 假如您正在服务器（拜见本文稍后的服务器和客户端之间的通信）、数据库服务器产品或其他产品之间履行操作,那么转换数目还会在性能方面中起侧重要作用.
  
  
• 假如您利用的是亚洲语言,那么利用 Unicode 实际上要比利用特定于语言的 DBCS 代码页更快.这是因为 DBCS 数据没有固定的宽度,而是双字节和单字节字符的混合.
  
  
• 假如您利用的是非亚洲语言,对 Unicode 数据排序要比对非 Unicode 数据排序慢 30%.这可以视作显示全局数据功效的一项本钱.

重要   要实际地评价性能问题,您必须通过测试来得到此情形下的真实数据.chin a i t p oe er . co msZSXwpB

系统表中的元数据信息

SQL Server 2000 的系统表存储了它们包含为 Unicode 的全部数据.这样大大削减了因数据库和列的差别排序法则而产生的问题.目前还没有其他办法来办理同一服务器上的差别数据库既可以有 Unicode 列名也可以有非 Unicode 列名的问题.即便您此时只支持一种语言,SQL Server 也必须预备支持任何您此后大概要挑选的语言.chin a i t p oe er . co msZSXwpB

当您从 SQL Server 6.5 或早期版本转换数据库和服务器时,很简单会为所转换的元数据而耽忧;其实,这种耽忧是不必要的.向 Unicode 的转换很简单,因为 SQL Server 的这些早期版本只利用在服务器级别上定义的一个代码页/排序法则.chin a i t p oe er . co msZSXwpB

此中一个重要问题是若何利用系统表中对象的标识符.SQL Server 2000 利用了 Unicode 2.0 字符属性定义来成立标识符中有效字符的列表（SQL Server 2000 的开辟完成时,Unicode 3.0 还没有公布）.为了避免 Unicode 2.0 字符属性定义中未定义国际化字符的问题,您应当用中扩号 ([]) 或双引号 (") 来限定您的标识符.这样便可以禁止服务器查抄有效的字符.chin a i t p oe er . co msZSXwpB