UTF-16エンコーディングのポイントを理解したことはありません。文字列をランダムアクセスとして処理できるようにする必要がある場合（つまり、コードポイントがコードユニットと同じである場合）、UTF-16は可変長であるため、UTF-32が必要です。これが必要ない場合、UTF-16はUTF-8と比較して膨大なスペースの浪費のように見えます。UTF-8およびUTF-32に対するUTF-16の利点は何ですか？また、WindowsおよびJavaがそれをネイティブエンコーディングとして使用するのはなぜですか？
18682 次
5 に答える
59
Windows NT が設計されたとき、UTF-16 は存在しませんでした (NT 3.51 は 1993 年に誕生しましたが、UTF-16 は 1996 年に Unicode 2.0 標準とともに誕生しました)。代わりに UCS-2 があり、当時は Unicode で利用可能なすべての文字を保持するのに十分だったので、1 コード ポイント = 1 コード単位の同等性は実際には真でした - 文字列に可変長ロジックは必要ありませんでした。
その後、Unicode 文字セット全体をサポートするために、UTF-16 に移行しました。ただし、UTF-8 または UTF-32 に移行することはできませんでした。これは、API インターフェースのバイナリ互換性が損なわれるためです (とりわけ)。
Java についてはよくわかりません。1995 年までにリリースされたので、UTF-16 は (まだ標準化されていなくても) すでに普及していたと思いますが、NT ベースのオペレーティング システムとの互換性が、彼らの選択に何らかの役割を果たした可能性があると思います (継続的なWindows API への呼び出しごとに UTF-8 <-> UTF-16 変換を行うと、速度が低下する可能性があります)。
編集
ウィキペディアは、Java でも同じように進んだと説明しています。当初は UCS-2 をサポートしていましたが、J2SE 5.0 で UTF-16 に移行しました。
したがって、一般に、一部の API/フレームワークで UTF-16 が使用されている場合、それは最初は UCS-2 (文字列管理アルゴリズムの複雑さを避けるため) でしたが、UTF-16 に移行して外部のコード ポイントをサポートしたためです。 BMP、同じコード単位サイズを維持します。
于 2011-03-13T20:36:38.590 に答える
22
UTF-8 に対する UTF-16 の利点を示す応答は、後方互換性応答を除いて、意味をなさない。
さて、私のコメントには2つの注意点があります。
Erik は次のように述べています。
警告 1)
アプリケーションが BMP 以外の文字を必要としないこと、およびそのアプリケーションで使用するために作成したライブラリ コードが、BMP 以外の文字を必要とするアプリケーションでは決して使用されないことが確実である場合は、以下を使用できます。 UTF-16、およびすべての文字の長さが正確に 2 バイトになるという暗黙の仮定を行うコードを記述します。
それは非常に危険に思えます (実際、ばかげています)。
すべての UTF-16 文字の長さが 2 バイトであると想定しているコードで、プログラムが BMP の外に 1 文字しかないアプリケーションまたはライブラリと対話する場合、コードは壊れます。UTF-16 を検査または操作するコードは、2 バイト以上を必要とする UTF-16 文字のケースを処理するように作成する必要があります。したがって、私はこの警告を「却下」しています。
UTF-16 は UTF-8 よりもコーディングが簡単ではありません (両方のコードは可変長文字を処理する必要があります)。
警告 2)
UTF-16 は、適切に記述されていれば、状況によっては計算効率が向上する可能性があります。
次のように: 特定の長い文字列がめったに変更されないが、頻繁に検査されるとします (または、一度構築されると決して変更されません。つまり、変更不可能な文字列を作成する文字列ビルダー)。各文字列にフラグを設定して、文字列に「固定長」文字のみが含まれているかどうか (つまり、長さが正確に 2 バイトではない文字が含まれていないかどうか) を示します。フラグが true の文字列は、固定長 (2 バイト) 文字を想定する最適化されたコードで調べることができます。
スペース効率はどうですか？
UTF-16 は明らかに、UTF-8 よりも UTF-16 の方がエンコードに必要なバイト数が少ない A) 文字に対してより効率的です。
UTF-8 は明らかに、UTF-16 よりもエンコードに必要なバイト数が少ない B) 文字に対してより効率的です。
非常に「特殊な」テキストを除いて、count(B) が count(A) をはるかに超える可能性があります。
于 2014-01-05T09:11:44.820 に答える
4
UTF-16 は、 BMP全体を 1 つの単位でカバーします。そのため、BMP 以外のより希少な文字が必要でない限り、UTF-16 は実質的に 1 文字あたり 2 バイトです。UTF-32 はより多くのスペースを必要とし、UTF-8 は可変長のサポートを必要とします。
于 2011-03-13T20:32:38.750 に答える
1
UTF-16を使用すると、すべての基本的な多言語平面（BMP）を単一のコード単位として表すことができます。U + FFFFを超えるUnicodeコードポイントは、サロゲートペアで表されます。
興味深いのは、JavaとWindows（およびUTF-16を使用する他のシステム）はすべて、Unicodeコードポイントレベルではなく、コードユニットレベルで動作することです。したがって、単一文字U + 1D122（MUSICAL SYMBOL F CLEF）で構成される文字列は、Javaでは「\ ud824 \ udd22」および"\ud824\udd22".length() == 2（ではなく1）としてエンコードされます。つまり、これは一種のハックですが、文字は可変長ではないことがわかります。
UTF-8に対するUTF-16の利点は、同じハックがUTF-8で使用された場合、あきらめすぎることです。
于 2011-03-13T20:48:04.297 に答える
0
UTF16 は通常、マルチバイト文字セットへの直接マッピングとして使用されます。つまり、元の 0-0xFFFF 割り当て文字のみです。
これにより、両方の長所が得られます。文字サイズは固定されていますが、誰もが使用する可能性のあるすべての文字を印刷できます (正統なクリンゴンの宗教的なスクリプトを除く)。
于 2011-03-13T20:32:40.323 に答える