Microsoft SQL Server 2000 的国际化功能(1)(4)

以下示例说明了如何使用 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

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有