エンコーディングの理解

[アーティクル]
08/16/2008

更新 : 2007 年 11 月

内部では、.NET Framework はテキストを Unicode UTF-16 として保存します。エンコーダは、このテキストデータをバイトシーケンスに変換します。デコーダは、バイトシーケンスをこの内部形式に変換します。エンコーディングにより、エンコーダまたはデコーダが動作する規則が表されます。たとえば、UTF8Encoding クラスは、テキストを Unicode UTF-8 として表すバイトシーケンスをエンコードおよびデコードするためのルールを表します。エンコードとデコードには、特定の検証手順も含まれます。たとえば、UnicodeEncoding クラスはすべてのサロゲートを検証して、有効なサロゲートペアが構成されていることを確認します。これらのクラスはどちらも、Encoding クラスを継承します。

エンコーディングの選択

Unicode 規格では、サポートされるすべてのスクリプトについて、各文字にコードポイント (数値) を割り当てています。コードポイントのエンコードには UTF (Unicode Transformation Format) が使用されます。System.Text のクラスでサポートされている UTF の詳細については、「.NET Framework での Unicode」の「Unicode エンコーディングの使用」を参照してください。

エンコーディングクラスの選択

Encoding クラスは非常に総合的です。Encoding クラスから継承するサポート対象クラスを使用すると、.NET アプリケーションはレガシアプリケーションで使用される可能性が高い一般的なエンコーディングを使用でき、開発者は追加のエンコーディングを実装できます。ただし、エンコーディングを選択できる場合は、Unicode エンコーディング (通常は UTF8Encoding または UnicodeEncoding) を使用することを強くお勧めします (UTF32Encoding もサポートされています)。特に、ASCIIEncoding よりも UTF8Encoding が優先して使用されています。コンテンツが ASCII の場合、2 つのエンコードの結果は同じになりますが、UTF8Encoding はすべての Unicode 文字も表すのに対して、ASCIIEncoding は U+0000 から U+007F の Unicode 文字値のみをサポートします。ASCIIEncoding にはエラー検出機能が用意されていないため、セキュリティ上の理由からも UTF8Encoding を使用することをお勧めします。

UTF8Encoding はできるだけ高速になるように調整されているため、他のエンコーディングよりも高速です。全体が ASCII のコンテンツの場合でも、UTF8Encoding で実行される演算は、ASCIIEncoding で実行される演算よりも高速になります。特定のレガシアプリケーションの場合のみ ASCIIEncoding の使用を検討してください。ただし、この場合でも、UTF8Encoding の方が適していることがあります。既定の設定を前提とすると、次のシナリオが考えられます。

アプリケーションが厳密には ASCII ではないコンテンツを ASCIIEncoding でエンコードすると、ASCII 以外の各文字は疑問符 ("?") としてエンコードされます。アプリケーションがこのデータをデコードすると、情報は失われます。
アプリケーションが厳密には ASCII ではないコンテンツを UTF8Encoding でエンコードすると、ASCII として解釈された場合、結果は理解不能に見えます。ただし、アプリケーションがこのデータをデコードすると、データは正常にラウンドトリップします。

フォールバックストラテジの選択

アプリケーションでは、文字をエンコードまたはデコードしようとしたときに、マッピングが存在しない場合は、エラー処理機構であるフォールバックストラテジを実装する必要があります。次の 2 種類のフォールバックストラテジがあります。

最適フォールバック

ターゲットエンコードまたはターゲットデコード内に、厳密な一致がない文字について、アプリケーションは類似した文字へのマッピングを試みることができます。
置換文字列フォールバック

類似した適切な文字がない場合、アプリケーションは置換文字列を指定できます。

たとえば、アプリケーションは GetEncoding(1252, 0, 0) を呼び出すことができます (「GetEncoding」を参照)。この呼び出しは、コードページが 1252 (西ヨーロッパ言語の Windows コードページ) で、encoderFallback および decoderFallback にゼロが指定されていることを示します。既定の動作は、特定の Unicode 文字の最適マッピングです。たとえば、CIRCLED LATIN CAPITAL LETTER S (円付きのアルファベット大文字の S) (U+24C8) はエンコードの前に LATIN CAPITAL LETTER S (アルファベット大文字の S) (U+0053) に変更され、SUPERSCRIPT FIVE (上付きの 5) (U+2075) は DIGIT FIVE (数字の 5) (U+0035) に変更されます。その後、アプリケーションがコードページ 1252 から Unicode にデコードすると、文字を囲んでいた円はなくなり、2⁵ は 25 になります。さらに大幅に差異が現れる変換も考えられます。たとえば、Unicode の INFINITY (無限大) 記号 (U+221E) は DIGIT EIGHT (数字の 8) (U+0038) にマッピングされることがあります。

最適なストラテジはコードページごとに異なるため、詳細には文書化されていません。たとえば、全角のアルファベットがより一般的な半角のアルファベットにマッピングされるコードページもあれば、そのようなマッピングが行われないコードページもあります。

積極的な最適ストラテジでも、一部のエンコーディングの一部の文字には可能な対応がない場合があります。たとえば、中国語の漢字から、コードページ 1252 への適切なマッピング候補はありません。その場合は、置換文字列が使用されます。既定では、この文字列は単一の QUESTION MARK (疑問符) (U+003F) です。

最適マッピングは、Encoding の既定の動作であり、Unicode データをコードページデータにエンコードします。この動作に依存するレガシアプリケーションが存在します。ただし、ほとんどの新しいアプリケーションでは、セキュリティ上の理由から、最適動作の使用を避ける必要がありますたとえば、アプリケーションで、最適エンコードを使用してドメイン名を付けないでください。

アプリケーションでは次のような最適マッピングに代わる方法を使用する必要があります。

フォールバックの問題を回避するには、Unicode エンコーディング (UTF8Encoding、UnicodeEncoding、および UTF32Encoding) のみを使用します。

注意 :
UTF7Encoding は技術的には Unicode エンコーディングですが、堅牢度および安全性が他のエンコーディングほど高くありません。状況によっては、1 ビットの変更により、UTF-7 文字列全体の解釈が完全に変わる場合があります。他方、大幅に異なる UTF-7 文字列が、エンコードの結果、同じテキストになる可能性もあります。したがって、選択の余地がある場合は、UTF-7 を使用しないでください。UTF-7 よりも UTF-8 を使用することをお勧めします。

UTF7Encoding は技術的には Unicode エンコーディングですが、堅牢度および安全性が他のエンコーディングほど高くありません。状況によっては、1 ビットの変更により、UTF-7 文字列全体の解釈が完全に変わる場合があります。他方、大幅に異なる UTF-7 文字列が、エンコードの結果、同じテキストになる可能性もあります。したがって、選択の余地がある場合は、UTF-7 を使用しないでください。UTF-7 よりも UTF-8 を使用することをお勧めします。

文字が正確にマッピングされない場合は、EncoderExceptionFallback および DecoderExceptionFallback を使用して、例外 (それぞれ EncoderFallbackException および DecoderFallbackException) をスローします。
文字が正確にマッピングされない場合に置換文字列で置換するには、EncoderReplacementFallback および DecoderReplacementFallback を常に使用します。これは ASCIIEncoding の既定の動作です。既定では、この文字列は単に疑問符になりますが、アプリケーションで別の文字列を選択できるメソッドが用意されています。これは通常は単一の文字ですが、単一でなくてもかまいません。テキストを Unicode に変換する場合に使用される DecoderReplacementFallback では、一般的に使用される文字は REPLACEMENT CHARACTER (U+FFFD) です。
望ましいストラテジを実装するには、カスタマイズした EncoderFallback と DecoderFallback の両方またはいずれか一方を使用します。フォールバックのエンコーディングのアプリケーションサンプルを参照してください。

最適エンコード (またはデコード) のフォールバックストラテジには、さらに 2 つの注意点があります。

最適なものを選択するのは主にエンコード時の問題であり、デコード時の問題ではありません。Unicode に正常にマッピングできない文字を含むコードページはほとんどありません。そのような文字は一般的に使用されていないため、Unicode から除外されました。
最適フォールバックに対応するサポート対象の名前付きオブジェクトはありません。最適フォールバックはコードページごとに異なります。アプリケーションが単一の Encoding オブジェクトについて最適フォールバックと他のフォールバックを切り替える必要がある場合は、他のフォールバックオブジェクトを割り当てる前に、元の最適オブジェクトを変数にコピーしなければなりません。この場合、アプリケーションは変数の値を Encoding.EncoderFallback または Encoding.DecoderFallback に割り当てることにより、最適フォールバックを復元できます。