UTF-7

UTF-7 (7- bit Unicode Transformation Format ) は、 ASCII文字のストリームを使用してUnicodeテキストを表現するための、廃止された可変長文字エンコーディングです。元々は、インターネット電子メールメッセージで使用するUnicodeテキストをエンコードする手段として、 UTF-8とquoted-printableの組み合わせよりも効率的なものを提供することを目的としていました。

UTF-7は（RFCによれば）「Unicode変換フォーマット」ではありません。なぜなら、定義上はBMP（最初の65536個のUnicodeコードポイント。絵文字やその他の多くの文字は含まれません）のコードポイントしかエンコードできないからです。しかし、UTF-7トランスレータがUTF-16との間で変換を行う場合、各サロゲートハーフを16ビットコードポイントであるかのようにエンコードすることができ（そしておそらく実際にエンコードしています）、したがってすべてのコードポイントをエンコードできます。他のUTF-7ソフトウェア（UTF-32やUTF-8へのトランスレータなど）がこれをサポートしているかどうかは不明です。

UTF-7 はUnicode コンソーシアムの公式標準になったことはありません。セキュリティ上の問題があることが知られており、そのためソフトウェアは UTF-7 の使用を無効にするように変更されています。^{[ 1 ]} HTML 5では禁止されています。^{[ 2 ] [ 3 ]}

電子メールフォーマットの最新標準であるMIMEでは、 ASCII範囲を超えるバイト値を使用したヘッダーのエンコードは禁止されています。MIMEではメッセージ本文をさまざまな文字セット（ASCIIよりも広い範囲）でエンコードできますが、基盤となる伝送インフラストラクチャ（主要な電子メール転送標準であるSMTP ）は依然として8ビットクリーンであることが保証されていません。そのため、疑わしい場合には、複雑なコンテンツ転送エンコーディングを適用する必要があります。残念ながら、Base64には、MIME以外のクライアントではASCII文字さえも読み取れなくなるという欠点があります。一方、UTF-8とquoted-printableを組み合わせると、サイズ効率が非常に悪いフォーマットが生成され、BMP内の非ASCII文字には6 ～ 9バイト、BMP外の文字には12バイトが必要になります。

エンコード時に特定のルールに従えば、UTF-7 は基盤となる MIME転送エンコーディングを使用せずに電子メールで送信できますが、テキスト文字セットとして明示的に識別する必要があります。さらに、「件名:」などの電子メールヘッダー内で使用する場合は、UTF-7 は文字セットを識別する MIMEエンコードされたワード内に含まれていなければなりません。エンコードされたワードはquoted-printableまたはBase64のいずれかの使用を強制するため、UTF-7 は、quoted-printable (またはその派生形である RFC 2047/1522 "Q" エンコーディング) と組み合わせたときに二重エスケープを避けるために、エスケープ文字として = 記号を使用しないように設計されています。

UTF-7 は処理が非常に難しいため、一般的にはアプリケーション内でネイティブ表現として使用されません。UTF-8 と quoted-printable または Base64 の組み合わせよりもサイズが小さいという利点があるにもかかわらず、現在は消滅したインターネットメールコンソーシアムは使用を推奨しませんでした。^{[ 4 ]}

8BITMIMEも導入され、メッセージ本文を7ビット形式でエンコードする必要性を軽減しました。

インターネットメッセージアクセスプロトコル（IMAP）電子メール取得プロトコルバージョン4 rev 1では、「国際」メールボックス名に、UTF-7の修正版（「mUTF-7」と呼ばれることもある^{[ 5 ]}）が使用されていました。 ^{[ 6 ]} 次のバージョンであるIMAPバージョン4 rev 2では、代わりにUTF-8が使用されています。^{[ 7 ]}

UTF-7 は、RFC 1642 「Unicode のメール安全変換フォーマット」で実験的なプロトコルとして初めて提案されました。このRFC は、標準にはならなかった情報提供 RFC である RFC 2152 によって廃止されました。RFC 2152 には、「いかなる種類のインターネット標準も規定していない」と明記されています。にもかかわらず、IANA の文字セット一覧では、RFC 2152 が UTF-7 の定義として引用されています。また、UTF-7 は Unicode 標準でもありません。Unicode 標準 5.0には、UTF-8、UTF-16、UTF-32 のみがリストされています。RFC 2060 で規定された修正版もあり、これは UTF-7 と識別されることがあります。

一部の文字は、単一のASCIIバイトとして直接表現できます。最初のグループは「直接文字」と呼ばれ、62個の英数字と9個の記号が含まれます。直接文字は、そのまま含めても安全です。もう1つの主要なグループは「オプションの直接文字」と呼ばれ、 U+ 0020 ～ U+007Eの範囲にある印刷可能な文字のうち、スペースを除くすべての文字が含まれます（文字と文字は、JIS-Romanなどの「ASCIIのバリアント」で再定義されているため除外されます）。オプションの直接文字を使用すると、サイズが小さくなり、人間の読みやすさが向上しますが、設計の悪いメールゲートウェイなどによって破損する可能性が高くなり、ヘッダーフィールドのエンコードされた単語で使用する場合は、追加のエスケープが必要になる場合があります。' ( ) , - . / : ?~ \ +\~

スペース、タブ、キャリッジリターン、ラインフィードも、単一のASCIIバイトとして直接表現できます。ただし、エンコードされたテキストを電子メールで使用する場合は、これらの文字が電子メールに適したコンテンツ転送エンコードをさらに必要としない方法で使用されていることを確認する必要があります。プラス記号（+）は、としてエンコードできます+-。

その他の文字はUTF-16でエンコードされ(したがって U+10000 以上は 2 つのサロゲートにエンコードされます)、次に修正 Base64でエンコードされます。修正 Base64 エンコードされた UTF-16 のブロックの開始は、+記号で示されます。終了は、修正 Base64 セットに含まれない任意の文字で示されます。修正 Base64 の後の文字が-(ASCIIハイフンマイナス) の場合、デコーダーによって消費され、デコードは次の文字から再開されます。それ以外の場合は、デコードが Base64 の後の文字から再開されます。

• " Hello, World!" は " " としてエンコードされますHello, World+ACE-" "
• " 1 + 1 = 2" は " " としてエンコードされます1 +- 1 +AD0- 2" "
• 「£1」は「 」としてエンコードされます。ポンド記号+AKM-1のUnicodeコードポイントはU+00A3で、これは以下の表のように修正Base64に変換されます。2ビットが余るので、0にパディングされます。

バイトオーダーマーク（BOM）は、ストリームまたはファイルの先頭にあるオプションの特殊なバイトシーケンスで、データ自体ではありませんが、後続のデータに使用されるエンコーディングを示します。エンコーディングを示すメタデータがない場合に使用できます。特定のエンコーディング方式の場合、それはその方式のUnicodeコードポイントの表現ですU+FEFF。^{[ 8 ]}

通常は単一の固定バイト列ですが、UTF-7 では、UTF-7 エンコーディングの 4 番目のバイトの最後の 2 ビットが次のU+FEFF文字に属するため、4 つのビットパターンが可能になり、したがって 4 番目の位置に 4 つの異なるバイトが存在する可能性があるため、4 つのバリエーションが現れることがあります。Unicodeバイト順序マークの表の UTF-7 エントリを参照してください。^{[ 8 ]}

UTF-7では、同じソース文字列を複数の方法で表現できます。特に、ASCII文字はUnicodeブロックの一部として表現できます。そのため、後でUTF-7として解釈される可能性のある文字列に対して、標準的なASCIIベースのエスケープ処理や検証処理が使用される場合、Unicodeブロックを利用して悪意のある文字列を紛れ込ませることが可能です。この問題を軽減するために、システムは検証の前にデコードを実行し、UTF-7の自動検出を試みないようにする必要があります。

Windows NT版のInternet Explorerの一部のバージョンの文字セット検出機能は、ページを UTF-7 として解釈するように騙される可能性があります。これは、HTML タグの区切り文字である <p>と<p>を UTF-7 でエンコードすると、ほとんどのバリデーターが単純なテキストとして通過させてしまうため、クロスサイトスクリプティング攻撃に悪用される可能性があります。^{[ 9 ]}<>+ADw-+AD4-

UTF-7 は、少なくとも Microsoft ソフトウェア (.NET) においては廃止されたとみなされており、2020 年に .NET 5 では、以前 UTF-7 をサポートしていたコード パスが意図的に破壊されました (セキュリティ上の問題を防止するため)。^{[ 1 ]}

• Unicodeエンコーディングの比較