ASCII、Unicode、テキスト表現

ASCII（American Standard Code for Information Interchange）は1963年に標準化され、7ビットで128文字（値0～127）をエンコードします。英語のアルファベット（大文字と小文字）、数字、句読点、制御文字を扱えます。

ASCIIは、英語とアメリカの通信機器向けに設計されました。本来の目的には適していましたが、英語以外の言語には根本的に不十分でした。

ASCIIの最初の32文字（0～31）とDEL（127）は制御文字です。これらはもともとテレタイプ端末を制御するために設計されました。LF（改行、10）、CR（復帰、13）、BEL（ベル、7）、TAB（9）、ESC（27）などがあります。

暗号技術の文脈では、制御文字が問題を引き起こすことがあります。ヌルバイト（0x00）はC文字列を途中で終了させ、DELやESC文字は端末エミュレーターによって解釈される可能性があります。

各国はASCIIの8ビット目（値128～255）を使って独自の拡張を作成し、互換性のないエンコーディングが数百種類も生まれました。西ヨーロッパ言語向けのISO-8859-1（Latin-1）、ロシア語向けのKOI-8R、中国語向けのBig5などです。

あるエンコーディングで保存した文書を別のエンコーディングで開くと、文字化けして見えます。普遍的な標準がなかったため、1980年代から1990年代にかけて、国際的なソフトウェア開発は大きな課題となりました。

Unicodeは、世界中のすべての文字体系を網羅する単一の普遍的な文字集合を提供するために作られました。現在では、歴史的な文字体系や記号を含む161の用字系を対象に、149,000を超える文字を定義しています。

Unicodeは、文字の同一性（"A"を表すU+0041のようなコードポイント）と、エンコーディング（そのコードポイントをバイトに格納する方法）を分離します。この分離により、同じ文字を複数のエンコーディング形式で表現できます。

UTF-8は、Unicodeのコードポイントを1～4バイトでエンコードします。ASCII文字（U+0000～U+007F）はASCII値と同じ1バイトだけを使用するため、UTF-8はASCIIとの後方互換性があります。

U+0080～U+07FFの文字は2バイトを使用します。U+0800～U+FFFFは3バイトを使用し、中国語、日本語、韓国語など、一般的な用字系の大部分をカバーします。U+10000以降は4バイトを使用します。

UTF-16は、最も一般的な文字（基本多言語面、U+0000～U+FFFF）に2バイトを使用し、U+FFFFを超える文字には4バイト（サロゲートペア）を使用します。WindowsとJavaの内部で使用されています。

UTF-32はコードポイントごとに必ず4バイトを使用するため、固定幅で文字位置によるインデックス参照が容易です。ただし、ASCIIが大部分を占めるテキストでは無駄が多くなります。高速なランダムアクセスのため、一部の内部表現で使用されています。

バイトオーダーマーク（BOM）は、バイト順序とエンコーディングを示すためにファイルの先頭に置かれるUnicode文字U+FEFFです。UTF-16では、ビッグエンディアン（FE FF）とリトルエンディアン（FF FE）を区別します。

UTF-8ではバイト順序の問題がないためBOM（EF BB BF）は不要ですが、一部のWindowsソフトウェアはそれでもBOMを追加します。これにより、BOMがマーカーではなくデータとして扱われる暗号アプリケーションで問題が発生します。

暗号学的ハッシュ関数やMACは、抽象的な文字ではなくバイト列を処理します。同じ文字列"café"でも、UTF-8では4バイト（63 61 66 C3 A9）、Latin-1では4バイト（63 61 66 E9）というように、エンコード結果が異なります。

2つのシステムが同じ文字列をハッシュしても、異なるエンコーディングを使用すれば、異なるハッシュが生成され、認証に失敗します。相互運用性を確保するため、暗号プロトコルではエンコーディングを明示的に指定する必要があります。

絵文字は追加多言語面にあるUnicode文字です。「ニヤリと笑う顔」の絵文字（U+1F600）は、UTF-8では4バイト（F0 9F 98 80）にエンコードされます。

セキュリティの場面では、絵文字や全角Unicode文字がホモグラフ攻撃に利用されてきました。たとえば、"xn--pple-43d.com"のようなURLは「apple.com」に見えるため、ユーザーをだまして悪意のあるサイトにアクセスさせる可能性があります。

一部の文字は、複数のUnicode形式で表現できます。「アクサン付きのe」はU+00E9（合成済み文字）にも、U+0065 U+0301（eの後に結合アクサンを続けた分解形式）にもできます。これらは同じように見えますが、バイト表現は異なります。

ハッシュ前にUnicodeを正規化しない暗号システムでは、見た目が同じ文字列に対して異なるハッシュが生成される可能性があります。テキストに暗号処理を適用する前には、一般的にNFKC正規化が推奨されます。

暗号システムを実装する際、エンコーディングの選択は文書化が必要な重要な決定事項です。パスワードはハッシュする前にUTF-8としてエンコードする必要があります。プロトコルのフィールドでは、仕様書でエンコーディングを指定してください。

エンコーディングの不一致による相互運用性の失敗は、暗号システムでよくあるバグの原因です。同じプロトコルを実装した2つのシステムでも、文字列のエンコード方法が異なると、認証結果が異なる可能性があります。

UTF-8エンコーディングの理解度を確認しましょう。

ASCIIは7ビットで128文字を扱います。Unicodeは、すべての人間の文字体系に対応する普遍的なコードポイント空間を提供します。UTF-8はUnicodeを1～4バイトでエンコードし、ASCIIはその1バイトのサブセットです。

暗号技術では、ハッシュ関数がバイトを処理するため、エンコーディングが重要です。同じテキストでも、エンコーディングが異なれば異なるハッシュが生成されます。テキストに暗号処理を行う前には、Unicodeの正規化が不可欠です。