9.1第二十二章
第二十二章 区域
本章从管理员的角度描述可用的区域特性。 PostgreSQL 通过两种途径支持区域：
利用操作系统库的区域（locale）特性，提供对集合顺序，数字格式，翻译过的信息，和其他方面的支持。这包括在Section 22.1 和Section 22.2.里面。
提供一些不同的节字符集以支持在各种语言中存储文本内容，以及提供客户端和服务器端之间的字符集转换。这包括在Section 22.3.
22.1. 区域支持
区域支持指的是应用中考虑字母，排序，数字格式化等与文化相关的问题。PostgreSQL 使用服务器操作系统提供的标准 ISO C 和POSIX的区域机制。更多的信息请参考你的系统的文档。
22.1.1. 概述
当数据库集群用initdb创建时，区域支持将被自动初始化。缺省时，initdb 将会按照它的执行环境的区域设置初始化数据库集群，所以，如果你的系统已经设置了数据库集群想要的区域，那么你什么都不需要做了。如果你想要用一个不同的区域（或者你不确定你的系统是设置的哪个区域），你可以用initdb指定--locale选项进行进行设置。例如：
initdb --locale=sv_SE
这个例子就把区域设置为瑞典（sv），用瑞典语说话（SE）。其他的可能性是 en_US（美国英语）和 fr_CA （加拿大法语）。如果有多于一种字符集可以用于区域，那么可以采取这样的形式：language_territory.codeset.例如，fr_BE.UTF-8表示法语（fr），用比利时语说话（BE），并且用UTF-8字符集编码。
你的系统里有哪些可用的区域设置，它们的名字是什么，这些信息都取决于你的操作系统提供商提供了什么以及你安装了什么东西。在大多数Unix系统上，这个命令locale -a可以提供一个有效的区域列表。Windows使用更详细的区域名称，例如，German_Germany or Swedish_Sweden.1252，但原则是相同的。
有时候，把几种区域规则混合起来也很有用，例如，用英语的排序规则但是用西班牙语消息。为了支持这些，我们有一套区域子范畴用于控制区域规则的某一方面：
LC_COLLATE 字符串排序顺序 LC_CTYPE 字符分类（什么是字母？它是这个字母的等效大写？） LC_MESSAGES 信息的语言 LC_MONETARY 货币金额的格式 LC_NUMERIC 数字的格式 LC_TIME 日期和时间的格式
这些范畴名转换成 initdb 选项的名字以覆盖某个特定范畴的区域选择。例如，比如，要把区域设置为加拿大法语，但使用 U.S. 规则进行格式转化，可以使用 initdb --locale=fr_CA --lc-monetary=en_US。
如果你想要你的系统表现得象没有区域支持，那么使用特殊的区域 C 或 POSIX。
当数据库被创建时，有些区域种类的的值必需是固定。你可以对不同的数据库用不同的设置，但是一旦数据库被创建，你将不能对这个数据库进行任何改变。LC_COLLATE 和LC_CTYPE 就是这种类型。它们影响索引的排序，所以，，它们的值必须保持固定，否则在文本字段上的索引将会崩溃。（但是你可以通过排序来缓解这个限制，如Section 22.2.的讨论。）当initdb运行时，这些种类的默认值就已经确定了，当新的数据库创建时将会用这些值，除非你在CREATE DATABASE命令中指定其他值。
其他区域的种类是可以随时改变的，需要通过设置服务器配置参数来设置，和区域类别的方法相同（请参阅Section 18.10.2获取详细信息）。当服务器启动时，initdb选择的默认值实际上是写到配置文件postgresql.conf中。如果你在postgresql.conf中移除这些值，那么服务器将会从环境变量中继承这些设置。
请注意服务器的区域是由服务器的环境变量确定的，而不是客户端的环境变量。因此，在服务器启动之前，请小心设置一个正确的区域。这个结论是，如果客户端和服务器设置了不同的区域，那么消息可能以不同的语言呈现，实际情况取决于它们的源是什么。
注意：在我们谈到从执行环境继承区域的时候，这意味这我们在大多数操作系统上的下列动作：对于一个给定的区域范畴，比如排序，它下面的环境变量将会被询问，直到找到了一个设置了的：LC_ALL,LC_COLLATE（或者变量对应各自的范畴），LANG。如果没有一个环境变量被设置，那么将默认使用C这个区域。
一些消息的区域库也用环境变量LANGUAGE来设置，它覆盖所有其它用于设置语言信息的区域设置。如果有疑问，请参考你的操作系统的文档，特别是关于gettext的文档。
要打开把消息能转换成用户的选择的语言的功能，必须在创建的是时候使用NLS选项（configure --enable-nls）.所有其他区域的支持是在创建时自动进行的。
22.1.2. 行为
区域的设置影响以下的SQL特性：
用ORDER BY或者其在文本数据上进行标准的比较操作进行排序查询
使用 LIKE 子句的索引的功能
使用upper，lower和initcap函数
使用和to_char相似的函数
在PostgreSQL中使用其他非C和POSIX区域的缺点是对性能有影响。它降低了字符处理的速度和阻止了在 LIKE 类查询里面普通索引的使用。因此，只有在你实际上需要的时候才使用它。
作为一种变通的方法，允许在非C区域下使PostgreSQL通过LIKE字句来使用索引，需要自定义几个操作。这些允许创建的索引执行严格的字符比较，忽略区域的比较规则。请参阅Section 11.9获取更多信息。另一种方法是用C排序创建一个索引，见Section 22.2中的讨论。
22.1.3. 问题
如果区域支持通过以上的说明不能工作，请检查你的操作系统的区域支持是否正确的配置。并检查这个区域是否在你的系统上安装，如果你的系统支持，你也可以用locale -a命令来检查支持的区域。
请检查核实PostgreSQL是否使用了你想要的区域设置。LC_COLLATE和LC_CTYPE设置在数据库被创建的时候确定。除了新建一个数据库，不然这个设置不能被改变。其他区域设置如LC_MESSAGES和LC_MONETARY将由服务器启动时候的环境变量决定，并可以在运行中被修改。你也可以用SHOW命令检查这些动态的设置。
目录 src/test/locale 包含 PostgreSQL 的区域支持的测试套件。
那些通过分析错误信息处理服务器端错误的客户端应用很明显会有问题，因为服务器来的信息可能会是以不同语言表示的。我们建议这类应用的开发人员改用错误代码机制。
维护信息翻译表需要许多志愿者的坚持不懈的努力， 他们就是希望 PostgreSQL 以它们的语言说话的人。如果在你的语言消息不可用或者没有被全部翻译，那么我们很欢迎你的协助。如果你想帮忙，请查看Chapter 48或者给开发这发邮件。
22.2. 排序支持
这个排序功能允许为数据库的每列和某些其他区域方面的数据指定排列顺序，甚至每一个操作。这样将减轻在数据库被创建之后将不能改变LC_collate和LC_CTYPE设置的限制。
22.2.1. 概念
从概念上讲，每一个collatable数据类型的表达式都具有排序规则。（内置的collatable数据类型有text，varchar和char。用户自定义的基本类型也能被当做collatable类型，当然一个collatable类型的域就是collatable。）如果这个表达式是一个引用列，该表达式的排序规则是用这一列定义排序规则，如果这个表达式是一个常量，该表达式的排序规则就是这个常量的数据类型默认的排序规则。大多复杂的表达式的排序规则都来自于它输入时候的排序规则，如下面的描述。
表达式的排序规则可以是“默认”的，这意味着需要为数据库定义区域设置。这个表达式的排序规则可能是不确定的。在这种情况下，排序操作和其他操作需要知道这个排序将会失败。
当这个数据库系统执行一个排序或者比较操作，它将会用这个输入表达式的排序规则。出现这种情况，例如，用ORDER BY字句和函数或者操作调用，如<.用ORDER BY字句来整理排序是非常简单的。当这个排序规则来自函数或者操作调用这时，如下面描述。除了比较运算符，排序规则是通过函数之间的大小写字母转换，如lower，upper和initcap。
对于一个函数或者一个操作调用,这个排序规则是通过在运行的时候执行指定的操作来检查这个参数的类别。如果这个函数或者操作调用的结果是一个collatable数据类型，如果有请求需要知道这个表达式定义的排序规则。这个排序规则也可以用在函数或操作表达式定义分析的过程中。
一个表达式的排序规则可以是隐式或显式的。当多个排序出现在一个表达式中时，这些差别将会影响排序规则的组合。当COLLATE字句时，将会产生一个显式的排序规则，所有其他的排序将会是隐式的。当又多个排序需要组合时，例如，在一个函数调用里面，一下的规则将会被用到：
1.如果任何输入的表达式有一个显式的排序规则，那么所有输入的表达式显式的排序规则必须相同，如果有任意一个显式的排序规则存在，那么，这个排序的结果是各个排序的并集。
2。在另一种方式下，所有输入的表达式必须有共同的隐式排序规则或者默认的排序规则。如果任意一个非默认的排序存在，那么这个排序的结果是各个排序的并集。否则，这个结果将按照默认的排序规则。
3.如果输入的表达式中隐式的排序规则和非默认的排序规则相冲突，那么这个组合将认为没有确定的排序规则。这不是一个错误条件，除非请求的内容需要用到这个特定的功能来进行排序。如果这个条件发生，那么在运行的时候你将会得到一个错误。
例如，考虑这个表的定义：
CREATE TABLE test1 ( a text COLLATE "de_DE", b text COLLATE "es_ES", ... );
然后再
SELECT a < 'foo' FROM test1;
根据de_DE规则来通过<来比较，因为这个表达式结合了一个隐式的默认的排序规则。但是在
SELECT a < ('foo' COLLATE "fr_FR") FROM test1;
这个比较将会用fr_FR规则进行比较，因为这个显式的排序规则覆盖这个隐式的排序规则。此外，给定
SELECT a < b FROM test1;
这个解析器将不能确定是用哪个排序规则，因为a列和b列的隐式排序规则相互冲突。由于<操作符需要知道使用哪个排序规则，这个结果将会返回一个错误。这个错误可以用输入一个显式的排序规则的表达式来解决。 如：
SELECT a < b COLLATE "de_DE" FROM test1;
或者等价的：
SELECT a COLLATE "de_DE" < b FROM test1;
另一方面，这个结构类似于
SELECT a || b FROM test1;
这不会导致错误，因为||操作符跟这个排序规则无关：其结果是一样的，跟排序无关。
输入表达式分配给函数或者操作组合的排序规则也被用来做这个函数或者操作的结果，如果函数或者操作的结果是一个collatable类型，那么，
SELECT * FROM test1 ORDER BY a || 'foo';
这个排序将会根据de_DE的规则来完成。但是这个查询：
SELECT * FROM test1 ORDER BY a || b;
这将导致错误，因为即使||操作符并不需要知道排序规则，但是ORDER BY字句需要知道。因此，这个冲突可以用一个显式的排序规则来解决：
SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";
22.2.2.排序管理
排序规则是映射SQL名到操作系统区域设置的一个SQL模型对象.特别是，它映射到LC_COLLATE和LC_CTYPE的组合。（正如名字所显示的，一个排序规则的主要意义是设置LC_COLLATE环境，它能控制这个排列的顺序。但是很少在实际环境中需要设置跟LC_COLLATE不同的LC_CTYPE环境，因此，它更多是为了方便收集这个模式下的一些概念，而不是在另一个结构中为每一个表达式设置LC_CTYPE环境）并且，排序规则依赖与字符集编码（见Section 22.3）。同样的排序规则可以在不同的编码中存在。
在所有平台上，排序规则default，C和POSIX都是有效的。其他的排序规则是否有效依赖于操作系统是否支持。default排序规则是由数据库在创建的时从LC_COLLATE何LC_CTYPE中选择一个值。C和POSIX排序均指定“传统的C”的行为，只有ASCII字母A-Z才被视为是一个字母，并且通过严格的字符编码的值来进行分类。
如果操作在单个程序中用多个区域提供支持（newlocale和相关的函数）。那么当数据库集群初始化，initdb将会在排序规则的系统目录pg_collation中找出此时在操作系统上的所有排序规则。例如，操作系统可能提供的区域名字为de_DE.utf8。initdb将根据UTF8编码创建一个名为de_DE.utf8的排序规则，并且通过LC_COLLATE和LC_CTYPE来设置de_DE.UTF8.它也会用拆开这个名字用.utf8来创建一个排序规则。因此，你也可以用这个名字下的de_DE来使用这个排序规则，这样比较容易书写，并让这个名字减少编码依赖。请注意，虽然如此，排序规则的初始名字和平台相关。
如果排序规则需要LC_COLLATE和LC_CTYPE有不同的值，可能需要用CREATE COLLATION命令创建一个新的排序规则。这个命令也可以从一个已经存在的排序规则来创建新的排序规则，这可能是有用的，以便能够使用应用程序中的操作系统无关的排序规则名称。
在任何一个指定的数据库中，只能用与数据库编码相关的排序规则。其他在pg_collation中的规则将会被忽略。因此，一个被剥离的名称的如de_DE在一个给定的数据库中可以被认为是唯一的，无论它在全局是否唯一。使用剥离排序规则名称的方法是可取的，如果你决定改变到另一个数据库的编码，你只需要做少量的改变。但是请注意，default，C和POSIX的排序规则可以不管数据库的编码。
PostgreSQL认为不同的排序规则之间互不相容，即使它们有相同的属性。因此，例如，
SELECT a COLLATE "C" < b COLLATE "POSIX" FROM test1;
这将会返回一个错误，即使C和POSIX排序规则有着相同的属性。因此，混合剥离和非剥离的排序规则名字也是不允许的。
22.3. 字符集支持
在PostgreSQL中字符集支持允许你存储各种字符集的文本（也可以叫编码）。包括单字节字符集支持如ISO 8850系列和多字节字符集如EUC（扩展的Unix 编码）,UTF-8，和Mule国际编码。所有支持的字符集可以被客户端透明的使用，除了在服务端一些不支持的字符集（也就是说作为服务端的编码）。当PostgreSQL数据库集群用initdb初始化的时候，将会选择默认的字符集。当你创建一个数据库的时候它能被覆盖，所以，如果你有多个数据库，它们都可以有不同的字符集。
然而，有一个重要的限制，每一个数据库的字符集必须和这个数据库的LC_CTYPE（字符分类）和LC_COLLATE（字符串排序）区域设置兼容。对于C和POSIX区域，任何一个字符集都是被允许的，但是对于其他区域都只允许一个字符集，这样才能正常工作。（然而在windows上，UTF-8编码能用于任何一个区域。）
22.3.1. 支持的字符集
Table 22-1显示了在PostgreSQL有效的字符集设置。
Table 22-1.PostgreSQL字符集
| 名字 | 描述 | 语言 | 服务端？ | 字节/字符 | 别名 |
| BIG5 | Big Five | 繁体中文 | No | 1-2 | WIN950, Windows950 |
| EUC_CN | Unix扩展中文编码 | 简体中文 | Yes | 1-3 | |
| EUC_JP | Unix扩展日文编码 | 日语 | Yes | 1-3 | |
| EUC_JIS_2004 | Unix扩展日文编码，JIX X 0213 | 日语 | Yes | 1-3 | |
| EUC_KR | Unix扩展韩文编码 | 韩语 | Yes | 1-3 | |
| EUC_TW | Unix扩展台湾编码 | 繁体中文，台语 | Yes | 1-3 | |
| GBK | 扩展国际标准 | 简体中文 | No | 1-2 | WIN936, Windows936 |
| ISO_8859_5 | ISO 8859-5, ECMA 113 | 拉丁语/斯拉夫语 | Yes | 1 | |
| ISO_8859_6 | ISO 8859-6, ECMA 114 | 拉丁语/阿拉伯语 | Yes | 1 | |
| ISO_8859_7 | ISO 8859-7, ECMA 118 | 拉丁语/希腊语 | Yes | 1 | |
| ISO_8859_8 | ISO 8859-8, ECMA 121 | 拉丁语/希伯来语 | Yes | 1 | |
| JOHAB | JOHAB | 朝鲜语（韩语） | N0 | 1-3 | |
| KOI8R | KOI8-R | 西里尔（俄罗斯）语 | Yes | 1 | KOI8 |
| KOI8U | KOI8-U | 西里尔（乌克兰）语 | Yes | 1 | |
| LATIN1 | ISO 8859-1, ECMA 94 | 西欧语 | Yes | 1 | ISO88591 |
| LATIN2 | ISO 8859-2, ECMA 94 | 中欧语 | Yes | 1 | ISO88592 |
| LATIN3 | ISO 8859-3, ECMA 94 | 南欧语 | Yes | 1 | ISO88593 |
| LATIN4 | ISO 8859-4, ECMA 94 | 北欧语 | Yes | 1 | ISO88594 |
| LATIN5 | ISO 8859-9, ECMA 94 | 土耳其语 | Yes | 1 | ISO88599 |
| LATIN6 | ISO 8859-10, ECMA 144 | 北欧语 | Yes | 1 | ISO8851910 |
| LATIN7 | ISO 8859-13 | 波罗的语 | Yes | 1 | ISO885913 |
| LATIN8 | ISO 8859-14 | 凯尔特语 | Yes | 1 | ISO885914 |
| LATIN9 | ISO 8859-15 | Latin1的与欧盟和口音 | Yes | 1 | ISO885915 |
| LATIN10 | ISO 8859-16，ASRO SR 14111 | 罗马尼亚语 | Yes | 1 | ISO885916 |
| MULE_INTERNAL | Mule 内部编码 | 多种语言的Emacs | Yes | 1-4 | |
| SJIS | Shift JIS | 日语 | No | 1-2 | Mskanji, ShiftJIS, WIN932, Windows932 |
| SHIFT_JIS_2004 | Shift JIS, JIS X 0213 | 日语 | No | 1-2 | |
| SQL_ASCII | 未指明的 (see text) | 任意 | Yes | 1 | |
| UHC | 统一的Hangul代码 | 韩语 | No | 1-2 | WIN949, Windows949 |
| UTF8 | Unicode, 8-bit | 所有 | Yes | 1-4 | Unicode |
| WIN866 | Windows CP866 | 斯拉夫语 | Yes | 1 | ALT |
| WIN874 | Windows CP874 | 泰语 | Yes | 1 | |
| WIN1250 | Windows CP1250 | 中欧语 | Yes | 1 | |
| WIN1251 | Windows CP1251 | 斯拉夫语 | Yes | 1 | WIN |
| WIN1252 | Windows CP1252 | 东欧语 | Yes | 1 | |
| WIN1253 | Windows CP1253 | 希腊语 | Yes | 1 | |
| WIN1254 | Windows CP1254 | 土耳其语 | Yes | 1 | |
| WIN1255 | Windows CP1255 | 希伯来语 | Yes | 1 | |
| WIN1256 | Windows CP1256 | 阿拉伯语 | Yes | 1 | |
| WIN1257 | Windows CP1257 | 波罗的语 | Yes | 1 | |
| WIN1258 | Windows CP1258 | 越南语 | Yes | 1 | ABC, TCVN, TCVN5712, VSCII |
不是所有的客户端的API都支持上面列出来的字符集。例如，PostgreSQL的JDBC驱动不支持MULE_INTERNAL, LATIN6, LATIN8, and LATIN10.
SQL_ASCII设置的行为跟其他的设置不同。当服务器字符集设置成SQL_ASCII，服务器解释的字节的值跟ASCII标准一样在0-127之间，当设置是SQL-ASCII时，编码将不会进行转换。然而当字节的值在128-255之间时将不能解释这个字符。因此，此设置与其说是一个对正在使用的特定的编码方式的声明，不如说是一个忽略编码方式的声明。在大多数情况下，如果你在是用任何非ASCII数据，是用SQL_ASCII将是非常不明智的，因为PostgreSQL不能帮助你进行转换使这些非ASCII字符有效。
22.3.2.设置字符集
initdb为一个PostgreSQL集群定义一个默认的字符集。例如，
initdb -E EUC_JP
将默认的字符集设置成EUC_JP（用于日语的扩张的Unix编码）。如果你喜欢长选项的字符串，你也可以用--encoding代替-E选项。如果没有指定-E或者--encoding选项，initdb将根据指定或者默认的区域来尝试确定合适的编码。
你也可以在数据库创建的时候指定一个非默认的编码，提供的这个编码应该和选择的区域兼容：
createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean
这将创建一个字符集为EUC_KR，区域为ko_KR，名字为korean的数据库，另一种方法的实现是使用下面的SQL命令：
CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0;
请注意，以上的命令将会以template0数据库作为模板进行拷贝。当拷贝任何一个其他的数据库时，编码和区域设置将不能从源数据库中进行更改，因为，这可能会破坏数据。更多多信息见Section 21.3.
这是存储在系统目录pg_database中的一个数据库的编码。你可以用psql -l或者\l命令来查看它。
$ psql -l
List of databases
Name | Owner | Encoding | Collation | Ctype | Access Privileges
-----------+----------+-----------+-------------+-------------+-------------------------------------
clocaledb | hlinnaka | SQL_ASCII | C | C |
englishdb | hlinnaka | UTF8 | en_GB.UTF8 | en_GB.UTF8 |
japanese | hlinnaka | UTF8 | ja_JP.UTF8 | ja_JP.UTF8 |
korean | hlinnaka | EUC_KR | ko_KR.euckr | ko_KR.euckr |
postgres | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 |
template0 | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
template1 | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
(7 rows)
重要：在大多数现代操作系统上，PostgreSQL能够确定用LC_CTYPE设置的隐含的字符集，如果和数据库编码相匹配时它将会被强制使用。在老的系统上，确定你想要选择的区域编码是你的责任。如果在这个范围内有错误，将会导致区域相关的操作发生奇怪的行为，如排序操作。
PostgreSQL允许超级用户用SQL_ASCII编码创建数据库，即使LC_CTYPE不是C或者POSIX类型。如上所述，如果存储在数据库中的数据有特定的编码，SQL_ASCII将不会被强制执行，所以这个选择将造成与区域相关的行为违规的风险。
22.3.3. 客户端和服务端自动字符集转换
PostgreSQL支持客户端和服务器之间用某些字符集组合进行字符集自动转换。这个转换信息存储在系统目录pg_conversion里面。PostgreSQL自带了一些预定义的转换，它们在 Table 22-2中列出。你也可以用SQL命令CREATE CONVERSION创建一个新的转换。
Table 22-2. 客户/服务器字符集转换
| 服务器字符集 | 可用的客户端字符集 |
| BIG5 | 不支持作为服务器的编码 |
| ENC_CN | EUC_CN, MULE_INTERNAL, UTF8 |
| ENC_JP | EUC_JP, MULE_INTERNAL, SJIS, UTF8 |
| ENC_KR | EUC_KR, MULE_INTERNAL, UTF8 |
| ENC_TW | EUC_TW, BIG5, MULE_INTERNAL, UTF8 |
| GB18030 | 不支持作为服务器的编码 |
| GBK | 不支持作为服务器的编码 |
| ISO_8859_5 | ISO_8859_5, KOI8R, MULE_INTERNAL, UTF8, WIN866, WIN1251 |
| ISO_8859_6 | ISO_8859_6,UTF8 |
| ISO_8859_7 | ISO_8859_7,UTF8 |
| ISO_8859_8 | ISO_8859_8,UTF8 |
| JOHAB | JOHAB, UTF8 |
| KOI8R | KOI8R, ISO_8859_5, MULE_INTERNAL, UTF8, WIN866, WIN1251 |
| KOI8U | KOI8U, UTF8 |
| LATIN1 | LATIN1, MULE_INTERNAL, UTF8 |
| LATIN2 | LATIN2, MULE_INTERNAL, UTF8, WIN1250 |
| LATIN3 | LATIN3, MULE_INTERNAL, UTF8 |
| LATIN4 | LATIN4, MULE_INTERNAL, UTF8 |
| LATIN5 | LATIN5, UTF8 |
| LATIN6 | LATIN6, UTF8 |
| LATIN7 | LATIN7, UTF8 |
| LATIN8 | LATIN8, UTF8 |
| LATIN9 | LATIN9, UTF8 |
| LATIN10 | LATIN10, UTF8 |
| MULE_INTERNAL | MULE_INTERNAL, BIG5, EUC_CN, EUC_JP, EUC_KR, EUC_TW, ISO_8859_5, KOI8R, LATIN1 to LATIN4, SJIS, WIN866, WIN1250, WIN1251 |
| SJIS | 不支持作为服务器的编码 |
| SQL_ASCII | 任意（不会进行转换） |
| UTF8 | 所有支持的编码 |
| WIN866 | WIN866, ISO_8859_5, KOI8R, MULE_INTERNAL, UTF8, WIN1251 |
| WIN874 | WIN874, UTF8 |
| WIN1250 | WIN1250, LATIN2, MULE_INTERNAL, UTF8 |
| WIN1251 | WIN1251, ISO_8859_5, KOI8R, MULE_INTERNAL, UTF8, WIN866 |
| WIN1252 | WIN1252,UTF8 |
| WIN1253 | WIN1253,UTF8 |
| WIN1254 | WIN1254,UTF8 |
| WIN1255 | WIN1255,UTF8 |
| WIN1256 | WIN1256,UTF8 |
| WIN1257 | WIN1257,UTF8 |
| WIN1258 | WIN1258,UTF8 |
启用自动字符集转换，你需要告诉PostgreSQL你想在客户端用的字符集（编码）。这里有些方法可以实现：
在psql中用\encoding命令。\encoding允许你动态改变客户端的编码。例如，将编码改成SJIS类型：
\enconding SJIS
libpq(Section 31.9)有函数可以控制客户单编码。
用SET client_encoding TO，设置客户端的编码可以用这个SQL命令：
SET CLIENT_ENCODING TO 'value';
你也可以用SET NAMES这个标准的语法来完成这些：
SET NAMES 'value';
查询客户端的编码：
SHOW client_encoding;
回退到默认的编码：
RESET client_encoding；
使用PGCLIENTENCODING。如果在客户端的环境中定义了PGCLIENTENCODING环境变量，那么在与服务器连接时客户端将会自动选择编码。（这个编码可以用上面谈到的任何其它方法覆盖。）
使用client_encoding配置变量。如果设置了client_encoding变量，那么在与服务器连接时客户端将会自动选择编码。（这个编码可以用上面谈到的任何其它方法覆盖。）
如果一个特殊的字符不能进行转换--比如你选的服务器编码是EUC_JP，客户端是LATIN1，那么有些日文字符不能转换成LATIN1--这将报告一个错误。
如果客户端字符集定义的是SQL_ASCII，那么无论服务器的字符集是什么，编码转换将会被禁止。正如服务器一样，用SQL_ASCII编码是不明智的，除非你使用的是都是ASCII编码的数据。
22.3.4.进一步阅读
这里有一些开始学习不同编码系统的好地方。
http://www.i18ngurus.com/docs/984813247.html 这些文档收集了大量关于字符集，编码和代码页的信息。
CJKV信息处理：中文，日语，韩语和越南语计算
包含了EUC_JP, EUC_CN, EUC_KR, EUC_TW.的详细解释。
http://www.unicode.org/
这是Unicode协会的站点。
RFC 3629
这里定义了UTF-8（8位UCS/Unicode转换格式）
