文字セットサポート

PostgreSQL 9.1.1文書
前のページ | 巻戻し | 第 22章多言語対応 | 早送り | 次のページ

# 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` | KOI8-R | キリル文字（ロシア） | はい | 1 | `KOI8`
`KOI8U` | KOI8-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.9)はクライアントの符号化方式を制御する関数を保持しています。

- `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. 推奨文書

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

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

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

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

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

http://www.unicode.org/

  Unicode協会のWebサイトです。

RFC 3629

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

前のページ | ホーム | 次のページ
照合サポート | 上に戻る | 定常的なデータベース保守作業