Unicode 必不可少
作者：Barry Trute

从使用 Unicode 开始部署一个新的数据库系统。

设计和设置一个新数据库系统要需要进行大量的规划。 但有一个重要的决定往往被忽略， 即选择正确的字符集。

选择字符集要考虑的一个基本问题就是确保它可以在将来的某个时候处理任何需要立即支持的语言。 另一个被忽略的问题就是要考虑使用或与数据库交互的应用程序和技术。 用 Unicode 作为数据库字符集可以确保为构建到数据库中以及基于数据库构建的功能奠定坚实的基础。

关于 Unicode

Unicode 是一种通用的字符编码方案，它允许用户使用一个字符集存储所有主要语言的信息。 Unicode 定义了每个字符的属性、标准化了脚本行为、为双向文本提供了标准算法并定义了与其他标准的交叉映射。 Unicode 标准（由 Unicode Consortium 制定）当前为第 4 版。它为 96,382 个字符（对版本 3.2 中的 95,156 个字符进行了扩充）分别指定了唯一的标识符，涵盖全球主要书面语言以及许多数学符号和其他符号。

Unicode 确保最大的可用性

与使用其他字符集相比，将 Unicode 集成到应用程序和网站中显著节省了成本。 Unicode 使单个软件产品或单个网站可以在多个平台、多种语言和多个国家中使用且不必重建。 它还允许在多个不同系统间传输数据而不会损坏数据。

Unicode 确保可扩展性

Unicode 已经开始全面取代各种字符编码方案，如 ASCII、EUC 和 ISO 8859。 使用 UTF-8 编码，可以在完全基于 ASCII 设计的环境（如 UNIX）中方便地使用 Unicode，也就说它具有向后兼容性。 UTF-8 是针对 Unix、Linux 和类似系统的编码。

所有事实上的 Web 标准（HTML、XML 等）都支持或需要 Unicode。 现在通过使用 Unicode 部署新系统，可以确保与当前最新技术兼容并使您无需昂贵的移植即可利用未来的先进技术。

不使用 Unicode 部署系统

如果现在不用 Unicode 部署您的新系统又会怎么样呢？ 如果现在不需要 Unicode 而是根据需要选择了其他字符集，则仍可以很成功地实现您的系统。 但根据我们与大量客户的合作经验，从长远看来这中做法不可取。 有很多情况最终必须使用 Unicode，如合并和收购、数据和系统整合、运营国际化、对新法规或标准的支持以及只是想领先竞争对手。

将旧式系统移植到 Unicode 所需要的时间和成本可能会高得吓人。 数据库移植的一个重要因素就是停机时间，该时间可能从数小时到数天不等。 在进行任何移植前必须进行精心的准备，包括备份、使系统脱机、搜索无效数据（使用数据库字符集扫描程序）、删除并重新创建索引以及运行 Oracle 数据库实用程序，如 Oracle Data Pump 或导出和导入实用程序。 某些公司无法承受任何停机所引起的影响并可能有上百个数据库要移植。

对许多客户而言，前面提到的将数据库字符集移植到 Unicode 所涉及的时间投入和潜在的困难通常只是冰山上的一角。 客户通常不得不必须同时移植应用程序和数百个最终用户以及多个数据库实例。 可能需要将应用程序国际化以处理多字节数据，包括提供对区域设置敏感的操作、扩展字段存储大小以及一开始就把输入正确地转换为 Unicode。 通常，在选择第三方工具时没有考虑到 Unicode，因此必须升级或替换这些工具。 在没有其他选择的情况下，遇到这些情况的客户通常必须分阶段移植到 Unicode，这有时可能需要数年才能完成。

Oracle 对 Unicode 的支持

Oracle 对 Unicode 的支持非常全面。 Oracle 数据库 10g 第 2 版为 Unicode 4.0（多语支持标准）提供了完全支持。 该支持使客户可以在单个中央数据库中或作为网格的一部分开发、部署和承载多种语言。 Oracle 还提供了将所有数据以 UTF-8 存储在 Unicode 数据库中或将 Unicode 数据类型的选择列以 UTF-8 或 UTF-16 增量式存储的灵活性。

Oracle 提供了几个用于插入和检索 Unicode 数据的数据库访问产品。 Oracle 支持最常用的编程环境，如 Java 和 C/C++。 数据在数据库与客户端程序之间进行透明转换，以确保客户端程序独立于数据库字符集。

Oracle 对 Unicode 的支持扩展到了整个数据库技术系列。 Oracle HTML DB、Oracle Text、SQL Regular Expressions、Oracle XML DB 和 XQuery 等数个关键技术不但支持 Unicode 而且提供了增强的功能及其使用时的灵活性。

尽管许多客户意识到了 Unicode 的必要性及其使用好处，但他们通常却为 Unicode 表面的复杂性而震慑。 在某些情况下，这是一种莫名的担心，但需要解决使用 Unicode 的一些难题。 这些难题大多围绕宽度可变的 UTF-8 编码方案。 每个 ASCII 字符占用 1 个字节。 每个带重音的拉丁字符（阿拉伯语、西里尔语、希腊语和希伯来语）占用 2 个字节。 大多数其他字符（包括中文、印度语、日语和朝鲜语）每个占用 3 个字节，补充字符用 4 个字节表示。 以下是一些常见问题以及 Oracle 对应的解决办法。

使用 Unicode 数据库如何进行存储管理和字符串处理？

许多人认为，支持 UTF-8 数据库意味着将存储要求提高一倍或两倍，并且必须处理非常复杂的字符串处理。 通常情况下，确实需要增加存储要求，但没有用户想像得那么高。 要记住的第一件事就是，数据库包含许多不会扩展的非字符数据字段，如数字、日期、时间戳和二进制数据（如图像和文档）。 数据扩展的量通常取决于文本数据语言。 对于一个假定主要由英语数据组成的数据库，扩展的量将非常小，只有非 ASCII 符号才会从 1 个字节扩展为 2 到 3 个字节。 西欧语言包含一些变音字符；这些字符在 UTF-8 中通常将扩展为 2 个字节。亚洲语言使用的字符扩展量最大，通常每个字符是从 2 个字节扩展为 3 个字节。

Oracle9i 引入了长度语义，使您可以选择是以字符形式还是以字节形式声明字符串。 字节语义仍是默认值，而在列、表、会话以及为整个数据库则可以声明字符长度语义。 长度语义使存储管理更直观，并使一个通用数据库模式可以在使用不同字符集的不同数据库上顺利运行。 这就简化了从应用程序和数据库到 Unicode 的移植过程。 字符或字节语义的选择只影响 PL/SQL 变量或数据库列的声明。

无论您如何声明变量或列，INSTR、LENGTH 和 SUBSTR 函数始终按字符处理。 这样做的好处是无论字符集是单字节的还是多字节的（如 Unicode），您都会获得相同的行为。

使用 Unicode 数据库是否会影响性能？

Oracle 致力于通过每个数据库版本提高 Unicode 的性能。 通常情况下，Unicode 数据库提供的性能与同一版本的单字节数据库提供的性能几乎相同。 在频繁使用 PL/SQL 字符串处理函数的环境中，Unicode 数据库对性能的影响将超过单字节数据库。

Unicode 数据库的性能超过了在上一版本中实现的单字节数据库的性能。 例如，Oracle 数据库 10g 中的 Unicode 数据库通常比在 Oracle9i 上运行的单字节数据库运行速度快，而在其他方面两者的性能相同。 当然，也可以使用其他出色的 Oracle 特性（如真正应用程序集群 (RAC) 和网格计算）来根据需要提高性能。

Unicode 能否与现有系统集成？

项目很少是完全从开头开始构建的。 尽管新系统不断被构建，但它们通常对现有数据或系统存在一定程度的依赖性。 由于 Unicode 几乎支持所有语言，并且是所有 Oracle 字符集的超集，因此可以正确地转换和存储有效的传入数据。 如果 Unicode 数据库为其他系统提供数据，则需要确保目标系统支持发送给它的所有数据。 使用前面提到的存储管理和字符串处理功能，可以更容易地重用现有模式和应用程序。 对于许多客户而言，使用 Unicode 实现一个新系统为摆脱旧式实践提供了良机，并为将他们的所有系统升级到 Unicode 奠定了基础。

Oracle 的建议

有关 Unicode 以及本文所描述特性的更多信息，请访问 OTN 的全球化支持主页。