5.2. 多字节支持 #
作者
Tatsuo Ishii（<ishii@postgresql.org>），最后更新于 2000-03-22。更多信息请查看Tatsuo 的网站。
多字节（MB）支持旨在让 Postgres能够处理多字节字符集，例如 EUC（扩展 Unix 编码）、Unicode 和 Mule 内部编码。启用MB后，你可以在正则表达式（regexp）、LIKE 以及其他一些函数中使用多字节字符集。默认编码系统是在使用initdb初始化 Postgres安装时选定的。注意，这可以在你使用createdb创建数据库或使用 SQL 命令 CREATE DATABASE 时被覆盖。因此你可以拥有多个数据库，并让每个数据库使用不同的编码系统。
MB还修复了一些与 8 位单字节字符集（包括 ISO8859）有关的问题。（我不能说所有问题都已修复。我只是确认了回归测试运行正常，而且补丁可以使用几个法语字符。如果你在使用 8 位字符时发现任何问题，请告诉我。）
5.2.1. 启用 MB
在运行 configure 时带上多字节选项：
% ./configure --enable-multibyte[=encoding_system]
其中encoding_system可以是下表中的值之一：
表 5.1. Postgres 字符集编码
| 编码 | 描述 |
|---|---|
| SQL_ASCII | ASCII |
| EUC_JP | 日语 EUC |
| EUC_CN | 中文 EUC |
| EUC_KR | 韩语 EUC |
| EUC_TW | 台湾 EUC |
| UNICODE | Unicode（UTF-8） |
| MULE_INTERNAL | Mule 内部 |
| LATIN1 | ISO 8859-1 英语和某些欧洲语言 |
| LATIN2 | ISO 8859-2 英语和某些欧洲语言 |
| LATIN3 | ISO 8859-3 英语和某些欧洲语言 |
| LATIN4 | ISO 8859-4 英语和某些欧洲语言 |
| LATIN5 | ISO 8859-5 英语和某些欧洲语言 |
| KOI8 | KOI8-R(U) |
| WIN | Windows CP1251 |
| ALT | Windows CP866 |
这里有一个把Postgres默认配置为使用日语编码的例子：
% ./configure --enable-multibyte=EUC_JP
如果省略了编码系统（./configure --enable-multibyte），则假定使用 SQL_ASCII。
5.2.2. 设置编码
initdb为Postgres 安装定义默认编码。例如：
% initdb -E EUC_JP
这会把默认编码设为 EUC_JP（日语的扩展 Unix 编码）。注意，如果你喜欢较长的选项形式，也可以用"--encoding"代替"-E"。如果没有给出 -E 或 --encoding 选项，就使用在 configure 时指定的编码。
你可以创建使用不同编码的数据库：
% createdb -E EUC_KR korean
这会创建一个名为"korean"的数据库，使用 EUC_KR 编码。另一种实现方式是使用 SQL 命令：
CREATE DATABASE korean WITH ENCODING = 'EUC_KR';
数据库的编码表示为pg_database系统目录中的一个编码列。可以通过
psql 的 -l 或 \l
命令查看它。
$ psql -l
List of databases
Database | Owner | Encoding
---------------+---------+---------------
euc_cn | t-ishii | EUC_CN
euc_jp | t-ishii | EUC_JP
euc_kr | t-ishii | EUC_KR
euc_tw | t-ishii | EUC_TW
mule_internal | t-ishii | MULE_INTERNAL
regression | t-ishii | SQL_ASCII
template1 | t-ishii | EUC_JP
test | t-ishii | EUC_JP
unicode | t-ishii | UNICODE
(9 rows)
5.2.3. 后端和前端之间的自动编码翻译
对于某些编码，Postgres支持在后端和前端之间进行自动编码翻译。
表 5.2. Postgres 客户端/服务器字符集编码
| 服务器编码 | 可用的客户端编码 |
|---|---|
| EUC_JP | EUC_JP, SJIS |
| EUC_TW | EUC_TW, BIG5 |
| LATIN2 | LATIN2, WIN1250 |
| LATIN5 | LATIN5, WIN, ALT |
| MULE_INTERNAL | EUC_JP, SJIS, EUC_KR, EUC_CN, EUC_TW, BIG5, LATIN1 to LATIN5, WIN, ALT, WIN1250 |
若要启用自动编码翻译，必须告诉Postgres 你希望前端使用哪种编码。有几种方法可以做到这一点。
在psql中使用
\encoding命令。\encoding允许动态更改前端编码。例如，要把编码改成 SJIS，可以输入：\encoding SJIS
使用 libpq 函数。
\encoding实际上就是为此目的调用 PQsetClientEncoding() 的。int PQsetClientEncoding(PGconn *
conn, const char *encoding)其中
conn是到后端的连接，encoding是你想使用的编码。如果成功设置了编码，它返回 0，否则返回 -1。此连接的当前编码可以通过下面的函数得到：int PQclientEncoding(const PGconn *
conn)注意它返回的是“编码 ID”，而不是像"EUC_JP"这样的编码符号字符串。要把编码 ID 转换为编码符号，可以使用：
char *pg_encoding_to_char(int
encoding_id)使用
SET CLIENT_ENCODING TO。可以使用以下 SQL 命令设置前端侧的编码：SET CLIENT_ENCODING TO 'encoding';
也可以为此使用 SQL92 语法"SET NAMES"：
SET NAMES 'encoding';
要查询当前的前端编码：
SHOW CLIENT_ENCODING;
要返回到默认编码：
RESET CLIENT_ENCODING;
使用
PGCLIENTENCODING。如果在客户端环境中定义了PGCLIENTENCODING环境变量，那么建立后端连接时会自动选择该前端编码。（之后仍可以用上面提到的任何其他方法覆盖它。）
5.2.4. 关于 Unicode
从 PostgreSQL 7.1 开始支持 Unicode 与其他编码之间的自动编码翻译。因为这需要巨大的转换表，所以它默认不启用。要启用这个特性，运行 configure 时带上 --enable-unicode-conversion 选项。注意这还要求同时带 --enable-multibyte 选项。
5.2.5. 如果无法完成转换会怎样？
假设你为后端选择了 EUC_JP，为前端选择了 LATIN1，那么某些日语字符无法翻译为 LATIN1。在这种情况下，无法用 LATIN1 字符集表示的字母会被变换为：
(HEXA DECIMAL)
5.2.6. 参考资料
这些都是开始了解各种编码系统的良好资料。
ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf 对 EUC_JP、EUC_CN、EUC_KR、EUC_TW 的详细说明见 3.2 节。
Unicode：http://www.unicode.org/ UNICODE 的主页。
RFC 2044UTF-8 在这里定义。
5.2.7. 历史
Dec 7, 2000 * 实现了 Unicode 与其他编码之间的自动编码转换 * 以上变更将出现在 7.1 中 May 20, 2000 * SJIS UDC（NEC 选定 IBM 汉字）支持，由 Eiji Tokuya 贡献 * 以上变更将出现在 7.0.1 中 Mar 22, 2000 * 新增 libpq 函数 PQsetClientEncoding、PQclientEncoding * ./configure --with-mb=EUC_JP 已废弃。请改用 ./configure --enable-multibyte=EUC_JP * 新增 SQL_ASCII 回归测试用例 * 新增 SJIS 用户自定义字符（UDC）支持 * 以上全部将出现在 7.0 中 July 11, 1999 * 新增对 WIN1250（Windows 捷克语）作为客户端编码的支持（由 Pavel Behal 贡献） * 修复一些编译器警告（由 Tomoaki Nishiyama 贡献） Mar 23, 1999 * 新增对 KOI8(KOI8-R)、WIN(CP1251)、ALT(CP866) 的支持（感谢 Oleg Broytmann 测试） * 修复 MB 与 locale 相关的问题 Jan 26, 1999 * 新增 Big5 作为前端编码的支持（要使用 Big5，需用 EUC_TW 创建数据库） * 新增 EUC_TW 的回归测试用例（由 Jonah Kuo<jonahkuo@mail.ttn.com.tw>) Dec 15, 1998 * 修复了与 SQL_ASCII 支持相关的一些错误 Nov 5, 1998 * 6.4 发布。此版本中，pg_database 增加了表示数据库编码的 "encoding" 列 Jul 22, 1998 * 在 initdb/createdb 时确定编码，而非编译时 * 在发出 COPY 命令时支持 PGCLIENTENCODING * 支持 SQL92 语法 "SET NAMES" * 支持 LATIN2-5 * 新增 UNICODE 回归测试用例 * 新的 MB 测试套件 * 清理源代码文件 Jun 5, 1998 * 新增后端与前端之间的编码转换支持 * 新增 SET CLIENT_ENCODING 等新命令 * 新增 LATIN1 字符集支持 * enhance 8 bit cleaness April 21, 1998 一些增强/修复 * character_length()、position()、substring() 现在能识别多字节字符 * 新增 octet_length() * 为 configure 新增 --with-mb 选项 * 新的 EUC_KR 回归测试（由 Soonmyung Hong<hong@lunaris.hanmesoft.co.kr>贡献） * 为 EUC_JP 回归测试新增一些测试用例 * 修复 System V 情况下 regress/regress.sh 中的问题 * 修复 toupper()、tolower() 以处理 8 位字符 Mar 25, 1998 MB PL2 被并入 PostgreSQL 6.3.1 Mar 10, 1998 PL2 发布 * 为 EUC_JP、EUC_CN 和 MULE_INTERNAL 新增回归测试 * 新增一份英文文档（本文件） * 修复与 8 位单字节字符有关的问题 Mar 1, 1998 PL1 发布
5.2.8. Windows/ODBC 上的 WIN1250
Windows 客户端平台上的 WIN1250 字符集可以配合启用了区域支持的 Postgres使用。
应记住以下几点：
成功与否取决于正确的系统区域设置。这已经在 RH6.0 和 Slackware 3.6 上用 cs_CZ.iso8859-2 区域测试过。
决不要尝试把服务器多字节数据库编码设为 WIN1250。始终改用 LATIN2，因为 Unix 中没有 WIN1250 区域。
WIN1250 编码只对 M$W ODBC 客户端可用。字符会被动态转码，以便正确显示和存回。
运行时，重要的是记住以下几点：
这种配置会根据你的
LC_设置重排你的排序顺序。不要因为回归测试结果而困惑，因为它们不使用区域。x像"
ch"这样的区域只有在你的系统支持该区域时才能正确排序；较老的系统可能做不到，但新的系统（例如 RH6.0）可以。你必须以'
162,50'的形式插入货币值（注意单引号内的逗号）。在撰写本文时（1999 年初），这种配置还没有经过广泛测试。如果你不得不做任何修改，请告诉我们！
Windows/ODBC 上的 WIN1250
在启用区域支持、多字节编码设为
LATIN2的情况下编译 Postgres。设置你的安装。不要忘记在你的 profile（环境）中创建区域变量。例如（这可能不适用于你的环境）：
LC_ALL=cs_CZ.ISO8859-2 LC_COLLATE=cs_CZ.ISO8859-2 LC_CTYPE=cs_CZ.ISO8859-2 LC_MONETARY=cs_CZ.ISO8859-2 LC_NUMERIC=cs_CZ.ISO8859-2 LC_TIME=cs_CZ.ISO8859-2必须带着区域设置启动 postmaster！
用捷克语试一试，并在查询上进行排序。
在你的 M$ Windows 机器上为 PgSQL 安装 ODBC 驱动。
正确设置你的数据源。在 ODBC 配置对话框的
Connect Settings字段中加入这一行：SET CLIENT_ENCODING = 'WIN1250';现在再试一次，但这次是在带 ODBC 的 Windows 中。