第 7 章 本地化

在使用initdb创建数据库集簇时，区域设置支持会自动 初始化。initdb会使用其执行环境中的区域 设置来初始化数据库集簇，因此如果你的系统已经设置为数据库集簇想要使用的 区域设置，就无需额外操作。如果想使用不同的区域设置（或者不确定系统当前 设置了哪种区域设置），可以通过指定--locale选项，精确 告诉initdb使用哪种区域设置。例如：

$ initdb --locale=sv_SE

这个例子把区域设置为瑞典（SE）所讲的瑞典语（sv）。其他可能的设置有en_US（美国英语）和fr_CA（加拿大法语）。如果一个区域可以使用多种字符集，那么规范可以采用cs_CZ.ISO8859-2这样的形式。系统上有哪些区域设置可用，以及它们以什么名称出现，取决于操作系统供应商提供了什么以及实际安装了什么。

有时混合多个区域设置的规则会很有用，例如使用美国排序规则但使用西班牙语消息。为此，存在一组只控制本地化规则某些方面的区域设置子类别：

这些类别名会转换成initdb选项名，用于覆盖特定类别的区域设置选择。例如，要将区域设置设为加拿大法语，但对货币格式采用美国规则，可以使用initdb --locale=fr_CA --lc-monetary=en_US。

如果希望系统的行为如同没有区域支持一样，可以使用特殊区域C或POSIX。

有些区域类别的性质决定了其值必须在数据库集簇的整个生命周期内保持固定。也就是说，一旦initdb运行过，就无法再更改它们。LC_COLLATE和LC_CTYPE就属于这类类别。它们影响索引的排序顺序，因此必须保持固定，否则文本列上的索引会损坏。PostgreSQL通过记录initdb所见的LC_COLLATE和LC_CTYPE值来强制这一点。服务器启动时会自动采用这两个值。

其他区域类别可以在每次服务器启动时通过设置与区域类别同名的运行时配置变量来更改（细节见第 3.4 节）。initdb所选择的默认值实际上只是写入了配置文件postgresql.conf，作为服务器启动时的默认值。如果你从postgresql.conf中删除这些赋值，服务器将从其执行环境继承设置。

请注意，服务器的区域设置行为由服务器看到的环境变量决定，而不是由任何客 户端的环境决定。因此，务必在启动服务器前配置好正确的区域设置。由此带来 的一个结果是，如果客户端和服务器使用不同的区域设置，消息可能会因其来源 不同而显示为不同语言。

若要让消息可以翻译为用户偏好的语言，必须使用 --enable-nls选项。该选项独立于其他区域支持。

区域支持尤其会影响下列特性：

在PostgreSQL中使用区域支持的唯一严重缺点是速度。因此，只有在确实需要时才使用区域。特别要注意，选择非 C 区域会禁用LIKE和~操作符的索引优化，这可能对使用这些操作符的搜索速度产生巨大影响。

如果区域设置支持没有像上面说明的那样工作，请检查操作系统中的区域设置支持是否已正确配置。要检查某个给定区域是否已安装并可用，例如可以使用Perl。Perl 也支持区域设置，如果区域损坏，perl -v会给出类似下面这样的抱怨：

$ export LC_CTYPE='not_exist'
$ perl -v
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LC_CTYPE = "not_exist",
LANG = (unset)
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

请检查你的区域文件是否位于正确的位置。可能的位置包括：/usr/lib/locale（Linux、 Solaris）、/usr/share/locale（Linux）、 /usr/lib/nls/loc（DUX 4.0）。如果不确定，请查阅系统的 locale 手册页。

请确认PostgreSQL实际使用的区域设置就是你预期的区域设置。LC_COLLATE和LC_CTYPE设置是在initdb时确定的，不重新运行initdb就无法更改。其他区域设置（包括LC_MESSAGES和LC_MONETARY）由启动 postmaster 的环境决定，通过简单地重启 postmaster 即可更改。你可以使用contrib/pg_controldata实用程序检查数据库的LC_COLLATE和LC_CTYPE设置。

src/test/locale目录包含 PostgreSQL区域设置支持的一个测试套件。

那些通过解析错误消息文本来处理服务器端错误的客户端应用，显然会遇到问 题，因为服务器消息可能使用不同语言。如果你创建这样的应用，就需要制定应 对这种情况的方案。嵌入式 SQL 接口（ecpg）也受此问题影 响。目前建议与ecpg应用交互的服务器配置为以 英语发送消息。

维护消息翻译目录需要许多志愿者持续投入，他们希望 PostgreSQL能够良好地支持他们偏好的语言。如 果你所用语言的消息目前还不可用，或尚未完全翻译，我们将非常感谢你的协 助。如果你愿意帮忙，请参考开发者指南，或向开发 者邮件列表写信。