他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

23.3. 文字セットサポート

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

しかし重要な制限として、それぞれのデータベースの文字セットがサーバのLC_CTYPE(文字分類)およびLC_COLLATE(文字列並び替え順序)ロケール設定と互換性がなくてはいけないことがあげられます。 CもしくはPOSIXロケール設定の場合、どのような文字セットも許可されています。 しかし、libcが提供する他のロケール設定の場合、正しく動作する文字セットはひとつだけとなります。 (しかしWindowsではUTF-8符号化方式をどのロケールでも使用できます。) ICUサポートが組み込まれている場合は、サーバサイドのすべてではないにしても、ほとんどのエンコーディングで、ICUが提供する照合順序が利用できます。

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

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

表23.1 PostgreSQL文字セット

名前説明言語サーバ?ICU?バイト数/文字別名
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-4 
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ではない文字を変換したり検査したりすることは出来ないからです。

23.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データベースのコピーが指定されていることに注目してください。 他のデータベースからコピーする場合、データが破損する結果となる可能性がありますので、符号化方式とロケール設定を元のデータベースの設定から変更することはできません。 詳細については22.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は、データベースに保存されているデータが特定のエンコーディングを持つことを強制しません。さらに、この選択はロケールに依存したおかしな動作を引き起こすリスクを高めます。この設定の組み合わせを使用することは、お勧めできませんし、いつの日か完全に禁止されるかもしれません。

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

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

表23.2 クライアント・サーバ文字セット変換

サーバ文字セット利用可能なクライアント文字セット
BIG5サーバの符号化方式としてはサポートしていません。
EUC_CNEUC_CNMULE_INTERNALUTF8
EUC_JPEUC_JPMULE_INTERNALSJISUTF8
EUC_JIS_2004EUC_JIS_2004SHIFT_JIS_2004UTF8
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
JOHABサーバの符号化方式としてはサポートしていません。
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からLATIN4まで、 SJISWIN866WIN1250WIN1251
SJISサーバの符号化方式としてはサポートしていません。
SHIFT_JIS_2004サーバの符号化方式としてはサポートしていません。
SQL_ASCIIどれでも (変換されません)
UHCサーバの符号化方式としてはサポートしていません。
UTF8すべてサポートされています。
WIN866WIN866ISO_8859_5KOI8RMULE_INTERNALUTF8WIN1251
WIN874WIN874UTF8
WIN1250WIN1250LATIN2MULE_INTERNALUTF8
WIN1251WIN1251ISO_8859_5KOI8RMULE_INTERNALUTF8WIN866
WIN1252WIN1252UTF8
WIN1253WIN1253UTF8
WIN1254WIN1254UTF8
WIN1255WIN1255UTF8
WIN1256WIN1256UTF8
WIN1257WIN1257UTF8
WIN1258WIN1258UTF8

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

  • psql\encodingコマンドを使います。 \encodingは実行中であってもクライアントの符号化方式を変更させることができます。 例えば符号化方式をSJISに変えたい場合は次のように入力します。

    \encoding SJIS
    

  • libpq (34.10)はクライアントの符号化方式を制御する関数を保持しています。

  • SET client_encoding TOを使います。 次のSQLコマンドでクライアントの符号化方式を設定できます。

    SET CLIENT_ENCODING TO 'value';
    

    標準SQLの構文SET NAMESを同じ目的で使うこともできます。

    SET NAMES 'value';
    

    現在のクライアントの符号化方式を問い合わせるには次のようにします。

    SHOW client_encoding;
    

    デフォルトの符号化方式に戻すのには次のようにします。

    RESET client_encoding;
    

  • PGCLIENTENCODINGを使います。 クライアントの環境でPGCLIENTENCODING環境変数が定義されていると、サーバと接続が確立した時点で自動的にクライアントの符号化方式が選択されます (上で説明したその他のどんな方法でもその後書き換えできます)。

  • client_encoding変数を使います。 client_encoding変数が設定されていると、サーバとの接続が確立した時点で自動的にクライアントの符号化方式が選択されます (上で説明したその他のどんな方法でもその後書き換えできます)。

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

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

23.3.4. 推奨文書

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

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

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

http://www.unicode.org/

Unicode協会のWebサイトです。

RFC 3629

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