UTF-8 を使用した XML ドキュメントのエンコードの詳細な紹介

Google のサイトマップ サービスでは、公開されるすべてのサイト マップ が Unicode の UTF-8 でエンコードされている必要があります。 Google では、ISO-8859-1 などの非 Unicode エンコードはもちろん、UTF-16 などの他の Unicode エンコードさえも許可していません。 XML 勧告では「すべての XML ハンドラーは Unicode 3.1 の UTF-8 および UTF-16 エンコーディングを受け入れる必要がある」と特に要求しているため、技術的には、これは Google が非標準の XML パーサーを使用していることを意味しますが、これは実際には大きな問題です?

誰でも UTF-8 を使用できます

UTF-8 を選択する第一の、そして最も説得力のある理由は、汎用性です。現在世界中で使用されているあらゆるスクリプトを処理できます。まだいくつかのギャップはありますが、それらはますます目立たなくなり、徐々に埋められています。含まれていないテキストは通常​​、他の Character Set に実装されておらず、たとえ実装されていたとしても XML では使用できません。最良の場合、これらのスクリプトはフォント借用を通じて Latin-1 などのシングルバイト文字セットに渡されます。このようなまれなスクリプトの実際のサポートは、おそらく Unicode から初めて提供され、おそらく Unicode だけがそれらをサポートします。

しかし、それは Unicode を使用する理由の 1 つにすぎません。 UTF-16 や他の Unicode エンコーディングではなく UTF-8 を選択するのはなぜですか?最も直接的な理由の 1 つは、広範なツールのサポートです。基本的に、JEdit、BBEdit、Eclipse、emacs、さらにはメモ帳など、XML 用の主要なエディタはすべて UTF-8 を処理できます。 XML ツールと非 XML ツールの間でこれほど広範なツールをサポートしている Unicode エンコーディングは他にありません。

BBEdit や Eclipse などの一部のエディタでは、UTF-8 がデフォルトの文字セットではありません。ここで、デフォルト設定を変更する必要があります。すべてのツールは工場出荷時にデフォルトのエンコードとして UTF-8 を選択する必要があります。これが行われない限り、ファイルが国境、プラットフォーム、言語を越えて移動する際に、相互運用性のない泥沼にはまってしまうことになります。ただし、すべてのプログラムがデフォルトのエンコーディングとして UTF-8 を使用するまでは、デフォルト設定を自分で簡単に変更できます。たとえば、Eclipse では、図 1 に示す [全般]/[エディタ] 設定パネルで、すべてのファイルが UTF-8 を使用するように指定できます。 Eclipse はデフォルトが MacRoman であることを想定していることに気づくかもしれませんが、この場合、Microsoft® Windows® を使用するプログラマや米国および西ヨーロッパ以外のコンピュータにファイルを渡すと、ファイルはコンパイルされません。

図 1. Eclipse のデフォルトの文字セットの変更

もちろん、UTF-8 が機能するには、開発者が交換するすべてのファイルも UTF-8 を使用する必要がありますが、これは問題ではありません。 MacRoman とは異なり、UTF-8 はいくつかのスクリプトやプラットフォームに限定されません。 UTF-8 は誰でも使用できます。 MacRoman、Latin-1、SJIS、およびその他のさまざまな従来の各国語文字セットでは、これを行うことができません。

UTF-8 は、マルチバイト データをサポートしていないツールでも正常に動作します。 UTF-16 などの他の Unicode 形式には、多くのゼロ バイトが含まれる傾向があります。多くのツールは、これらのバイトをファイルの終わりまたはその他の特別な区切り文字として解釈し、望ましくない、予期しない、多くの場合不快な結果を引き起こします。たとえば、UTF-16 データがそのまま C string にロードされる場合、文字列は最初の ASCII 文字の 2 バイト目から切り捨てられる可能性があります。 UTF-8 ファイルには、実際には null を意味する null のみが含まれます。もちろん、XML ドキュメントの処理にそのような単純なツールを選択すべきではありません。しかし、レガシー システムのドキュメントは奇妙な場所に置かれることがよくあり、それらの文字列が新しいボトルに入った古いワインにすぎないことを実際に認識または理解する人は誰もいません。 Unicode と XML をサポートしていないシステムでは、UTF-8 は UTF-16 または他の Unicode エンコーディングよりも問題を引き起こす可能性が低くなります。

専門家の意見

XML は UTF-8 を完全にサポートする最初の主要標準ですが、それは始まりにすぎません。さまざまな標準化団体が段階的に UTF-8 を推奨しています。たとえば、非 ASCII 文字を含む URL は、Web 上で長年の問題です。 PC で動作する非 ASCII 文字を含む URL は Mac では動作しません。また、その逆も同様です。 World Wide Web Consortium (W3C) と Internet Engineering Task Force (IETF) は最近、すべての URL を UTF-8 でエンコードし、他のエンコードを使用しないことに同意することで、この問題を解決しました。

W3C と IETF は、UTF-8 を最初に使用するか、最後に使用するか、または時々使用するかについて、より厳しくなっています。 W3C Character Model for the World Wide Web 1.0: Fundamentals には、「文字エンコーディングを選択する必要がある場合は、UTF-8、UTF-16、または UTF-32 である必要があります。US-ASCII は UTF-8 と上位互換性があります ( US-ASCII 文字列は UTF-8 文字列でもあります ([RFC 3629] を参照)。そのため、US-ASCII との互換性が必要な場合には、UTF-8 が非常に適しています。「実際、US-ASCII との互換性は非常に重要です。ほぼ必須。 W3C は賢明にも、「API などの他のケースでは、UTF-16 または UTF-32 の方が適切な場合があります。1 つのエンコーディングを選択する理由には、内部処理の効率や他のプロセスとの相互運用性が含まれる可能性があります。」に同意します。内部処理効率の理論的根拠。たとえば、Java™ 言語の文字列の内部表現は UTF-16 であるため、文字列のインデックス作成が高速になります。ただし、Java コードは、データを交換するプログラムにこの内部表現を公開することはありません。代わりに、外部データ交換の場合は、文字セットを明示的に指定して java.io.Writer を使用します。選択する場合は、UTF-8 を強くお勧めします。

IETF はさらに明確です。 IETF 文字セット ポリシー [RFC 2277] では、非決定的言語では次のように規定されています。

プロトコルは、ISO 10646 エンコード セットと UTF-8 文字エンコード方式で構成される UTF-8 文字セットを使用できなければなりません。全文は、[10646 ] Annex R (改訂 2 でリリース) を参照してください。

さらに、このプロトコルでは、他の ISO 10646 文字セットや UTF-16 などの文字エンコード スキームの使用方法を指定できますが、UTF-8 を使用できないことは、このポリシーに違反する場合に報告する必要があります。標準追跡プロセスに参加または昇格する場合は、変更手順 ([BCP9] のセクション 9) を実行し、プロトコル仕様書で明確かつ信頼できる根拠を提供します。

既存のプロトコル、または既存のデータ ストアからデータを転送するためのプロトコルは、他の

データセット

をサポートしたり、UTF-8 以外のデフォルトのエンコーディングを使用したりする必要がある場合があります。これは許可されていますが、UTF-8 をサポートできる必要があります。 ポイント: レガシープロトコルとファイルのサポートには、今後しばらくの間、UTF-8 以外の文字セットとエンコーディングの受け入れが必要になる可能性がありますが、そうしなければならない場合には細心の注意を払います。新しいプロトコル、アプリケーション、ドキュメントはすべて UTF-8 を使用する必要があります。

中国語、日本語、韓国語

よくある誤解は、UTF-8 は圧縮形式であるということです。これはそうではありません。 UTF-8 では、ASCII 文字は他の Unicode エンコード、特に UTF-16 と比較して半分のスペースしか占有しません。ただし、一部の文字、特に中国語、日本語、韓国語 (CJK) などの象形文字の UTF-8 エンコードでは、50% 多くのスペースが必要になります。

ただし、CJK XML が UTF-8 でエンコードされていても、実際のサイズは UTF-16 よりも小さくなる可能性があります。たとえば、中国語の XML ドキュメントには、、&、=、"、'、スペースなどの ASCII 文字が多数含まれています。これらの文字の UTF-8 エンコードは、UTF-16 より小さくなります。特定の圧縮/展開係数はドキュメントによって異なりますが、どちらの場合も違いは明らかではありません

最後に、中国語や日本語などの象形文字は、次のようなアルファベット文字よりも使用する単語が少ない傾向があることに注意してください。ラテン語とキリル文字は文字数が多いため、これらの単語を完全に表現するには 1 文字あたり 3 バイト以上が必要です。つまり、これらの言語では同じ単語や文章を英語やロシア語よりも少ない単語で表現できます。たとえば、「木」は日本語では「木」で表されます (木と非常によく似ています)。一方、英語の「木」という単語には 4 バイトが必要です。 UTF-8 でのエンコードには 3 バイトが必要ですが、「grove」という単語は 5 文字で、日本語の「sen」（3 つの木）は 5 バイト必要です。それでも 3 バイト必要ですが、対応する英語の単語「forest」は 6 バイト必要です

本当に圧縮が必要な場合は、圧縮後の UTF-8 と UTF-16 のサイズは似ています。どのエンコーディングであっても、元のサイズが大きいほど、圧縮アルゴリズムによってより多くの冗長性が削除されます。

設計上、UTF-8 はどの形式よりも堅牢で解釈が容易です。まず、UTF-8 は 16 ビット バイトではなく 8 ビット バイトで定義されているため、UTF-8 には UTF-8 のエンディアンの問題がありません。 -bit ワード。エンディアンネス フラグまたはその他のヒューリスティックを通過する必要があります。

UTF-8 のより重要な機能の 1 つはステートレスです。 UTF-8 ストリームまたはシーケンス内のすべてのバイトは明確です。 UTF-8 では、常に位置を知ることができます。つまり、バイトが与えられた場合、それが 1 バイト文字であるか、2 バイト文字の最初のバイトであるか、または 2 バイト文字の最初のバイトであるかをすぐに判断できます。 2 バイト文字、または 3 バイト/4 バイト文字の 2 バイト目、3 バイト目、または 4 バイト目 (もちろん、他の可能性もありますが、ご理解いただけると思います)。 UTF-16 では、バイト「0x41」が文字「A」であるかどうかを判断することはできません。そうなる場合もあれば、そうでない場合もあります。フロー内の位置を判断するには、十分な状態をログに記録する必要があります。 1 バイトが失われると、それ以降のデータはすべて使用できなくなります。 UTF-8 では、バイトの欠落または破損は簡単に判断でき、他のデータには影響しません。

UTF-8 は万能薬ではありません。ドキュメント内の特定の場所へのランダム アクセスが必要なアプリケーションは、UCS2 や UTF-32 などの固定幅エンコードを使用すると高速に動作する可能性があります。 (置換ペアを考慮すると、UTF-16 は可変長文字エンコーディングです。) ただし、XML 処理は、このカテゴリのアプリケーションには分類されません。 XML 仕様では、パーサーが XML ドキュメントの最初のバイトから最後のバイトまで解析を開始することが特に要求されており、既存のすべてのパーサーはこれを実行します。ランダム アクセスの高速化は XML 処理には役に立ちません。これはデータベースや他のシステムに別のエンコーディングを使用する十分な理由になるかもしれませんが、XML には当てはまりません。

結論

言語と政治の境界があいまいになり、国際化が進む世界では、地域依存の文字セットはもはや適用できません。 Unicode は、多くの地域間で相互運用できる唯一の文字セットです。 UTF-8 は最高の Unicode エンコーディングです:

従来の ASCII システムとの最高の互換性を含む広範なツールのサポート。

シンプルで効率的に扱えます。

腐敗防止。

プラットフォームに依存しません。

文字セットとエンコーディングについての議論をやめ、UTF-8 を選択して議論を終わらせる時が来ました。

以上がUTF-8 を使用した XML ドキュメントのエンコードの詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。