22.3. 文字セットサポート

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

しかし重要な制限は、それぞれのデータベースの文字セットがサーバのLC_CTYPE(文字分類)およびLC_COLLATE(文字列並び替え順序)ロケール設定と互換性がなくてはいけません。 CもしくはPOSIXロケール設定の場合、どのような文字セットも許可されています。 しかし、他のロケール設定の場合、正しく動作する文字セットはひとつだけとなります。 (しかしWindowsではUTF-8符号化方式をどのロケールでも使用できます。)

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

PostgreSQLで使用できる文字セットを表22-1に示します。

表 22-1. PostgreSQL文字セット

名前説明言語サーバ?バイト数/文字別名
BIG5Big Five繁体字いいえ1-2WIN950Windows950
EUC_CNExtended UNIX Code-CN簡体字はい1-3 
EUC_JPExtended UNIX Code-JP日本語はい1-3 
EUC_JIS_2004Extended UNIX Code-JP, JIS X 0213日本語はい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 
KOI8RKOI8-Rキリル文字(ロシア)はい1KOI8
KOI8UKOI8-Uキリル文字(ウクライナ)はい1 
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内部コード多言語Emacsはい1-4 
SJISShift JIS日本語いいえ1-2MskanjiShiftJISWIN932Windows932
SHIFT_JIS_2004Shift JIS, JIS X 0213日本語いいえ1-2 
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 
WIN1253Windows CP1253ギリシャはい1 
WIN1254Windows CP1254トルコはい1 
WIN1255Windows CP1255ヘブライはい1 
WIN1256Windows CP1256アラビア語はい1 
WIN1257Windows CP1257バルト語派はい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ではない文字を変換したり検査したりすることは出来ないからです。

22.3.2. 文字セットの設定

initdbPostgreSQLクラスタのデフォルト文字セット(エンコーディング)を定義します。 以下に例を示します。

initdb -E EUC_JP

これはデフォルトの文字セットをEUC_JP(日本語拡張Unixコード)に設定します。 より長いオプションの文字列がお好みなら-Eの代わりに--encodingと書くこともできます。 -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データベースのコピーが指定されていることに注目してください。 他のデータベースからコピーする場合、データが破損する結果となる可能性がありますので、符号化方式とロケール設定を元のデータベースの設定から変更することはできません。 詳細については項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は、LC_CTYPECもしくはPOSIXでもない場合にも、スーパユーザがSQL_ASCIIエンコーディングでデータベースを作成することを許可します。上記のように、SQL_ASCIIは、データベースに保存されているデータが特定のエンコーディングを持つことを強制しません。さらに、この選択はロケールに依存したおかしな動作を引き起こすリスクを高めます。この設定の組み合わせを使用することは、お勧めできませんし、いつの日か完全に禁止されるかもしれません。

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

PostgreSQLは、ある文字セットの組み合わせに対してサーバとクライアントの間で自動的に文字セットを変換する機能を提供しています。 変換情報はpg_conversionシステムカタログに格納されています。PostgreSQLには、表22-2で示されているように、事前に定義された変換が付属します。 新しい変換を作成するにはSQLコマンドのCREATE CONVERSIONを使用します。

表 22-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
KOI8RKOI8RISO_8859_5MULE_INTERNALUTF8WIN866WIN1251
KOI8UKOI8UUTF8
LATIN1LATIN1MULE_INTERNALUTF8
LATIN2LATIN2MULE_INTERNALUTF8WIN1250
LATIN3LATIN3MULE_INTERNALUTF8
LATIN4LATIN4MULE_INTERNALUTF8
LATIN5LATIN5UTF8
LATIN6LATIN6UTF8
LATIN7LATIN7UTF8
LATIN8LATIN8UTF8
LATIN9LATIN9UTF8
LATIN10LATIN10UTF8
MULE_INTERNALMULE_INTERNALBIG5EUC_CNEUC_JPEUC_KREUC_TWISO_8859_5KOI8RLATIN1 to LATIN4SJISWIN866WIN1250WIN1251
SJISサーバの符号化方式としてはサポートしていません。
SQL_ASCIIどれでも (変換されません)
UHCサーバの符号化方式としてはサポートしていません。
UTF8すべてサポートされています。
WIN866WIN866ISO_8859_5KOI8RMULE_INTERNALUTF8WIN1251
WIN874WIN874UTF8
WIN1250WIN1250LATIN2MULE_INTERNALUTF8
WIN1251WIN1251ISO_8859_5KOI8RMULE_INTERNALUTF8WIN866
WIN1252WIN1252UTF8
WIN1253WIN1253, UTF8
WIN1254WIN1254, UTF8
WIN1255WIN1255, UTF8
WIN1256WIN1256UTF8
WIN1257WIN1257, UTF8
WIN1258WIN1258UTF8

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

EUC_JPをサーバに、そしてLATIN1をクライアントに選んだ場合のように、 特定の文字の変換ができない時、日本語文字はLATIN1に入っていないという旨の日本語が返され、エラーが報告されます。

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

22.3.4. 推奨文書

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

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

文字セット、エンコーディングについてのドキュメントの集まりです。

CJKV日中韓越情報処理: 中国語、日本語、韓国語 & ベトナム語処理

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

http://www.unicode.org/

Unicode協会のWebサイトです。

RFC 3629

ここでUTF-8(8ビットUCS/Unicode変換書式)が定義されています。