UTF-8（および多分UTF-16 / UTF-32）以外の文字エンコーディングは非推奨ですか？

私の大嫌いな人は、文字セットをサポートするための山のようなコードを持つ非常に多くのソフトウェアプロジェクトを見ています。誤解しないでください、私はすべて互換性があるので、テキストエディタを使用して複数の文字セットでファイルを開いたり保存したりできることを嬉しく思います。私を悩ますのは、非ユニバーサル文字エンコーディングの急増が「問題」ではなく「適切なUnicodeサポート」とラベル付けされていることです。

たとえば、PostgreSQLとその文字セットサポートを選択します。PostgreSQLは2種類のエンコーディングを扱います。

• クライアントのエンコード：クライアントとサーバー間の通信で使用されます。
• サーバーのエンコード：データベースにテキストを内部的に保存するために使用されます。

多くのクライアントエンコーディングをサポートすることが良いことである理由を理解できます。UTF-8で動作しないクライアントは、変換を実行する必要なくPostgreSQLと通信できます。取得できないのは、PostgreSQLが複数のサーバーエンコーディングをサポートしている理由です。データベースファイルは（ほとんどの場合）PostgreSQLバージョン間で互換性がないため、ここではバージョン間の互換性は問題になりません。

UTF-8は、すべてのUnicodeコードポイントをエンコードできる唯一の標準のASCII互換文字セットです（間違っている場合はお知らせください）。私は、UTF-8が最高の文字セットであるという陣営にいますが、UTF-16やUTF-32などの他のユニバーサル文字セットに我慢します。

すべての非ユニバーサル文字セットは廃止されるべきだと思います。彼らがすべきではない説得力のある理由はありますか？

PostgreSQLについて述べたので、いくつかの権限で、UTF8以外のサーバー側エンコーディングがこのように詳細にサポートされている主な理由は、日本人がそれを必要としているということです。どうやら、Unicodeとさまざまな日本の「レガシー」エンコーディングとの間の同一の往復変換が常に可能とは限らず、場合によってはベンダー間で変換テーブルが異なることさえあります。それは本当に困惑していますが、明らかにそうです。（広範な文字セットのサポートも、PostgreSQLが日本で非常に人気がある理由の1つです。）

データベースシステムについて説明しているので、主な仕事の1つは、ユーザーが定義したとおりにデータを確実に保存および取得できるようにすることです。そのため、損失のある文字セット変換が飛ぶことがありません。たとえば、Webブラウザーを扱っている場合、本当に重要なのは結果が問題ないように見えるかどうかです。おそらく、サポートするエンコードの数を減らすことはできますが、データベースシステムでは追加の要件があります。

他の回答で言及された他の理由のいくつかは、支持する議論としても当てはまります。しかし、日本人が拒否している限り、キャラクター設定のサポートを減らすことはできません。

明らかな2つの理由：保存しているデータによっては、別の形式への変換にかなりの時間と余分なスペースが必要になる場合があります。400メガバイトの情報を保存する場合、ストレージ要件を2倍にすることは大したことではありませんが、400テラバイトを保存する場合は、もう少し意味があります。400テラバイトのデータを（たとえば）Shift-JISからUTF-xに変換するのにも少し時間がかかります。

これは、たとえば、データベースが特定の年のうち、たとえば10分間を除くすべての時間で使用可能であり、1秒間に数百回更新されるデータベースがあるという稼働時間の保証がある場合、特に困難になります。ただし、このような状況でもメジャーコンバージョンを管理することは可能ですが、軽視することはできません。場合によっては、そのような変換の準備をするのに数年の計画が簡単にかかる可能性があります。

（たとえば）ASCIIのみをサポートするデータベースから始めている場合、これらすべてのエンコーディングのサポートを追加することが理にかなっているかどうかを議論する正当な理由があるかもしれません -しかし、すでにそれらをサポートしている場合、ドロップすることから得られるものはほとんどありませんそれらのサポート。

特に、コードを単純化する方法などでは、ほとんど何も得られないことに注意してください。とにかくクライアントとサーバー間の変換を処理するには、すべての変換ルーチンが必要です。そのため、サポートを削除するということは、「ディスクへの書き込み」および「ディスクからの読み取り」パスで1つの（マイナー）関数呼び出しを削除することを意味しますが、（他の場合は）ほとんどありません。ディスク上で2つのエンコーディングをサポートしていても、それを得ることさえできません-関数呼び出しがまだあるので、あなたが本当にやるべきことは、その関数でサポートされているエンコーディングの範囲を制限することです。

少なくともこれを設計する場合は、おそらくUCS-4で動作するデータベースのコアを作成し、コアとディスク間、およびコアとユーザー間で変換ルーチンを作成することになります。どちらの場合も同じルーチンセットを使用するため、最も簡単なルートは、クライアントが使用を許可されたのとまったく同じエンコーディングセットをディスクストレージで使用できるようにすることです。

サーバーにUTF-8のみを保存する場合、いくつかの問題があります。

1. VARCHAR(20)列の制限は何ですか？それは20バイトですか、それとも20の「文字」ですか（Unicodeでは、文字、合字などの組み合わせを考慮した場合の「文字」とは何ですか？）。さらに悪いことに、CHAR(20)可能なスペース全体を実際に確保する必要がある場所についてはどうでしょうか。MySQLではCHAR(20)、最悪のケースを処理するためだけに、UTF-8エンコード列のバイト数の4倍（つまり80バイト）を確保しています。
2. サーバーエンコーディングとクライアントエンコーディングの間で、一定のエンコーディング変換を実行する必要があります。複数のクライアントエンコーディングのサポートを停止することもできますが、そうしない限り、すべての文字列を常に変換する必要があります。サーバーのエンコードとクライアントのエンコードを一致させることができる場合、変換は必要ありません。
3. 他の人が指摘しているように、UTF-8は英語のテキストを保存するのに非常に効率的ですが、他の言語、特に東アジア言語には非常に非効率的です。スーツとしてUTF-16またはUTF-8の使用を許可することができると思います。または、テキストを圧縮しますが、インデックス作成と検索が非効率的になります。

そうは言っても、私はあなたに同意します。レガシーエンコーディングはほとんど無意味であり、一般的にUnicodeはすべての新しいアプリケーションに使用するのに最適なエンコーディングです。今日データベースデータベースをゼロから作成する場合、Unicodeのみをサポートし、レガシーエンコーディングは一切サポートしません。

違いは、現在使用されているPostgreSQLと他のほとんどのデータベースサーバーは、Unicodeが実行可能なオプションになる前から存在していたことです。そのため、彼らはすでにレガシーエンコーディングをサポートしていました（もちろん当時はレガシーではありませんでした）。

非ユニバーサル（具体的にはシングルバイト）エンコーディングには、次の場所があります。

• Unicode文字データベースを保存するのに十分なメモリがありません。
• ROMにハードコードされたシングルバイトフォントを使用します。
• 異なってエンコードされたファイルのソースを提供するためのインターネットアクセスがありません。

これは、一部の種類の組み込みデバイスに今日当てはまります。しかし、デスクトップ上およびサーバールームでは、非Unicodeエンコーディングは長い間廃止されるはずです。

UTF-8は、エゴセントリックな^1人の英語を話す人に最適です。日本人の場合、文字の約99％はUTF-16の2つではなく3〜4バイトかかります。

非ラテン方言は、サイズレベルでUTF-8の影響を本当に受けます。数年以内に、ほとんどのクライアントは中国語であり、中国語の文章には数百万の文字があることを忘れないでください。UTF-8ではこれを効率的に維持できません。

それ以外の場合、UTF- 何かではないテキスト文書を持っているときは嫌いです。適切なエンコードを行う必要がある場合は、しばしば邪魔になりません。私の本では、非Unicodeエンコーディングは死んでいます。

_{1.自己中心的な部分を個人的にとらないでください。私はカラフルなイラストを作りたかったのですが、それは本当の意味ではありません。}

Unicodeは根本的に壊れており、修正されることはほとんどありません。より良いもの、真に普遍的なものに置き換える必要があります。廃止が必要なものがあれば、それはUnicodeです。

Unicideの問題の例：

• UTF8は妥当なハックですが、ほとんどのUTF16ベースのソフトウェアは壊れています。UnicodeをサポートするほとんどのWindowsアプリは、OS自体を含めてUTF16を使用します。最も一般的な問題は、基本的なプレーン、つまり複数単語の文字以上をサポートしていないことです。

• 漢統一は、軽減されない災害です。追加のメタデータなしで日本語/中国語/韓国語のテキストを単一のドキュメントに混在させることは不可能であり、使用するフォントを検出することは困難です。

• 組み合わせキャラクターは別の災害です。より賢明なエンコーディングスキームは、1つの文字を1つのコードにマッピングするため、文字列の処理が比較的健全になります。Unicodeはサポートしていません。Unicodeは一貫性さえありません-漢字はほとんど組み合わせですが、ヨーロッパの組み合わせ文字のようにそのようにエンコードされません。

• 一部の人々の名前はユニコードで正しく記述できないか、上記の問題のために誤ってレンダリングされる傾向があります。これは、航空券に（誤って）印刷されているものと一致しないパスポートで航空機に搭乗しようとする場合など、深刻な結果を招く可能性があります。

これらの問題などにより、英語以外のソフトウェアの多くはUnicodeを使用できず、ローカルの文字エンコーディングに依存しています。これは、特に日本語および中国語のソフトウェアで一般的です。

理想的には、Unicodeは非推奨です。TRON文字コーディングは、Unicodeのかなり良い代替品であり、更新されない既存のソフトウェアとほぼ互換性があります。

たぶん書くためではなく、読むためです。

これらのエンコーディングを使用する既存のコンテンツがたくさんあります。また、base64のような一部のエンコーディングは、バイナリデータを埋め込む方法としてテキストプロトコルを義務付けているため、どこにも行きません。

本当の問題は、セキュリティホールにつながるエンコーディングの自動検出です。UTF-7のような不明瞭なエンコーディングが消えるのを見るのは気になりません。

また、自動検出は、単純にバイト文字列を連結して生成されるコンテンツを不適切に処理する傾向があります。

データベースと新しいアプリケーションのデフォルトの文字エンコーディングは、ある種のUTFバリアントでなければならないことに同意できます。私は個人的にはUTF-16を選択します。これは、スペースと複雑さ（UTF-8よりも）の合理的なトレードオフのようです。ただし、特定の場合には、一部の文字エンコードが依然として意味をなします。

• base64テキストを保存/転送する場合、必要なのはASCIIだけで、電子メールなどの7ビットでエンコードされたプロトコルを使用することもできます。UTF-8の余分なオーバーヘッドは不要です。
• これらの古い文字エンコーディングに基づいていくつかのファイルと既存のデータが構築されているため、それらを読み取ることができることが重要です。

4つの標準UTF正規化アルゴリズムがあることに注意してください。マルチコードポイント文字が心配な場合は、2つの正規化アルゴリズムのいずれかを使用して、それらを同等の単一コードポイント文字にまとめることができます。それらの違いは、文字の論理的同等性と物理的同等性に関係しています。