PostgreSQL 字符编码总结

字符集可在 initdb、createdb、”create database” 时设定，每个数据库的字符集必须和 LC_CTYPE、LC_COLLATE 设置兼容，C 或 POSIX 区域兼容任意字符集，但其他区域只兼容一种字符集（在 Windows 上 UTF-8 编码可兼容任意区域）。

PostgreSQL 支持编码在服务端和前端之间的自动编码转换，也可以使用 SQL 命令创建一种编码转换。比如数据库使用了 EUC_JP 日文编码，但前端收到的是 UTF8 编码的数据，数据库内部会自动完成 UTF8 到 EUC_JP 的编码转换。

若数据库被设置为 SQL_ASCII 编码，字节值 [0, 127] 依据 ASCII 标准解释，[128, 255] 作为无法解析的字符，数据库不会做任何编码转换。也就是说，使用了非 ASCII 数据时，数据库不会转换编码，也不会校验非 ASCII 字符。

若客户端使用了 SQL_ASCII 编码发送 SQL 语句，那么数据库的自动编码转换会禁用，不管数据库的字符集是什么。

这种行为被允许但会被弃用：通过超级用户创建数据库，数据库编码为 SQL_ASCII，LC_CTYPE 不为 C 也不为 POSIX。

除非很明确地知道数据库内存入的数据都是 ASCII 数据，否则不建议将数据库编码设置为 SQL_ASCII ，也不建议客户端编码设置为 SQL_ASCII。

表格 Client/Server Character Set Conversions 显示了 PostgreSQL 支持的服务端/客户端的自动编码转换，比如数据库编码采用 EUC_JP，客户端可使用 EUC_JP、MULE_INTERNAL、SJIS、UTF8 编码，数据库内部就能够完成自动编码转换。若数据库采用 UTF8 编码，那么客户端使用任意编码都行。进一步地看，不管数据库使用什么编码，自动编码转换支持使用 UTF8 编码的客户端；不过有一个例外就是数据库采用 MULE_INTERNAL 编码，客户端使用 UTF8 时就无法做自动编码转换。

参考链接： Character Set Support

Advertisements