pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
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 位字符时发现 任何问题，请告诉我。）
在运行 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。
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)
对于某些编码，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环境变量，那么建立后端连接时会自动选择该前端编码。（之后仍可以用上面提到的任何其他方法覆盖它。）
从 PostgreSQL 7.1 开始支持 Unicode 与其他编码之间的自动编码翻译。 因为这需要巨大的转换表，所以它默认不启用。 要启用这个特性，运行 configure 时带上 --enable-unicode-conversion 选项。注意这还要求同时带 --enable-multibyte 选项。
假设你为后端选择了 EUC_JP， 为前端选择了 LATIN1， 那么某些日语字符无法翻译为 LATIN1。在 这种情况下，无法用 LATIN1 字符集表示的字母 会被变换为：
(HEXA DECIMAL)
这些都是开始了解各种编码系统的良好资料。
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 2044 UTF-8 在这里定义。
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 发布
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 中。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。