utf-8 - 多国籍企業に最適な文字エンコード

Question

世界中のすべての言語に翻訳される Web サイトがあり、これらすべての翻訳を含むデータベースがある場合、どの文字エンコーディングが最適でしょうか? UTF-128?

もしそうなら、すべてのブラウザは選択されたエンコーディングを理解していますか? 文字エンコーディングを実装するのは簡単ですか、それとも隠れた要因がありますか?

前もって感謝します。

Answer 1

Web コンテンツでさまざまな言語をサポートする場合は、Unicode 範囲全体をカバーするエンコーディングを使用する必要があります。この目的に最適な選択は UTF-8 です。UTF-8 は Web で推奨されるエンコーディングです。HTML5ドラフト標準から：

作成者は UTF-8 を使用することをお勧めします。適合性チェッカーは、作成者に従来のエンコーディングを使用しないようにアドバイスする場合があります。[RFC3629]

オーサリング ツールは、新しく作成されたドキュメントに対してデフォルトで UTF-8 を使用する必要があります。[RFC3629]

UTF-8 と Windows-1252 はブラウザーでサポートする必要がある唯一のエンコーディングであり、UTF-8 と UTF-16 は XML パーサーでサポートする必要がある唯一のエンコーディングです。したがって、UTF-8 は、すべてがサポートする必要がある唯一の一般的なエンコーディングです。

---

以下は、それ自体の回答というよりも、Liv の回答に対する拡張された回答です。これは、CJK コンテンツでも UTF-8 が UTF-16 よりも望ましい理由の説明です。

ASCII 範囲の文字の場合、UTF-8 は UTF-16 よりもコンパクトです (1 バイト対 2)。ASCII 範囲と U+07FF (拡張ラテン語、キリル文字、ギリシャ語、アラビア語、ヘブライ語を含む) の間の文字の場合、UTF-8 も 1 文字あたり 2 バイトを使用するため、ウォッシュされます。Basic Multilingual Plane の外にある文字の場合、UTF-8 と UTF-16 の両方が 1 文字あたり 4 バイトを使用するため、そこでウォッシュされます。

UTF-16 が UTF-8 より効率的である唯一の範囲は、インドのアルファベットと CJK を含む U+07FF から U+FFFF までの文字です。その範囲内の多くのテキストであっても、UTF-8 は比較可能になります。そのテキスト (HTML、XML、RTF、またはあなたが持っているもの) のマークアップはすべて、UTF-8 が半分である ASCII 範囲内にあるためです。 UTF-16 のサイズ。

たとえば、日本語の Web ページ、nhk.or.jp のホームページをランダムに選択すると、UTF-8 でエンコードされます。UTF-16 にトランスコードすると、元のサイズのほぼ 2 倍になります。

$ curl -o nhk.html 'http://www.nhk.or.jp/'
$ iconv -f UTF-8 -t UTF-16 nhk.html > nhk.16.html
$ ls -al NHK*
-rw-r--r-- 1 ラムダ ラムダ 32416 3 月 13 日 13:06 nhk.16.html
-rw-r--r-- 1 ラムダ ラムダ 18337 3 月 13 日 13:04 nhk.html

UTF-8 は、ほぼすべての点で UTF-16 より優れています。どちらも可変幅エンコーディングであるため、複雑さが伴います。ただし、UTF-16 では 4 バイト文字はかなり一般的であるため、固定幅の仮定を作成し、キャッチできなかったコーナー ケースに遭遇するまですべてを機能させる方がはるかに簡単です。この混乱の例は、エンコード CESU-8 で見ることができます。これは、サロゲート ペアの各半分を個別の文字としてエンコードするだけで UTF-16 テキストを UTF-8 に変換した場合に得られるものです (1 文字あたり 6 バイトを使用)。 ; ペアをそのコードポイントにデコードして UTF-8 にエンコードする代わりに、サロゲート ペアの各半分を UTF-8 でエンコードするための 3 バイト)。この混乱はよくあることで、間違ったエンコーディングが実際に標準化されているため、少なくとも壊れたプログラムを相互運用できるようになっています。

UTF-8 は、大部分のコンテンツで UTF-16 よりもはるかに小さく、サイズが気になる場合は、別のエンコーディングを選択するよりも、テキストを圧縮する方が常に優れています。UTF-8 は、API およびデータ構造がエンコーディングを気にしないか、文字列内の異なるエンコーディングを処理できる限り (そのようなもの)、null で終了するバイト シーケンスを使用して文字列を表す API およびデータ構造と互換性があります。ほとんどの C および POSIX 文字列処理 API と同様)、UTF-8 は、まったく新しい一連の API とワイド文字用のデータ構造を持たなくても問題なく動作します。UTF-16 はエンディアンを指定しないため、エンディアンの問題に対処する必要があります。実際には、UTF-16、UTF-16BE、および UTF-16LE という 3 つの異なる関連エンコーディングがあります。UTF-16 は、ビッグ エンディアンまたはリトル エンディアンのいずれかです。そのため、BOM を指定する必要があります。UTF-16BE と LE はビッグ エンディアン バージョンとリトル エンディアン バージョンであり、BOM がないため、アウト オブ バンド メソッド (Content-Type HTTP ヘッダーなど) を使用して、どちらを使用しているかを通知する必要があります。帯域外ヘッダーは、間違っているか欠落していることで有名です。

UTF-16 は基本的に偶然であり、最初はすべての Unicode をエンコードするには 16 ビットで十分だと人々が考え、その表現と API をワイド (16 ビット) 文字を使用するように変更し始めたためです。より多くの文字が必要になることに気付いたとき、2 つのコード単位を使用して 32 ビット値をエンコードするためにいくつかの予約文字を使用するスキームを思いついたので、新しいエンコードに同じデータ構造を引き続き使用できます。これにより、UTF-8 のような可変幅エンコーディングのすべての欠点がもたらされましたが、ほとんどの利点はありませんでした。

Answer 2

UTF-8は、Unicode の事実上の標準文字エンコーディングです。

UTF-8 は、Unicode 文字セットのすべての文字を表すことができるため、UTF-16 や UTF-32 と似ています。ただし、UTF-16 や UTF-32 とは異なり、ASCII と下位互換性があるという利点があります。また、エンディアンの複雑さと、結果としてバイト オーダー マーク (BOM) を使用する必要性を回避できるという利点があります。これらの理由やその他の理由から、UTF-8 は World-Wide Web の主要な文字エンコーディングになり、すべての Web ページの半分以上を占めています。

UTF-128 というものはありません。

Answer 3

これに対処するときは、より多くのことを考慮する必要があります。たとえば、中国語、日本語、およびほとんどすべてを UTF-8 で表すことができますが、そのような「外国の」文字ごとに一連のエスケープ文字を使用します。これらの追加のマーカー。中国語、日本語などのエスケープ/マーカーを必要としない UTF-16 も確認できますが、各文字を表すのに 2 バイトが必要になります。したがって、主にラテン文字セットを扱っている場合は、データ ストレージのサイズを 2 倍にしただけで何のメリットもありません。これらの文字セットを UTF-8 や UTF-16 よりも適切に表す日本語専用の shift-jis もありますが、ラテン文字はサポートされていません。私は言うでしょう、多くの外国語の文字が含まれることが事前にわかっている場合は、UTF-16 を検討してください。主にアクセント記号とラテン文字を扱う場合は、UTF-8 を使用してください。ラテン文字を使用しない場合は、shift-jis などを検討してください。