Microsoft SQL Server 2000 的国际化功效(3)[MSSQL防范]

Unicode 服务器和客户端

这是抱负的配置范例.通过在整个历程中以 Unicode 情势保存数据,您可以确保最佳的性能并避免检索到的数据被破坏.ADO 和 OLE DB 就属于这种情形.www.iTbulo .comc3iWkZh

Unicode 服务器和一个或多个非 Unicode 客户端

在这种配置中,您大概不会碰到数据存储方面的问题,但是在将数据传送到客户端并利用这些数据时,明显会有很大的限制.客户端代码页必须用于在某一时刻转换 Unicode 数据.www.iTbulo .comc3iWkZh

在数据层上的示例就是您从正在利用 DB-Library 的计算机衔接到 sql server 2000 数据库的时刻.DB-Library 是答应 C 利用程序拜候 SQL Server 的调用级别接口.自 SQL Server 6.5 以来,DB-Library 还没有举行重要的进级.关于我们来说,这将明显地阐明任何利用 DB-Library 的客户端所面对的限制.数据可以仅基于一个代码页,即系统的默许 OEM 代码页.您还可以挑选区域设置信息能否基于客户端系统的区域设置.如以下图解（图 10）所示,在 SQL Server 客户端网络实用程序的“DB-Library 选项”选项卡中,您可以在两个选项之间挑选 DB-Library 转换信息的方法.在默许情形下,这两个选项城市被选中.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 10:默许的 DB-Library 选项www.iTbulo .comc3iWkZh

由于无法处理其他代码页上的数据,所以只有当数据层处于只需求处理 SQL Server 中数据子集的遗留系统中时,DB-Library 才真正具有意义.固然确切有了办理的技术,已经利用它的开辟人员不需求重写其利用程序,但是假如需求支持多种语言数据,重写仍大概是值得考虑的.www.iTbulo .comc3iWkZh

非 Unicode 客户端的另一示例是不支持 Unicode 的程序,如 Microsoft Access 97.当 Access 数据库可以衔接到 SQL Server 2000 数据库时,存在一些您应当知道的限制.比方,当您从美国英语的计算机衔接到具有日语表名的数据库时,便大概会看到一个表名已转换为问号的对话框.以下图解（图 11）显示了这种对话框的示例.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 11:Access 97 中表名转换为问号的图解www.iTbulo .comc3iWkZh

此问题的缘由是很简单理解的:Access 97 利用的是版本低于 3.7 的 ODBC,所以数据利用默许系统代码页从 Unicode 转换为 ANSI.即便您安装了 ODBC 的更高版本,Access 97 中的 Jet 3.5 仍将履行相同的转换.由于日语字符不在美国英语计算机的代码页 1252 上,所以将它们替换为问号.www.iTbulo .comc3iWkZh

不大概与这些表成立衔接.衔接尝试将招致图 12 中所示的错误消息.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 12:Microsoft Access 错误消息www.iTbulo .comc3iWkZh

这也很简单理解.数据一旦转换为错误的代码页并由问号替换,将没有办法使其恢复.这将使 Jet 和 ODBC 直接尝试衔接到名为 dbo.???? 的表.因为该表不存在,此尝试明显会失利.关于不在该代码页中的全部数据,也会呈现这种情形.www.iTbulo .comc3iWkZh

近似的问题也将在表本身的数据中呈现.比方,在一个包含朝鲜语数据的表中,您将看到非 Unicode 客户端（如 Access）供应的数据显示为问号.图 13 中对此举行了阐明.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 13:非 Unicode 客户端数据库中问号的示例www.iTbulo .comc3iWkZh

在下面全部三种客户端（即 DB-Library、ODBC 和 Jet 3.5）中,只理解若何将 Unicode 转换为默许的系统代码页,而不睬解 Unicode 的组件将不能处理这种多种语言数据.这种客户端只能利用其默许系统代码页上可包含的数据.www.iTbulo .comc3iWkZh

非 Unicode 服务器和 Unicode 客户端

关于多种语言数据而言,这不是抱负的配置,因为您将无法在服务器上保存这种数据.但是,您至少可以确保数据会精确显示.该配置具有前面情形中提到的全部限制,但不会因转换无效而破坏已接纳的数据.示例之一就是 SQL Server 2000 数据库将链接的服务器定义为 SQL Server 6.5 数据库.从运行 SQL Server 6.5 的服务器接纳的全部信息都将是有效的,但不要尝试插入不在代码页上的数据.www.iTbulo .comc3iWkZh

非 Unicode 服务器和客户端

这是限制最多的配置,因为无论什么时刻,您基本上只能利用一个代码页.www.iTbulo .comc3iWkZh

从 SQL Server 早期版本举行的多种语言数据转换

并非全部用户都有耐烦等候利用 SQL Server 7.0 和 SQL Server 2000 中包含的 Unicode 功效来处理他们的多种语言数据.因此,有些用户已成立了自定义编码架构来存储这种数据.假如您考虑利用这种办法,那么您将需求利用大容量复制实用程序 (bcp) 将数据保存为二进制情势（意味着无数据转换）,然后利用 -C 号令行参数将数据大批量复制到呼应的代码页.有关 bcp 实用程序的具体信息,请拜见本文稍后的利用 bcp 实用程序来处理多种语言数据.www.iTbulo .comc3iWkZh

利用 Access 2000 的新 ADP 格局

Microsoft Access 2000 增添了一个新文件格局选项,它不是 Jet 数据库,而是 Access 数据项目 (ADP).这些文件可以直接作为 SQL Server 的前端.www.iTbulo .comc3iWkZh

ADP 功效超越了本文谈论的范围,但要指出的两个重要问题是: www.iTbulo .comc3iWkZh

• Access 2000 不支持 SQL Server 2000,除非安装了 SQL Server 2000 客户端工具.
  
  
• 在 Access 内 SQL Server 数据的全部进口点（窗体、数据拜候页、表数据表视图和 ADO）中,Access 和 SQL Server 之间存在一此中间层,即 COM.它会影响日期/时间值、数字和钱币值的输入,因为客户端（在这种情形下指 ADP 所在的计算机）的区域设置用于注释数据的含义.当您利用 Access 时,务必要记着这一点,因为 SQL Server 的法则在某些情形下限制并不多.有关具体信息,请拜见本文稍后的处理 COM 的区域设置冲突.

用户界面中的多种语言数据

固然 SQL Server 主如果服务器,但它仍带有多种管理工具.这些工具已按照需求在 Server 2000 中举行了更新,以支持多种语言数据.www.iTbulo .comc3iWkZh

普通的 UI 更改（Unicode 支持）

在处该当前默许代码页或服务器代码页上的表名时,SQL Server 企业管理器表现相当超卓.在需求时,它还可以操纵 Windows 中的一些字体链接技术来“借用”其他字体的字符,如以下图解（图 14）中所示.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

14: 字体链接技术示例www.iTbulo .comc3iWkZh

如上所示,字体链接无法完成全部工作.关于很多种语言（如亚美尼亚语、Sylfaen、格鲁吉亚和印地语）,Windows 没有高级字体链接信息.别的,当某种语言利用在脚本中不常用的字符（如阿泽里语 － 斯拉夫语）时,除了少数字符大概不会显示外,字符串的大大都字符都将显示.www.iTbulo .comc3iWkZh

有三件风趣的事值得注意: www.iTbulo .comc3iWkZh

• 只要名称在字体中不受支持且字体链接无法实现,您将看不到破坏的字符;相反,您将看到如上所示的对话框,它表示有没有法显示的字符.
  
  
• SQL Server 2000 客户端工具没有利用 Uniscribe 技术来显现复杂的脚本,所以假如您利用的不是 Windows 2000,双向语言（如前面图解所示的希伯来语、意第绪语、阿拉伯语和波斯语）字符向后显示.但是,在 Windows 2000 和支持 BIDI 的平台上,这些字符将精确显示.其他复杂脚本的显现问题（如泰语的断字）则会碰到一样的限制（即便不在 Windows 2000 上）.
  
  
• SQL Server 企业管理器所用的“基本”字体是在计算机桌面显示设置中定义的,它不能被覆盖.

SQL 查询解析器的网格和 SQL 窗格中的多种语言信息

在 SQL Server 企业管理器中,不能对字体举行更改;但是,在 SQL 查询解析器中,您可以在“选项”对话框中的“字体”选项卡中显式地更改用户界面多个部份的字体.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 15:“SQL Server 2000 查询解析器字体”对话框www.iTbulo .comc3iWkZh

由于字体链接仿佛答应显示大大都字符串,所以举行这种更改的缘由起先大概并不明显.但是,精确显示字符串要比简单地找到可表示字符的字体要费事得多.普通,字体挑选是很重要的.因此,这种功效关于精确显示多种语言数据也相当重要.在字体链接看来无法工作的情形下,该功效将使您看到字符串,而不是对话框.www.iTbulo .comc3iWkZh

查询计划器中的格局问题

在查询计划器的很多部份中,您可以在网格窗格中输入与计算机的默许区域设置匹配的信息,大概可以显式地利用 CONVERT 函数来处理采取肆意格局的字符串.www.iTbulo .comc3iWkZh

在采取这种区域设置利用办法时,您应当明确以下一些的计划限制: www.iTbulo .comc3iWkZh

• 不支持长数据格局.
  
  
• 固然可以挑选利用美圆标记 ($),但不该在网格窗格中输入钱币标记.无论怎样,从区域设置中检索到的钱币标记都将在“后果”窗格中利用.
  
  
• 无论区域设置是什么,一元减号始终显示在左侧,且不带括号.因此,-1 应当显示为 -1,而不是 1- 、(1),也不是大概在“区域选项”对话框中指定的任何有效变量.

要在查询计划器中实现一定程度的环球性支持,这些限制是必须的,它们不会阻碍大大都利用特定于区域设置的数据的操作.www.iTbulo .comc3iWkZh

请注意:在“网格”窗格中输入的任何信息都将在“SQL” 窗格中转换为与区域设置无关的格局,这样,在尺度德国计算机上输入的“03.09.65”将转换为 { ts ' 1965-09-03 00:00:00 }.全部直接输入“SQL”窗格的数据都应当是这种格局,不然,应包含一个明确 CONVERT 调用.www.iTbulo .comc3iWkZh

排序次序

“后果”窗格中数据的次序不受“区域设置”的影响,而是由排序法则（请拜见本文前面的 SQL Server 2000 的
排序法则）来掌握若何注释 ORDER BY 子句.www.iTbulo .comc3iWkZh

双字节 (DBCS) 字符

您可以输入 DBCS 字符作为字面量和数据库对象的名称、别名、参数名以及参数标志字符.但是,您不能利用 DBCS 字符作为 SQL 语言元素,如函数名或 SQL 关键字.因此,您应当利用关键字 SELECT,而不能利用日语全形www.iTbulo .comc3iWkZh

获得 SQL Server 数据（数据拜候办法）

您在 SQL Server 中获得数据的方法是至关重要的.拜候数占据很多差别的办法,而每种办法处理多种语言文本的法则是非常重要的.以下各节将对这些数据拜候办法中的一些举行阐明.www.iTbulo .comc3iWkZh

OLE DB

OLE DB 是 Microsoft 数据拜候组件 (MDAC) 的核心组件,在 SQL Server 7.0 中利用 MDAC 2.1 版,而在 SQL Server 2000 中利用 MDAC 2.6 版.OLE DB 是成立在 COM 上的,因而全部字符串都是 Unicode BSTR（在 Windows 2000 上为 UTF-16,在全部其他操作系统上为 UCS-2）.关于 SQL Server 来说,供应程序为 Microsoft OLE DB Provider for SQL Server (SQLOLEDB).数据按需求转换为 Unicode,利用实际数据的次序.最抱负的情形是全部历程中数据都保持为 Unicode.www.iTbulo .comc3iWkZh

ADO

Microsoft ActiveX® 数据对象是一个脚本友好的 Visual Basic 接口,充当 OLE DB 的包装.它还是一种 COM 组件,因此对 Unicode 的支持是相同的.假如要拆分 ADO 和 OLE DB,这二者之间是不答应产生转换的,因此,假如确切存在问题的话,这些问题始终出在 OLE DB 层.www.iTbulo .comc3iWkZh

ODBC

ODBC 能否为 Unicode 层取决于正在利用的 ODBC 的版本.有关实用于 ODBC 法则,请拜见本文前面的 服务器和客户端之间的通信.www.iTbulo .comc3iWkZh

DB-Library

DB-Library 没有最新的 Unicode 版本.有关具体信息,请拜见本文前面的 服务器和客户端之间的通信.www.iTbulo .comc3iWkZh

SQL-DMO

SQL 分布式管理对象 (SQL-DMO) 是一个 COM 层,它交融了 SQL Server 2000 数据库和复制管理.由于它属于 COM,所以 ADO 和 OLE DB 的法则一样实用于 SQL-DMO.SQL-DMO 还具有一些属性,可用于前面所提到功效,如 SQLServer2、Database2、Column2、SystemDateType2 和 UserDefinedDataType2 对象的 Collation 属性.www.iTbulo .comc3iWkZh

利用多种语言的 Transact-SQL

当您向包含多种语言数据的服务器发送 SQL 语句时,有两个主要的问题将影响数据可否成功到达服务器: www.iTbulo .comc3iWkZh

• 对 SQL 语句本身的编码
  
  
• 对语句中字符串字面量的编码

对 SQL 语句中字符串字面量的编码

当对 SQL 字符串本身举行编码后,还必须利用处理字符串字面量的技术.从本质上说,这里的唯一挑选是计算机默许代码页中的字符串或 Unicode 字符串:后者是通过在字符串前面加一个前缀“n”（代表 National）来注明的,以下所示:www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

假如这里没有加上前缀“n”,该字符串（印地语中的词）将转换为“??????”.关于确切具有代码页的数据,也将发生这种情形,但与系统默许值不匹配.www.iTbulo .comc3iWkZh

告诫:注意,在字符串字面量和数据范例（nchar、nvarchar 和 ntext）中利用前缀“n” 表示 Unicode 数据的办法是 SQL Server 特有的.ANSI-92 SQL 标准定义了“National”字符数据范例,但没有规定这种数据范例必须为 Unicode.ANSI-99 SQL 标准（SQL Server 2000 公布时该标准还没有完成,所以就对 Unicode 的支持而言,大概会举行谈论和改正）也的确谈论了利用带有前缀“u”的一组 Unicode 范例（如 utext、uchar 和 uvarchar）.在 SQL Server 2000 中,没有这些数据范例.但在某些其他服务器数据库产品中,情形不是这样.有关具体信息,请拜见本文稍后的与其他数据库产品举行交互.www.iTbulo .comc3iWkZh

SQL 字符串编码

假如 SQL 字符串利用 Unicode（比方,就象任何利用 ADO 的 SQL 字符串 一样）,则您可以对任何范例的字符举行编码.假如字符串不利用 Unicode（如非 Unicode 批处理文件或 .SQL 文件中的字符串）,则转换必须在某处举行,普通,该操作利用举行转换的计算机上的默许系统代码页来举行.在多种语言的利用程序中,假如筹划不够周到,这一历程很简单发生问题.www.iTbulo .comc3iWkZh

假如字符串字面量不是 Unicode（标有前缀 n）,则将利用数据库的默许代码页将其转换为 Unicode.关于多种语言数据,最好利用 Unicode 数据范例和 Unicode 字符串字面量.www.iTbulo .comc3iWkZh

字符串处理函数

Transact-SQL 具有内置的字符串处理函数,这些函数有一些重要的多种语言注意事项:www.iTbulo .comc3iWkZh

ASCIIwww.iTbulo .comc3iWkZh

利用当前的默许系统代码页返回字符串中第一个字符的代码数据点.假如字符不在该代码页上,将返回 63（问号的代码数据点）.这近似于 Visual Basic 和 VBScript 中的 Asc() 函数.www.iTbulo .comc3iWkZh

CHARwww.iTbulo .comc3iWkZh

返回给定 ANSI 代码数据点的字符;从本质上来说,它是 ASCII 函数的反操作,近似于 Visual Basic 和 VBScript 中的 Chr() 函数.假如代码数据点不在 0-255 范围内,它将返回 Null.www.iTbulo .comc3iWkZh

NCHARwww.iTbulo .comc3iWkZh

CHAR 函数的 Unicode 等价函数.它返回给定 Unicode 代码数据点的字符.近似于 Visual Basic 和 VBScript 中的 ChrW() 函数.www.iTbulo .comc3iWkZh

UNICODEwww.iTbulo .comc3iWkZh

ASCII 函数的 Unicode 等价函数,它返回字符串第一个字符的 Unicode 代码数据点.近似于 Visual Basic 和 VBScript 中的 AscW() 函数.www.iTbulo .comc3iWkZh

请注意:在本文前面的示例中,曾经利用过 NCHAR 函数（请拜见日期/时间范例:datetime、smalldatetime）将 RLM（从右至左标志）增添到阿拉伯回历日期的前面,使该日期可以以预期的方法举行格局处理.www.iTbulo .comc3iWkZh

SQL Server 2000 的区域设置支持

SQL Server 2000 中包含对 33 种语言的特定区域设置支持.固然它未对 Windows 的 NLS 数据库的全部区域设置举行支持,但还是供应了很多基本的功效.下表列出了受支持的语言（用简体中文和本国语表示）.www.iTbulo .comc3iWkZh

SQL Server 2000 和 Windows 2000 中所支持的语言列表www.iTbulo .comc3iWkZh

您可以利用 sp_helplanguage 存储历程摆列这些语言以及有关这些语言的信息.请注意,固然各 SQL Server 版本都存储了有关以下所列各项的完好信息,但除非您安装了该产品的本地化版本,不然将无法得到全部区域设置的本地化系统消息.www.iTbulo .comc3iWkZh

有关语言的信息存储在 syslanguages 表中,但消息除外,它们存储在 sysmessages 中.www.iTbulo .comc3iWkZh

语言设置

每个 SQL Server 必须有默许语言,用于处理日期格局和消息等等.对每个所成立的登录到服务器的帐户都将保存一份这样的信息.固然此设置最初是在安装历程中设置的,但可以从服务器级别上将其覆盖,办法是在“SQL Server 属性”对话框的“服务器设置”选项卡上举行呼应的设置,如图 16 所示.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 16:“SQL Server 语言设置”对话框www.iTbulo .comc3iWkZh

您也可以利用 sp_configure 存储历程,比方以下调用会将默许语言更改成意大利语:www.iTbulo .comc3iWkZh

sp_configure "language", 6

下表列出了可用的语言 ID (langid)（要查询语言 ID,可以在 syslanguages 表中查找）.www.iTbulo .comc3iWkZh

利用 sp_addlogin 存储历程或“登录属性”对话框,可以覆盖基于每次登录的默许语言设置,如图 17 所示.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 17:“登录属性”对话框www.iTbulo .comc3iWkZh

最后,还可以利用 SET LANGUAGE 语句在会话级别上覆盖语言设置,以下例所示:www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

应当在字符串前面加上前缀 n,以确保其作为 Unicode 传送.这样,在利用服务器的默许系统代码页举行转换时,可以避免不测问题的发生.www.iTbulo .comc3iWkZh

除了 SET LANGUAGE 调用之外,各个数据拜候办法供应自己的指定语言设置的办法: www.iTbulo .comc3iWkZh

• ADO 支持 ConnectionString 中特定于供应程序的语言关键字.
  
  
• OLE DB 可以设置特定于供应程序的 SSPROP_INIT_CURRENTLANGUAGE 属性.
  
  
• ODBC 可以在数据源定义中或衔接字符串的 LANGUAGE 关键字中指定语言.
  
  
• DB-Library 可以利用 dblogin 分配 LOGINREC,然后利用 DBSETNATLANG 指定语言设置.

语言设置（无论是在服务器、登录级别上指定的,还是在会话级别上指定的）将影响以下各项: www.iTbulo .comc3iWkZh

• 消息
  
  
• 日期/时间
  
  
• 每周的第一天
  
  
• 钱币和钱币标记
  
  
• 月/日的名称和月份的缩写

消息

SQL Server 2000 支持功效具有多种特定语言的系统错误字符串和消息文本.这些消息存储在 master 数据库的 sysmessages 表中.当您安装 SQL Server 2000 的本地化版本时,这些系统消息将被翻译成您所安装的语言版本.默许情形下,您还将得到美国英语版本的消息集.您可以利用“设置语言”来设置服务器会话的语言.默许情形下,该语言为所安装版本的语言.当 SQL Server 向衔接发送消息时,假如语言 ID 设置与在 sysmessages 表的 msglangid 列中所找到的此中一个语言 ID 相匹配,它将利用本地化消息.这些 ID 的格局为十进制,表示消息的区域设置 ID (LCID).假如在 sysmessages 表中没有具有相同 LCID 的消息,将发送美国英语消息.www.iTbulo .comc3iWkZh

您可以利用 sp_addmessage 系统存储历程的 @lang 参数,在 sysmessages 表中增添特定语言的用户定义的消息.（错误号应当大于 50,000.）该语言为该消息的 @lang,即映射到 LCID 的已命名别名.www.iTbulo .comc3iWkZh

由于可以在服务器上安装多个特定于语言的系统错误字符串和消息,language 的值将指定把消息写入 sysmessages 表所利用的语言.当省略 language 时利用服务器会话的默许语言.受支持的语言定义存储在 master.dbo.syslanguages 中.假如您必须安装 sysmessages 的多种语言版本,请与您的产品支持服务 (PSS) 代表接洽.www.iTbulo .comc3iWkZh

日期/时间

可以对短日期格局举行基本更改:是“mdy”、“dmy”情势,还是“ymd”情势.您可以利用 SET DATEFORMAT 设置,在衔接级别上将其覆盖,但需求注意的是,每种语言都有呼应的默许值.通过利用 sp_helplanguage 存储历程,可以检索默许值.该值存储在 dateformat 列中.www.iTbulo .comc3iWkZh

每周的第一天

在差别的区域设置中,每周的第一天会有所差别;在 syslanguages 表的 33 种语言中,该设置在 1（星期一）和 7（星期日）之间改变.您可以利用 sp_helplanguage 存储历程来检索这一信息.该值存储在 datefirst 列中.www.iTbulo .comc3iWkZh

钱币和钱币标记

money 或 smallmoney 范例的任何列都可以包含钱币标记.钱币标记不一定是在“区域选项”对话框中所指定的标记,它可以是下表所列字符中的任何一个.www.iTbulo .comc3iWkZh

您需求注意的是,在 SQL Server 2000 Books Online 中,所列出的欧元标记的十六进制值为 20A0,这是不精确的;其值应为 20AC.20A0 所表示的字符为 ,即欧洲钱币 (ECU) 标记.该标记不是欧元,所以不能当作欧元利用;假如试图在钱币值中利用,将会招致错误.www.iTbulo .comc3iWkZh

月/日的名称和月份的缩写

月和日的名称包含在 syslanguages 表中.您可以通过 sp_helplanguage 存储历程,利用以下列来检索它们:www.iTbulo .comc3iWkZh

monthswww.iTbulo .comc3iWkZh

用逗号脱离的从一月到十仲春的月份名称列表.www.iTbulo .comc3iWkZh

shortmonthswww.iTbulo .comc3iWkZh

用逗号脱离的从一月到十仲春的月份名称缩写.www.iTbulo .comc3iWkZh

dayswww.iTbulo .comc3iWkZh

用逗号脱离的从星期一到星期日的一周各天的列表.www.iTbulo .comc3iWkZh

办理 COM 的区域设置冲突

固然当 SQL Server 在处理日期/时间和钱币值时具有某些非常强盛的功效,但在您利用任何 COM 服务（如 ADO）拜候服务器时,您必须当心其干扰.比方,要让 Visual Basic 知道,以任何钱币标记（列在前面的表中）开首的数值就是钱币值时,您会碰到问题.在使 COM 精确利用存储在字符串中的日期/时间值时,也会碰到严重问题.www.iTbulo .comc3iWkZh

为了精确办理这种情形,您必须理解利用程序在什么时刻将字符串转换为日期/时间或钱币值.一旦知道了转换发生在客户端上还是在服务器上,您便可以决意利用哪些法则了.www.iTbulo .comc3iWkZh

Access 2000 ADP 就是这样一种客户端（请拜见本文前面的 利用 Access 2000 的新 ADP 格局）.由于 Access 通过 OLE DB 工作,所以 Access 2000 的全部操作都遭到 COM 法则的掌握,而 COM 法则利用的是客户端计算机的区域设置.www.iTbulo .comc3iWkZh

注   OLE DB 供应程序（如 Microsoft OLE DB Provider for SQL Server）将适本地在有效 COM 日期和 SQL Server 日期之间举行转换.尽大概不要依靠于字符串中的日期格局,因为这种功效会随着客户端在差别区域设置间变更而忽然失效出错.www.iTbulo .comc3iWkZh

数据转换服务

在处理多种语言数据时,“DTS 导入/导出向导”的用户界面中存在一些问题,如图 18 所示.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 18:“DTS 向导”对话框www.iTbulo .comc3iWkZh

该向导一个界面以供处理差别范例的数据.有少量的对话框,用于显示那些没有象 SQL Server Enterprise Manager 和 SQL Query Analyzer 那样完好启用 Unicode 的数据.（请拜见本文前面的用户界面中的多种语言数据）.所以您大概会碰到这种情形:固然向导中的数据显示不正常,但可以精确传送.DTS 操作的坚固性和安定性是不受这些 UI 限制影响的! 在大都情形下,您只不过不能看到数据罢了,因为这些数据将用小方框替换,如图 19 所示.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 19:“DTS 向导”图解www.iTbulo .comc3iWkZh

只是一个 Unicode 文本文件,此中包含简体中文数据.导入完毕后,便可精确处理这些数据,无论是将其导入到 Unicode 文本列还是导入到简体中文文本列.www.iTbulo .comc3iWkZh

但假如您的文本文件所利用的是与系统默许值不匹配的特别代码页,向导将没有精确的读取该文件的上下文,如图 20 所示.请注意,这种限制并不鲜见.很多程序（包含“记事本”和“写字板”）都不能辨认不利用预期代码页的文件.www.iTbulo .comc3iWkZh

www.iTbulo .comc3iWkZh

图 20:利用“DTS 向导”不能精确导入的文件的图解www.iTbulo .comc3iWkZh

该朝鲜语文件不能在利用美国计算机上精确导入,而向导又不答应利用为导入进程指定代码页的办法.（这就是为什么既不能精确显示数据也不能精确导入数据的缘由）.就象在很多别的情形下一样,法则是十清楚确的:要利用多种语言数据,就应当利用 Unicode.www.iTbulo .comc3iWkZh

在 DTS 转换历程中,可以利用三种对信息编码的法则:您可以挑选“use src”、“use dest”或“use collation”.www.iTbulo .comc3iWkZh

“use collation”选项最有大概使您得到但愿的后果.在 SQL-DMO 和“DTS 计划器”中,它实际上就是默许值.（在 DTS 向导中,它不是默许值,但很简单设置）.“use collation”选项只有当源和目标都是 SQL Server 2000 数据库时才实用,但它将利用各列的排序法则信息来肯定最佳的传送办法.www.iTbulo .comc3iWkZh

别的两个转换选项机动性不足,它们要求您利用服务器的源代码页或目标代码页来肯定转换应当采取的办法.不过,这些设置都过度机械地遵守服务器的代码页设置.固然它们将考虑特定多实例服务器的排序法则,但它们不支持与服务器差别的数据库排序法则.www.iTbulo .comc3iWkZh

“DTS 转换”操作中的另一个特点具有强盛的功效,可以利用 SQL Server 实例的 NLS 信息来转换字符串和其他非日期时间数据.关于将日期/时间数据存储为字符串的格局来说,这种关键功效可以使导入历程按用户所但愿的那样举行.这是非常重要的,因为并非全部格局都有象 SQL Server 2000 那么多的数据格局,而 DTS 则是沟通受限制的格局和服务器功效的重要桥梁.www.iTbulo .comc3iWkZh

当源为 SQL Server 7.0 而目标为 SQL Server 2000 时,SQL Server 2000 列的排序法则在 SQL Server 7.0 中表示对比艰难,在非 Unicode 列之间移动数据会使 DTS 会发生其他问题 .（反之,源为 SQL Server 2000,目标为 SQL Server 7.0 时也会招致一样的问题）.在这些情形下,默许的办法是在 SQL Server 7.0 端利用服务器代码页.一样,利用 Unicode 数据范例可以避免这种问题发生.www.iTbulo .comc3iWkZh

当您用 DTS 而不是转换来履行复制操作时,将会呈现三种大概的情形: www.iTbulo .comc3iWkZh

• OLE DB 供应程序列

  此选项只复制原始数据,很明显,假如两列在相同的代码页上不包含数据,将会发生问题.当源和目标利用相同代码页时,该选项是快速的选项,但当在具有利用差别代码页数据的列之间举行复制时,复制将无效.www.iTbulo .comc3iWkZh

• NCHAR 到 CHAR

  DTS 将自动利用服务器的代码页履行从 Unicode 到其他代码的转换.www.iTbulo .comc3iWkZh

• CHAR 到 NCHAR

  DTS 将自动利用源服务器的代码页履行从其他代码到 Unicode 的转换.www.iTbulo .comc3iWkZh

DTS 转换问题总结

首先要阐明,Unicode 源和目标始终不会呈现问题.这一事实是至关重要的.问题仅发生在特定环境中的非 Unicode 数据上.这里将对此举行总结.www.iTbulo .comc3iWkZh

在要成立目标表时: www.iTbulo .comc3iWkZh

• 当源为 SQL Server 7.0 而 SQL Server 2000 目标服务器代码页与目标数据库代码页不匹配时,转换将失利.
  
  
• 当源为 SQL Server 2000 而目标为 SQL Server 7.0,且源列的排序法则与源服务器代码页不匹配时,转换将失利.
  
  
• 当源和目标为 SQL Server 2000 时,假如没有选中“利用排序法则”,转换将失利,不然,不会丧失任何数据.

在目标表已经存在时: www.iTbulo .comc3iWkZh

• 当源为 SQL Server 7.0 而 SQL Server 2000 目标服务器代码页与目标列代码页不匹配时,转换将失利.
  
  
• 当源为 SQL Server 2000 而目标为 SQL Server 7.0,且源列的排序法则与源服务器代码页不匹配时,转换将失利.
  
  
• 当源和目标都是 SQL Server 2000 时,只要存在下述情形之一,转换将成功:
  • 源和目标列代码页相匹配且选中了“利用排序法则”.
    
    
  • 目标列代码页与目标服务器代码页相匹配且没有选中“利用排序法则”.

    假如“利用排序法则”为真,则所传送数据为原始数据.假如为假,数据将转换为源服务器代码页,然后转换到目标列代码页.www.iTbulo .comc3iWkZh

关于复制列转换来说: www.iTbulo .comc3iWkZh

• char 到 char 是原始转换.假如源和目标列代码页不匹配,转换将失利.
  
  
• char 到 Unicode 将把源数据转换为计算机代码页并转换为 Unicode,但假如源数据没有显示在代码页中,转换将失利.
  
  
• Unicode 到 char 将把数据转换为计算机代码页,而不管目标代码页.这样,假如目标列代码页与计算机的代码页不匹配,转换将失利.

与在其他情形下一样,从 Unicode 到 Unicode 的历程将会正常工作,不会有转换失利或破坏数据的情形,因而成为在利用多种语言数据时的首选.www.iTbulo .comc3iWkZh

利用 bcp 实用程序来处理多种语言数据

当您要从特定的代码页导入数据或将数据导出到特定的代码页时,还可以利用 bcp 实用程序,该实用程序支持下表中所列的标志,用于举行无数据丧失的转换.www.iTbulo .comc3iWkZh

您还可以在列级别利用格局文件并指定排序法则.（假如您不指定 -C、-N 或 -w,bcp 将在履行导入/导出之前,实际查询各列、排序法则和代码页的信息）.系统将提醒您保存格局文件,以下面的示例所示（请拜见 pubs 数据库中的 authors 表）:www.iTbulo .comc3iWkZh

8.0

9

1   SQLCHAR   0   11   ""1   au_id   Latin1_General_CI_AI

2   SQLCHAR   0   40   ""   2   au_lname   Latin1_General_CI_AI

3   SQLCHAR   0   20   ""   3   au_fname   Latin1_General_CI_AI

4   SQLCHAR   0   12   ""   4   phone   Latin1_General_CI_AI

5   SQLCHAR   0   40   ""   5   address   Latin1_General_CI_AI

6   SQLCHAR   0   20   ""   6   city   Latin1_General_CI_AI

7   SQLCHAR   0   2   ""   7   state   Latin1_General_CI_AI

8   SQLCHAR   0   5   ""   8   zip   Latin1_General_CI_AI

9   SQLBIT   0   1   ""   9   contract   ""

所答应的数据范例显示在下表中.排序法则是该列所指定的默许排序法则,它可以是从数据库或服务器担当来的.www.iTbulo .comc3iWkZh

请注意:该表中没有列出 varchar 和 nvarchar 数据范例.关于 bcp 实用程序来说,char 和 nchar 范例应当辨别用于其得当的位置.www.iTbulo .comc3iWkZh

最后,bcp 支持“区域启用”的 -R 标志.该标志与 ODBC“利用区域设置”选项具有相同的效果（请拜见本文前面的 服务器和客户端之间的通信）,并可以与存储在非文本字段中的日期/时间、数字和钱币数据的注释方法相关联.www.iTbulo .comc3iWkZh

Microsoft 的搜索服务和 FTS

很多 Microsoft 产品都利用 Microsoft 搜索服务;该服务本身既用于 SQL Server 2000,又用于 Exchange 2000.引擎与 Index Server 中所利用的引擎一样,将来大概会增添很多别的产品的功效.它最重要的功效是供应提取词干（动词的不法则改变）和特定于语言的单词拆分功效,比方,它使您可以对近似于法语中 l'unique 这样的单词精确编制索引.Microsoft 搜索服务所支持的语言包含: www.iTbulo .comc3iWkZh

• 荷兰语
  
  
• 英语（英国）
  
  
• 英语（美国）
  
  
• 法语
  
  
• 德语
  
  
• 意大利语
  
  
• 日语
  
  
• 朝鲜语
  
  
• 简体中文
  
  
• 西班牙语（现代）
  
  
• 瑞典语
  
  
• 繁体中文
  
  
• 泰语

除了这些与语言有关的词干提取功效/单词拆分功效外,还供应了一种中性功效供在其他语言中利用.在某些特定情形下,您大概更乐意承受利用特定语言得到的后果,而不肯意承受利用中性语言得到的后果（比方,您大概但愿利用西班牙语而不利用加泰罗尼亚语,或但愿利用荷兰语而不利用南非公用荷兰语）,但关于这些情形官方举荐利用中性挑选.因此,倡议您按照自己的数据尝试哪类后果更好,而不但认为“类似”的语言能供应杰出的后果.语言支持是非常复杂的,假如您试图供应的数据并不专属该种语言,将招致潜在的不良后果.www.iTbulo .comc3iWkZh

利用 Microsoft 搜索服务以及相关组件的各种供应程序的实际实现细节,大部份都是以您的需求为底子的:假如您在 Exchange 存储中对数据编制索引,Exchange 实现将是首选.但假如您利用的是文件系统,则 Index Server 是首选.明显,假如您利用的是 SQL Server 2000,则 SQL Server 2000 的“全文搜索”是最佳挑选.www.iTbulo .comc3iWkZh

Microsoft 搜索服务答应客户利用特定语言“标志”文本区域,以答应在单个数据集合利用多种语言索引,但由于 SQL Server 2000 未供应一种方法来以此法“标志”数据,所以应当在列级别上指定语言.但是,您可认为单个列成立多个索引.假如单个列中有多种语言数据,而您但愿履行特定于某种与语言的搜索时,这是一种不错的办法.您可以指定 sp_fulltext_column 的 @language 参数所利用的语言.www.iTbulo .comc3iWkZh

还可以通过对 sp_configure 存储历程利用“默许全文语言”选项,来指定“全文搜索”所利用的默许语言,其调用历程以下所示:www.iTbulo .comc3iWkZh

sp_configure 'show advanced options', 1

GO

RECONFIGURE

GO

sp_configure 'default full-text language', 1041

GO

RECONFIGURE

GO

假如您利用的是默许语言,则没必要在对 sp_fulltext_column 的调用中指定语言.www.iTbulo .comc3iWkZh

用户常常会问,若何才能在“全文搜索”中增添对自己所利用语言的支持.很遗憾,当前还没有办法来实现这一功效.www.iTbulo .comc3iWkZh

代理对（请拜见本文前面的什么是代理?）在 FTS 或 Microsoft 搜索服务中不受支持.别的,您不能基于这些值坚固地履行搜索,一样,由于该缘由,不能对 SQL Server 2000 认为是未定义的任何字符坚固地履行搜索.www.iTbulo .comc3iWkZh

利用 OLAP/分层数据

普通而言,全部有关利用于关系型 SQL Server 2000 的 Unicode 字段中多种语言文本的法则,都一样实用于 SQL Server 2000 的“解析服务”组件所包含的联机解析处理功效 (OLAP).“解析服务”可以处理 SQL Server 2000 本身所支持的任何字符.在少数情形下,假如这些数据不在客户端系统的默许代码页上,将在 OLAP 及其向导的用户界面上显示为问号.但这不会对实际的数据产生影响,而纯粹是 UI 的显示问题.www.iTbulo .comc3iWkZh

OLAP 有一项功效在 SQL Server 2000 中是不受支持的,即在构成“数据仓库”的分层数据构造的差别部份具有差别排序法则的本领.固然该功效在数据解析中并不广泛有效,但是它会对某些情形产生影响,比方按字母次序对数据分区（以举行解析）.在这种情形下,您需求肯定其他数据分区办法来明肯定义排序和分区,但不利用字母次序.这关于分层数据的显示非常有效.假如您需求这种功效,则必须对从 OLAP 源返回的数据的子集举行排序.www.iTbulo .comc3iWkZh

利用 SQL Server 2000 的 XML 支持来处理多种语言数据

SQL Server 2000 中丰富的 XML 支持供应了支持多种语言数据的本领,这是因为 XML 本身默许的编码为 UTF-8 Unicode,并且在很多情形下,SQL Server 将在其成立的 XML 中利用 UCS-2 编码方法.您可以利用多种办法指定 XML 中的编码方法: www.iTbulo .comc3iWkZh

• 假如要将数据作为 ADO 流对象中的 XML 举行格局化,然后保持该流,您可以指定输出编码方法,精确的编码方法将在 XML 格局的数据中标志出来.
  
  
• 您可以在 URL 中指定输出编码方法.
  
  
• XML 模板可以指定编码方法.

即便您不利用这些办法中的任何一种,默许情形下 Unicode 也受支持并将正常工作.www.iTbulo .comc3iWkZh

有一个重要的问题需求注意,对 XML 中名称所答应利用字符的限制要远远多于 SQL Server 中对标识符所答应利用字符的限制.为了完好支持 SQL Server 标识符,XML 中不受支持的标识符字符被一种特别情势 _x0000_ 所替换,这里的 0000 将用 Unicode 代码数据点号码替换.SQL Server 将可以精确辨认这些字符并将其精确返回.注意,Updategrams 将以任一种办法注释编码方法.但是,只有在您没有映射架构的情形下,才有必要利用它们.www.iTbulo .comc3iWkZh

比方,以下 Transact-SQL 语句不能用于成立利用 UCS-2 编码方法的 XML 文件:www.iTbulo .comc3iWkZh

USE Northwind

GO

SELECT TOP 1 * FROM "Order Details" FOR XML AUTO

DECLARE @h int

EXEC sp_xml_preparedocument @h output,

N'<?xml version="1.0" encoding="ucs-2"?>

<root test_x0020_2="foo"></root>'www.iTbulo .comc3iWkZh

SELECT * FROM OPENXML(@h,'/root') WITH("test 2" varchar(200) )

EXEC sp_xml_removedocument @h

这一小段脚本将成立对西里尔字符串 举行编码的 XML 文档,该字符串恰好是表示语言名“乌克兰语”的单词.www.iTbulo .comc3iWkZh

带有注释的架构是随 SQL Server 2000 的 XPath 支持发售的.当前,Web 上的 Updategrams 是测试版,筹划在 2001 年上半年在 Web 上公布终究版.按照计划,这两个版本都能正常处理多种语言文本,并支持指定编码方法的办法;它们还支持前面所述的标识符利用语法.www.iTbulo .comc3iWkZh

与其他数据库产品举行交互

当利用其他数据库系统时,您仅需肯定该系统的代码页和近似法则便可.SQL Server 端的大部份举荐数据拜候办法都触及到 COM,从而触及 Unicode 数据的利用.这样,要肯定一个国际利用程序利用这些数据拜候办法运行的效果若何,您所需求的最主要的信息就是其他数据库产品支持 Unicode 的情形若何.www.iTbulo .comc3iWkZh

比方,其他数据库产品如 Oracle 和 Sybase SQL Server 利用 UTF-8 编码方法支持 Unicode.普通,这不会对您产生影响,因为在您看到信息之前,必须利用 ADO/OLE DB 将数据转换为 UTF-16.但当您尝试直接与这些产品中的数据举行交互时,您应当理解此中的辨别.www.iTbulo .comc3iWkZh

另一个您必须考虑到的主要问题是,固然象 Sybase SQL Server 这样的产品支持“National”字符数据范例,但并不将其视为 Unicode 数据范例.比方,关于这些产品来说,您可以利用 nchar 和 nvarchar 字段将日语数据存储在美国英语数据库中.当您对其他产品运行查询时,理解信息是如安在其他数据库中处理的是非常重要的,只有如此,才能利用 OPENROWSET 这样的号令精确处理国际文本.利用“National”字符数据范例来指定 Unicode 文本是特定于 Microsoft SQL Server 的,以精确处理支持全部语言的编码方法.www.iTbulo .comc3iWkZh

完毕语

Microsoft SQL Server 2000 包含多种强盛的国际功效.SQL Server 7.0 是第一个真正具有多种语言功效的 SQL Server 版本,而成立在其上的 SQL Server 2000 则增添了一组惹人注目的功效,使您可以成立真正环球化的利用程序.由于 Internet 和万维网的重要性,利用程序和数据库可以满意这种需求是至关重要的;而不断增长的电子商务和环球化通信则要求数据库产品可以对其供应支持.SQL Server 2000 是环球组织的首选数据库.www.iTbulo .comc3iWkZh

道谢

假如没有很多人的勤劳工作,本文是不大概完成的.目前此对他们表示感激.www.iTbulo .comc3iWkZh

Michael Kung 是 SQL Server 的项目经理,研究侧重于环球化支持.他不但为本文的多处供应贵重的审视看法质料,并且当我在自己不熟习的产品范畴碰到问题时,还为我举荐符合的咨询人选.他在差别范畴的博识知识是一种重要的资源（乃至超越了本文的范围）,可以在该项目上得到他的帮忙,本人深感侥幸.www.iTbulo .comc3iWkZh

Peter Carlin 是开辟经理,其职责包含 SQL Server 关系型引擎.他挤出自己的时间为我供应反馈看法,是我所接触过的人中供应反馈看法最多的人.他还撰写了一封电子邮件,此中包含了大量有关 SQL Server 中 Unicode 支持的重要信息.这封电子邮件实际上就是本文的灵感源泉,从它发展而来的本文是原文大小的 25 倍!www.iTbulo .comc3iWkZh

Fernando Caro 是首席国际化项目经理.他不但帮忙我一一理解 SQL Server 的各个 OLAP 功效,还帮忙将有关本地化系统消息的谈论从简短的一句“对不起,不支持”更改成可以使读者找到呼应资源的指引.我感激本文使我有机会指出这一不支持的问题,但我更感激 Fernando 和 Peter 的决意:办理该问题是更重要的.在很大的程度上,由于有了象他们一样老是以任何（公道的）大概的方法来帮忙用户的人,才使得 SQL Server 成为了一件巨大的产品.www.iTbulo .comc3iWkZh

此外还要感激几位项目经理和测试人员的帮忙.假如没有他们的帮忙,本文就无法对很多分离在整个 SQL Server 产品中的功效举行国际化功效和问题的谈论.这些人员包含:Michael Rys、Euan Garden、Fadi Fakhouri 和 James Howey.我还要感激 Margaret Li,她使我理解了 SQL Server“全文搜索”所基于的 Microsoft 搜索服务是若何工作的.www.iTbulo .comc3iWkZh

Windows 2000 小组中很多勤劳工作的人员为我供应了很多帮忙,比方有关一些基本问题（如排序法则和区域设置支持）应当若何工作的信息,以及供应 SQL Server 7.0 和 2000 的排序法则支持所基于的原始数据.我要分外感激 Julie Bennett、Cathy Wissink 和 John McConnell,他们有问必答并鼓舞我写出这些文字!www.iTbulo .comc3iWkZh

当然,触及 SQL Server 国际化和多种语言功效的筹划、开辟和测试的完好人员列表,几近与参与该产品的人员列表一样长,这是因为这些功效明显不是什么“附件”,而是 SQL Server 2000 的核心部份.因此,我要感激参与生产这一环球实用的巨大产品的全部人员!www.iTbulo .comc3iWkZh

关于作者

Michael Kaplan 是 Trigeminal Software, Inc. 的总裁和首席开辟人员.该公司是一家软件开辟和咨询公司,专门从事 Microsoft Visual Basic、Microsoft SQL Server、Microsoft Access 和 ASP 利用程序的国际化和本地化.他是 Sams Publishing 出版的 "Internationalization with Visual Basic"（Visual Basic 的国际化）一书的作者,其下一部著作 "Internationalization with SQL Server"（SQL Server 的国际化）将在 2001 中期出版.他还撰写了很多文章并就国际化发展发表过阐述.他的电子邮件地址是:michka@trigeminal.com,Trigeminal Software, Inc. 的网站为 http://www.trigeminal.com/.www.iTbulo .comc3iWkZh