無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

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 文字セット

名前 説明 言語 サーバ? バイト数/文字 別名
BIG5 Big Five 繁体字 いいえ 1-2 WIN950 Windows950
EUC_CN Extended UNIX Code-CN 簡体字 はい 1-3  
EUC_JP Extended UNIX Code-JP 日本語 はい 1-3  
EUC_JIS_2004 Extended UNIX Code-JP, JIS X 0213 日本語 はい 1-3  
EUC_KR Extended UNIX Code-KR 韓国語 はい 1-3  
EUC_TW Extended UNIX Code-TW 繁体字、台湾語 はい 1-3  
GB18030 National Standard 中国語 いいえ 1-2  
GBK Extended National Standard 簡体字 いいえ 1-2 WIN936 Windows936
ISO_8859_5 ISO 8859-5、 ECMA 113 ラテン/キリル はい 1  
ISO_8859_6 ISO 8859-6、 ECMA 114 ラテン/アラビア語 はい 1  
ISO_8859_7 ISO 8859-7、 ECMA 118 ラテン/ギリシャ語 はい 1  
ISO_8859_8 ISO 8859-8、 ECMA 121 ラテン/ヘブライ語 はい 1  
JOHAB JOHAB 韓国語(ハングル) いいえ 1-3  
KOI8R KOI 8-R キリル文字(ロシア) はい 1 KOI8
KOI8U KOI 8-U キリル文字(ウクライナ) はい 1  
LATIN1 ISO 8859-1、 ECMA 94 西ヨーロッパ はい 1 ISO88591
LATIN2 ISO 8859-2、 ECMA 94 中央ヨーロッパ はい 1 ISO88592
LATIN3 ISO 8859-3、 ECMA 94 南ヨーロッパ はい 1 ISO88593
LATIN4 ISO 8859-4、 ECMA 94 北ヨーロッパ はい 1 ISO88594
LATIN5 ISO 8859-9、 ECMA 128 トルコ はい 1 ISO88599
LATIN6 ISO 8859-10、 ECMA 144 北欧 はい 1 ISO885910
LATIN7 ISO 8859-13 バルト語派 はい 1 ISO885913
LATIN8 ISO 8859-14 ケルト はい 1 ISO885914
LATIN9 ISO 8859-15 LATIN1でヨーロッパと訛りを含む はい 1 ISO885915
LATIN10 ISO 8859-16、 ASRO SR 14111 ルーマニア はい 1 ISO885916
MULE_INTERNAL Mule内部コード 多言語Emacs はい 1-4  
SJIS Shift JIS 日本語 いいえ 1-2 Mskanji ShiftJIS WIN932 Windows932
SHIFT_JIS_2004 Shift JIS, JIS X 0213 日本語 いいえ 1-2  
SQL_ASCII 未指定(テキストを参照) 何でも はい 1  
UHC 統合ハングルコード 韓国語 いいえ 1-2 WIN949 Windows949
UTF8 Unicode、8ビット すべて はい 1-4 Unicode
WIN866 Windows CP866 キリル文字 はい 1 ALT
WIN874 Windows CP874 タイ語 はい 1  
WIN1250 Windows CP1250 中央ヨーロッパ はい 1  
WIN1251 Windows CP1251 キリル文字 はい 1 WIN
WIN1252 Windows CP1252 西ヨーロッパ はい 1  
WIN1253 Windows CP1253 ギリシャ はい 1  
WIN1254 Windows CP1254 トルコ はい 1  
WIN1255 Windows CP1255 ヘブライ はい 1  
WIN1256 Windows CP1256 アラビア語 はい 1  
WIN1257 Windows CP1257 バルト語派 はい 1  
WIN1258 Windows CP1258 ベトナム語 はい 1 ABC TCVN TCVN5712 VSCII

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

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

22.3.2. 文字セットの設定

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

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_CTYPE C もしくは POSIX でもない場合にも、スーパユーザが SQL_ASCII エンコーディングでデータベースを作成することを許可します。上記のように、 SQL_ASCII は、データベースに保存されているデータが特定のエンコーディングを持つことを強制しません。さらに、この選択はロケールに依存したおかしな動作を引き起こすリスクを高めます。この設定の組み合わせを使用することは、お勧めできませんし、いつの日か完全に禁止されるかもしれません。

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

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

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

サーバ文字セット 利用可能なクライアント文字セット
BIG5 サーバの符号化方式としてはサポートしていません。
EUC_CN EUC_CN MULE_INTERNAL UTF8
EUC_JP EUC_JP MULE_INTERNAL SJIS UTF8
EUC_KR EUC_KR MULE_INTERNAL UTF8
EUC_TW EUC_TW BIG5 MULE_INTERNAL UTF8
GB18030 サーバの符号化方式としてはサポートしていません。
GBK サーバの符号化方式としてはサポートしていません。
ISO_8859_5 ISO_8859_5 KOI8 MULE_INTERNAL UTF8 WIN866 WIN1251
ISO_8859_6 ISO_8859_6 UTF8
ISO_8859_7 ISO_8859_7 UTF8
ISO_8859_8 ISO_8859_8 UTF8
JOHAB JOHAB UTF8
KOI8R KOI8R ISO_8859_5 MULE_INTERNAL UTF8 WIN866 WIN1251
KOI8U KOI8U UTF8
LATIN1 LATIN1 MULE_INTERNAL UTF8
LATIN2 LATIN2 MULE_INTERNAL UTF8 WIN1250
LATIN3 LATIN3 MULE_INTERNAL UTF8
LATIN4 LATIN4 MULE_INTERNAL UTF8
LATIN5 LATIN5 UTF8
LATIN6 LATIN6 UTF8
LATIN7 LATIN7 UTF8
LATIN8 LATIN8 UTF8
LATIN9 LATIN9 UTF8
LATIN10 LATIN10 UTF8
MULE_INTERNAL MULE_INTERNAL BIG5 EUC_CN EUC_JP EUC_KR EUC_TW ISO_8859_5 KOI8R LATIN1 to LATIN4 SJIS WIN866 WIN1250 WIN1251
SJIS サーバの符号化方式としてはサポートしていません。
SQL_ASCII どれでも (変換されません)
UHC サーバの符号化方式としてはサポートしていません。
UTF8 すべてサポートされています。
WIN866 WIN866 ISO_8859_5 KOI8R MULE_INTERNAL UTF8 WIN1251
WIN874 WIN874 UTF8
WIN1250 WIN1250 LATIN2 MULE_INTERNAL UTF8
WIN1251 WIN1251 ISO_8859_5 KOI8R MULE_INTERNAL UTF8 WIN866
WIN1252 WIN1252 UTF8
WIN1253 WIN1253 , UTF8
WIN1254 WIN1254 , UTF8
WIN1255 WIN1255 , UTF8
WIN1256 WIN1256 UTF8
WIN1257 WIN1257 , UTF8
WIN1258 WIN1258 UTF8

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

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

    \encoding SJIS

  • libpq ( 項31.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のデータを扱っている場合を除き、賢い方法ではありません。

22.3.4. 推奨文書

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

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

EUC_JP EUC_CN EUC_KR EUC_TW の詳しい説明があります。

http://www.unicode.org/

Unicode協会のWebサイトです。

RFC 3629

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


powered by SEO.CUG.NET