<xref linkend="charset-table"/> shows the character sets available for use in <productname>PostgreSQL</productname>. PostgreSQLで使用できる文字セットを表 24.3に示します。

Not all client <acronym>API</acronym>s support all the listed character sets. For example, the <productname>PostgreSQL</productname> JDBC driver does not support <literal>MULE_INTERNAL</literal>, <literal>LATIN6</literal>, <literal>LATIN8</literal>, and <literal>LATIN10</literal>. 全てのクライアントのAPIが上の一覧表に示した文字セットをサポートしているわけではありません。 例えばPostgreSQL JDBCドライバはMULE_INTERNAL、LATIN6、LATIN8、そしてLATIN10をサポートしません。

The <literal>SQL_ASCII</literal> setting behaves considerably differently from the other settings. When the server character set is <literal>SQL_ASCII</literal>, the server interprets byte values 0&ndash;127 according to the ASCII standard, while byte values 128&ndash;255 are taken as uninterpreted characters. No encoding conversion will be done when the setting is <literal>SQL_ASCII</literal>. Thus, this setting is not so much a declaration that a specific encoding is in use, as a declaration of ignorance about the encoding. In most cases, if you are working with any non-ASCII data, it is unwise to use the <literal>SQL_ASCII</literal> setting because <productname>PostgreSQL</productname> will be unable to help you by converting or validating non-ASCII characters. SQL_ASCIIの設定は、他の設定とかなり異なります。サーバのキャラクタセットがSQL_ASCIIのとき、サーバは0から127のバイト値をASCIIに変換します。一方、128から255までは変換されません。 設定がSQL_ASCIIの場合は、符号化は実行されません。よって、この設定は特定の符号化を使用している場合には、その符号化を無視するようになってしまいます。 多くの場合、ASCIIではない環境で作業する場合はSQL_ASCIIの設定を使用するのは、賢いことではありません。なぜならPostgreSQLはASCIIではない文字を変換したり検査したりすることは出来ないからです。

<command>initdb</command> defines the default character set (encoding) for a <productname>PostgreSQL</productname> cluster. For example, initdbでPostgreSQLクラスタのデフォルト文字セット（エンコーディング）を定義します。 以下に例を示します。

initdb -E EUC_JP

sets the default character set to <literal>EUC_JP</literal> (Extended Unix Code for Japanese). You can use <option>&#45;-encoding</option> instead of <option>-E</option> if you prefer longer option strings. If no <option>-E</option> or <option>&#45;-encoding</option> option is given, <command>initdb</command> attempts to determine the appropriate encoding to use based on the specified or default locale. これはデフォルトの文字セットをEUC_JP（日本語拡張Unixコード）に設定します。 より長いオプションの文字列がお好みなら-Eの代わりに--encodingと書くこともできます。 -Eオプションも--encodingオプションも与えられない場合、initdbは、指定もしくはデフォルトのロケールに基づいて適当な符号化方式を決定しようとします。

You can specify a non-default encoding at database creation time, provided that the encoding is compatible with the selected locale: データベース作成時に選択したロケールと互換性を持つ符号化方式を提供することで、デフォルト以外の符号化方式を指定できます。

createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean

This will create a database named <literal>korean</literal> that uses the character set <literal>EUC_KR</literal>, and locale <literal>ko_KR</literal>. Another way to accomplish this is to use this SQL command: これは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;

Notice that the above commands specify copying the <literal>template0</literal> database. When copying any other database, the encoding and locale settings cannot be changed from those of the source database, because that might result in corrupt data. For more information see <xref linkend="manage-ag-templatedbs"/>. 上のコマンドにてtemplate0データベースのコピーが指定されていることに注目してください。 他のデータベースからコピーする場合、データが破損する結果となる可能性がありますので、符号化方式とロケール設定を元のデータベースの設定から変更することはできません。 詳細については23.3を参照してください。

The encoding for a database is stored in the system catalog <literal>pg_database</literal>. You can see it by using the <command>psql</command> <option>-l</option> option or the <command>\l</command> command. データベースの符号化方式は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)

<productname>PostgreSQL</productname> supports automatic character set conversion between server and client for many combinations of character sets (<xref linkend="multibyte-conversions-supported"/> shows which ones). PostgreSQLは、多数の文字セットの組み合わせ（24.3.4 のいずれか）に対してサーバとクライアントの間で自動的に文字セットを変換する機能を提供しています。

To enable automatic character set conversion, you have to tell <productname>PostgreSQL</productname> the character set (encoding) you would like to use in the client. There are several ways to accomplish this: 自動文字セット変換を有効にするためには、クライアントでどのような文字セット（符号化方式）を使用させたいかをPostgreSQLに伝えなければなりません。 これを行うにはいくつかの方法があります。

If the conversion of a particular character is not possible &mdash; suppose you chose <literal>EUC_JP</literal> for the server and <literal>LATIN1</literal> for the client, and some Japanese characters are returned that do not have a representation in <literal>LATIN1</literal> &mdash; an error is reported. EUC_JPをサーバに、そしてLATIN1をクライアントに選んだ場合のように、 特定の文字の変換ができない時、日本語文字はLATIN1に入っていないという旨の日本語が返され、エラーが報告されます。

If the client character set is defined as <literal>SQL_ASCII</literal>, encoding conversion is disabled, regardless of the server's character set. (However, if the server's character set is not <literal>SQL_ASCII</literal>, the server will still check that incoming data is valid for that encoding; so the net effect is as though the client character set were the same as the server's.) Just as for the server, use of <literal>SQL_ASCII</literal> is unwise unless you are working with all-ASCII data. クライアント側のキャラクタセットがSQL_ASCIIに定義されている場合は、符号化変換はサーバ側のキャラクタセットに関係無く無効化されます。 （ただし、サーバの文字セットがSQL_ASCIIでない場合、サーバは受信データがそのエンコーディングに対して有効であることをチェックします。したがって、クライアントの文字セットがサーバの文字セットと同じであるかのような結果になります。） サーバ側と同じように、SQL_ASCIIを使用することは、すべてASCIIのデータを扱っている場合を除き、賢い方法ではありません。

<productname>PostgreSQL</productname> allows conversion between any two character sets for which a conversion function is listed in the <link linkend="catalog-pg-conversion"><structname>pg_conversion</structname></link> system catalog. <productname>PostgreSQL</productname> comes with some predefined conversions, as summarized in <xref linkend="multibyte-translation-table"/> and shown in more detail in <xref linkend="builtin-conversions-table"/>. You can create a new conversion using the SQL command <xref linkend="sql-createconversion"/>. (To be used for automatic client/server conversions, a conversion must be marked as <quote>default</quote> for its character set pair.) PostgreSQLは、pg_conversionシステムカタログ内にリストされた変換関数によって2つの文字セット間を変換できます。 PostgreSQLでは表 24.4で要約され表 24.5に詳細が示されているように、いくつかの変換があらかじめ組み込まれています。 CREATE CONVERSIONSQLコマンドを用いることで新しい変換を作成できます。（クライアントもしくはサーバの自動変換を使用するためには、変換がその文字セットの組み合わせのための「デフォルト」として設定されている必要があります。）

These are good sources to start learning about various kinds of encoding systems. ここに記したものは様々な符号化方式システムを学習するのに良い資料です。