21.2. 文字セットサポート

PostgreSQLの文字セットサポートにより、ISO 8859シリーズなどのシングルバイト文字やEUC(拡張Unixコード)、UTF-8、Mule内部コードなどのマルチバイト文字を含む、各種文字セットでテキストを保存することができます。 全ての文字セットはサーバに対して透過的に使用することができます (他のソースからの拡張関数を使用している場合は、そのコードが正しく作成されているかどうかに依存します)。 デフォルトの文字セットは、initdbを使用したPostgreSQLデータベースクラスタの初期化時に決定されます。 これは、createdbもしくはCREATE DATABASE SQLコマンドを使用してデータベースを作成する時に上書きすることができます。 ですから、異なる文字セットを使用した複数のデータベースを持つことができます。

21.2.1. サポートされる文字セット

サーバで使用できる文字セットを表21-1に示します。

表 21-1. サーバ文字セット

名前説明言語バイト数/文字別名
BIG5Big Five従来の中国語1-2WIN950Windows950
EUC_CNExtended UNIX Code-CN簡易中国語1-3 
EUC_JPExtended UNIX Code-JP日本語1-3 
EUC_KRExtended UNIX Code-KR韓国語1-3 
EUC_TWExtended UNIX Code-TW従来の中国語、台湾語1-3 
GB18030National Standard中国語1-2 
GBKExtended National Standard簡易中国語1-2WIN936Windows936
ISO_8859_5ISO 8859-5、ECMA 113ラテン/キリル1 
ISO_8859_6ISO 8859-6、ECMA 114ラテン/アラビア語1 
ISO_8859_7ISO 8859-7、ECMA 118ラテン/ギリシャ語1 
ISO_8859_8ISO 8859-8、ECMA 121ラテン/ヘブライ語1 
JOHABJOHAB韓国語(ハングル語)1-3 
KOI8KOI8-R(U)キリル語1KOI8R
LATIN1ISO 8859-1、ECMA 94西ヨーロッパ1ISO88591
LATIN2ISO 8859-2、ECMA 94中央ヨーロッパ1ISO88592
LATIN3ISO 8859-3、ECMA 94南ヨーロッパ1ISO88593
LATIN4ISO 8859-4、ECMA 94北ヨーロッパ1ISO88594
LATIN5ISO 8859-9、ECMA 128トルコ1ISO88599
LATIN6ISO 8859-10、ECMA 144北欧1ISO885910
LATIN7ISO 8859-13バルト諸国1ISO885913
LATIN8ISO 8859-14ケルト1ISO885914
LATIN9ISO 8859-15LATIN1でヨーロッパと訛りを含む1ISO885915
LATIN10ISO 8859-16、ASRO SR 14111ルーマニア1ISO885916
MULE_INTERNALMule内部コード多言語Emacs1-4 
SJISShift JIS日本語1-2MskanjiShiftJISWIN932Windows932
SQL_ASCII未指定(テキストを参照)英語1 
UHC統合ハングルコード韓国語1-2WIN949Windows949
UTF8Unicode、8ビットすべて1-4Unicode
WIN866Windows CP866キリル語1ALT
WIN874Windows CP874タイ語1 
WIN1250Windows CP1250中央ヨーロッパ1 
WIN1251Windows CP1251キリル語1WIN
WIN1252Windows CP1252西ヨーロッパ1 
WIN1256Windows CP1256アラビア語1 
WIN1258Windows CP1258ベトナム語1ABCTCVNTCVN5712VSCII

全てのAPIが上の一覧表に示した文字セットをサポートしているわけではありません。 例えばPostgreSQL JDBCドライバはMULE_INTERNALLATIN6LATIN8、そしてLATIN10をサポートしません。

SQL_ASCIIの設定は、他の設定とかなり異なります。サーバのキャラクタセットがSQL_ASCIIのとき、サーバは0から127のバイト値をASCIIに変換します。一方、128から255までは変換されません。 設定がSQL_ASCIIの場合は、符号化は実行されません。よって、この設定は特定の符号化を使用している場合には、その符号化を無視するようになってしまいます。 多くの場合、ASCIIではない環境で作業する場合はSQL_ASCIIの設定を使用するのは、賢いことではありません。なぜならPostgreSQLはASCIIではない文字を変換したり検査したりすることは出来ないからです。

21.2.2. 文字セットの設定

initdbPostgreSQLクラスタのデフォルト文字セットを定義します。 以下に例を示します。

initdb -E EUC_JP

これはデフォルトの文字セット(符号化方式)をEUC_JP(日本語拡張Unixコード)に設定します。 より長いオプションの文字列を入力するのがお好みなら-Eの代わりに77encodingと書くこともできます。 -Eオプションも77encodingオプションも与えられない場合、initdbは、指定もしくはデフォルトのロケールに基づいて適当な符号化方式を決定しようとします。

異なる文字セットのデータベースを作成することができます。

createdb -E EUC_KR korean

これはEUC_KR文字セットでkoreanという名前のデータベースを作成します。 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
 postgres      | t-ishii | EUC_JP
 regression    | t-ishii | SQL_ASCII
 template1     | t-ishii | EUC_JP
 test          | t-ishii | EUC_JP
 utf8          | t-ishii | UTF8
(9 rows)

重要項目: データベースに対して好みの符号化方式を任意に指定することができますが、選択したロケールが想定していない符号化方式を選択することはお勧めしません。 LC_COLLATE設定とLC_CTYPE設定は、暗黙的な特定の符号化方式を意味していますので、互換性のない符号化方式でロケールに依存した操作(ソート処理など)を行うと、データを間違って解釈してしまいます。

これらのロケール設定はinitdbで固定化されます。 1つのクラスタにおいて、異なるデータベースに異なる符号化方式を使用できるという、この見かけ上の柔軟性は現実的ではなく、理論に走ったものと言えます。 将来のバージョンのPostgreSQLで、これらの機構を変更する予定です。

安全に複数の符号化方式を使用する方法の1つとして、initdb時にロケールをCもしくはPOSIXに設定する方法があります。 これにより、ロケールを意識する必要がまったくなくなります。

21.2.3. サーバ・クライアント間の自動文字セット変換

PostgreSQLは、特定の文字セットに対してサーバとクライアントの間で自動的に文字セットを変換する機能を提供しています。 変換情報はpg_conversionシステムカタログに格納されています。 新しい変換を作成するにはCREATE CONVERSIONを使用します。 PostgreSQLには定義済みの変換がいくつか用意されています。 表21-2に定義済みの変換を示します。

表 21-2. クライアント・サーバ文字セット変換

サーバ文字セット利用可能なクライアント文字セット
BIG5サーバの符号化方式としてはサポートしていません。
EUC_CNEUC_CNMULE_INTERNALUTF8
EUC_JPEUC_JPMULE_INTERNALSJISUTF8
EUC_KREUC_KRMULE_INTERNALUTF8
EUC_TWEUC_TWBIG5MULE_INTERNALUTF8
GB18030サーバの符号化方式としてはサポートしていません。
GBKサーバの符号化方式としてはサポートしていません。
ISO_8859_5ISO_8859_5KOI8MULE_INTERNALUTF8WIN866WIN1251
ISO_8859_6ISO_8859_6UTF8
ISO_8859_7ISO_8859_7UTF8
ISO_8859_8ISO_8859_8UTF8
JOHABJOHABUTF8
KOI8KOI8ISO_8859_5MULE_INTERNALUTF8WIN866WIN1251
LATIN1LATIN1MULE_INTERNALUTF8
LATIN2LATIN2MULE_INTERNALUTF8WIN1250
LATIN3LATIN3MULE_INTERNALUTF8
LATIN4LATIN4MULE_INTERNALUTF8
LATIN5LATIN5UTF8
LATIN6LATIN6UTF8
LATIN7LATIN7UTF8
LATIN8LATIN8UTF8
LATIN9LATIN9UTF8
LATIN10LATIN10UTF8
MULE_INTERNALMULE_INTERNALBIG5EUC_CNEUC_JPEUC_KREUC_TWISO_8859_5KOI8LATIN1 to LATIN4SJISWIN866WIN1250WIN1251
SJISサーバの符号化方式としてはサポートしていません。
SQL_ASCIIどれでも (変換されません)
UHCサーバの符号化方式としてはサポートしていません。
UTF8すべてサポートされています。
WIN866WIN866ISO_8859_5KOI8MULE_INTERNALUTF8WIN1251
WIN874WIN874UTF8
WIN1250WIN1250LATIN2MULE_INTERNALUTF8
WIN1251WIN1251ISO_8859_5KOI8MULE_INTERNALUTF8WIN866
WIN1252WIN1252UTF8
WIN1256WIN1256UTF8
WIN1258WIN1258UTF8

自動文字セット変換を有効にするためには、クライアントでどのような文字セット(符号化方式)を使用させたいかをPostgreSQLに伝えなければなりません。 これを行うにはいくつかの方法があります。

特定の文字の変換ができなかった場合、括弧で括った16進数で表したバイト値、例えば、(826C)に変換されます。 サーバ用にEUC_JPを、クライアント用にLATIN1を選択したとすると、日本語の文字の中にはLATIN1に変換できないものがあります。

クライアント側のキャラクタセットがSQL_ASCIIに定義されている場合は、符号化変換はサーバ側のキャラクタセットに関係無く無効化されます。 サーバ側と同じように、SQL_ASCIIを使用することは、すべてASCIIのデータを扱っている場合を除き、賢い方法ではありません。

21.2.4. 推奨文書

ここに記したものは様々な符号化方式システムを学習するのに良い資料です。

http://www.i18ngurus.com/docs/984813247.html

An extensive collection of documents about character sets, encodings, and code pages.

ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf

3.2節にEUC_JPEUC_CNEUC_KREUC_TWの詳しい説明があります。

http://www.unicode.org/

Unicode協会のWebサイトです。

RFC 2044

ここでUTF-8が定義されています。