Chapter 5. 区域

Table of Contents

5.1. 区域支持

5.1.1. 概述
5.1.2. 益处
5.1.3. 问题

5.2. 多字节支持

5.2.1. 打开多字节支持
5.2.2. 设置编码
5.2.3. 服务器和客户端之间的自动编码转换
5.2.4. 关于 Unicode
5.2.5. 如果不能转换会怎样？
5.2.6. 参考
5.2.7. 历史
5.2.8. Windows/ODBC 里的 WIN1250

5.3. 单字节字符集记录

从管理员的角度描述可用的区域特性．

PostgreSQL 通过三种途径支持区域：

利用操作系统库的区域（locale）特性，提供对集合顺序，数字格式，翻译过的信息，和其它方面的支持．
利用明确定义在 PostgreSQL 服务器里的多字节字符集，支持那些需要多于一个字节容量字符的语言，以及提供客户端和服务器之间的字符集记录．服务器所支持的字符集数目是在编译服务器的时候确定的，并且一些象字符串比较这样的内部操作要求把每个字符扩展为一个 32 位的字．
单字节字符记录为多字节和单字节字符集的用户提供了一种更轻量级的解决方法．

5.1. 区域支持

区域支持指的是应用中考虑字母，排序，数字格式化等与文化相关的问题． PostgreSQL 使用服务器操作系统提供的标准 ISO C 和类似 POSIX 的区域机制．更多的信息请参考你的系统的文档．

5.1.1. 概述

缺省的时候， PostgreSQL 并未内建区域的支持；要打开它，给 configure 脚本增加 --enable-locale 选项：


$ 


./configure --enable-locale

区域支持只影响服务器；所有客户端的区域支持都与服务器端兼容．

要打开用户优选的语言的信息译文，那么你必须使用 --enable-nls 选项．这个选项是独立于其它区域支持的．

具体使用哪种文化规则的信息由标准环境变量决定．如果你在其它程序中已经获得了区域的特性，那么很可能你已经获取了区域的支持．设置区域信息的最简单的方法是设置 LANG 变量，比如：

export LANG=sv_SE

这样就把区域设置为瑞典（sv ），用瑞典语说话（SE ）．其他的可能性是 en_US （美国英语）和 fr_CA （加拿大法语）．如果有多于一种字符集可以用于区域，那么声明看起来象下面这样： cs_CZ.ISO8859-2 ．你的系统里有哪些可用的区域设置，它们的名字是什么，这些信息都取决于你的操作系统提供商提供了什么以及你安装了什么东西．

有时候，把几种区域规则混合起来也很有用，比如，使用美国规则而用西班牙语信息．要实现这个目的，可以设置一套环境变量，为某一范畴覆盖缺省的LANG ：

`LC_COLLATE`	字符串排序顺序
`LC_CTYPE`	字符分类（什么是字母？什么是这个字母的等效大写？）
`LC_MESSAGES`	信息的语言
`LC_MONETARY`	货币金额的格式
`LC_NUMERIC`	数字的格式
`LC_TIME`	日期和时间的格式

另外，所有这些声明的变量和 LANG 变量都可以用 LC_ALL 环境变量覆盖．

注意: 一些信息区域化库也使用环境变量 LANGUAGE ，它覆盖所有其它用于设置语言信息的区域设置．如果有问题，请参考你的操作系统的文档，特别是 gettext 手册页获取更多信息．

如果你想要你的系统表现得象没有区域支持，那么使用特殊的区域 C 或 POSIX ，或者简单地取消掉所有区域相关变量的设置．

请注意服务器的区域行为是由它看到的环境变量决定的，而不是由任何客户端的环境变量影响的．因此，要在启动服务器之前认真地设置好这些变量．这样带来的一种情况是如果客户端和服务器设置成不同的区域，那么消息可能以不同的语言呈现，实际情况取决于它们的源是什么．

LC_COLLATE 和 LC_CTYPE 变量影响索引的排序顺序．因此对任意数据库集群，这些值必须固定，否则对文本字段的索引将会导致数据库崩溃． PostgreSQL 通过记录 initdb 所看到的 LC_COLLATE 和 LC_CTYPE 值来强制这样的固定．服务器在启动的时候自动采纳这两个值；在服务器启动的时候只能设置其它的 LC_ 范畴．简而言之，在一个数据库集群里只能使用一个集合顺序，而该顺序是在 initdb 的时候选取的．

5.1.2. 益处

区域支持特别影响下面的特性：

ORDER BY 查询里的排序顺序．
函数里的 to_char 家族
模式匹配中的 LIKE 和 ~ 操作符

PostgreSQL 里区域支持的唯一的严重缺点是速度．因此只有你需要的时候才使用它．同时我们还要特别指出的是选择一个非 C 区域设置将关闭为 LIKE 和 ~ 操作符设置的索引优化，这样对那些使用这些操作符的搜索可能有巨大的性能影响．

5.1.3. 问题

如果经过上面解释后区域支持仍然不能运转，那你就要检查一下看看你的操作系统的区域支持是否正确配置．要检查某个区域是否安装并且正常运转，你可以使用象 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 ）．如果你不知道在那里，请检查你的系统的手册页．

请检查核实 PostgreSQL 确实使用了你认为它该用的区域设置．LC_COLLATE 和 LC_CTYPE 设置都是在 initdb 的时候决定的，如果不重复 initdb 是不可能改变的．其它的区域设置包括 LC_MESSAGES 和 LC_MONETARY 都是由 postmaster 启动的环境决定的，可以通过简单地重启来修改．你可以用 contrib/pg_controldata 工具程序检查数据库的 LC_COLLATE 和 LC_CTYPE 的设置．

目录 src/test/locale 包含 PostgreSQL 的区域支持的测试套件．

那些通过分析错误信息处理服务器端错误的客户端应用很明显会有问题，因为服务器来的信息可能会是以不同语言表示的．如果你使用了这样的应用，那么你应该设计一个计划来处理这种情况．嵌入的 SQL 接口( ecpg )也受这个问题影响．我们目前建议使用 ecpg 应用做接口的服务器配置成发送英文信息．

维护信息翻译表需要许多志愿者的坚持不懈的努力，他们就是希望 PostgreSQL 以它们的语言说话的人．如果你的语言的信息目前还不可用或者没有完全翻译完成，那么我们很欢迎你的协助．如果你想帮忙，那么请参考 开发人员手册 或者向开发者邮递列表发邮件．