Windows 7では、インストーラーで「English、United States」ロケールを選択すると、照合順序が"English_United States.1252"
に設定されます。 Linuxでは、照合順序はデフォルトで"en_US.UTF-8"
に設定されています。
Windowsで照合順序のコードセットをUTF-8に設定する方法が見つからなかったので、これらの例の場合にデータベースの動作が異なるかどうか疑問に思っていますか?または、一般的に、最初に照合順序のコードセット部分の影響は何ですか?
両方のデータベースでエンコーディングをUTF-8に設定していますが、問題は、照合のコードセットの違いが動作の違いを引き起こすかどうかです。
ドキュメントは、データベースのエンコーディング/文字セットと照合のctype /コードセットの間の関係に関してあまり明確ではありません。それが言及するすべては以下のステートメントです(すべて 22.3。文字セットのサポート ドキュメンテーションページにあります):
各データベースの文字セットは、データベースのLC_CTYPE(文字分類)およびLC_COLLATE(文字列のソート順)ロケール設定と互換性がある必要があります。
Windowsでは、UTF-8エンコーディングを任意のロケールで使用できます。
重要:ほとんどの最新のオペレーティングシステムでは、PostgreSQLはLC_CTYPE設定によってどの文字セットが暗示されるかを判断でき、一致するデータベースエンコーディングのみが中古。古いシステムでは、選択したロケールで想定されているエンコーディングを使用するようにする必要があります。この領域での間違いは、ソートなどのロケールに依存する操作の奇妙な動作につながる可能性があります。
ここで、LC_CTYPE
値には、その文字セットの文字のルールのみがあるという意味があります。値1252
は、拡張ASCIIのコードページ Windows Latin1 を示します。これらの文字はすべてUTF-8にエンコードできます(現在のエンコード) 、しかしそれは必ずしもupper
、lower
、initcap
などのロケール対応関数が外部に存在する文字を操作するときに期待どおりに動作することを意味しませんコードページ。これは、Windows Latin1 /コードページ1252の文字セットに含まれていない文字でこれらの関数のいずれかを実行することでテストできます。例: ラテン小文字Nj U + 01CC :
大文字にする必要があります:
したがって、if (申し訳ありませんが、現時点ではPostgreSQLをテストできません) 以下;
SELECT upper('nj'), lower('NJ');
戻り値:
NJ nj
次に、 "1252" LC_CTYPE
値が何にも悪影響を与えていないことは非常に肯定的に見えます。これらの値(エンコーディングとLC_CTYPE)が影響を受ける可能性のある領域としてドキュメントでソートが数回言及されているため、SELECT
をORDER BY
で試してみるのも良いでしょう。紛争中。
いったんデータベースが作成されると、LC_COLLATE
またはLC_CTYPE
を変更することはできません。そのため、新しいデータベースを作成して、インストーラーの想定に関係なく、必要な設定が得られるかどうかを確認できます。
CREATE DATABASE my_db_name WITH
ENCODING 'UTF8'
LC_COLLATE='English_United States.UTF8'
LC_CTYPE='English_United States.UTF8'
TEMPLATE=template0;
pg_collation システムカタログを調べて、何が利用できるかを確認する必要がある場合があります。