UTF-7

UTF-7とは

UTF-7（UTF-7, ユーティーエフセブン）は、[ISO/IEC 10646|ISO_IEC 10646]とUnicodeで利用可能な7ビット符号単位の文字符号化形式、および文字符号化スキームです。主に、7ビット環境でのみデータ送信が可能なプロトコル、例えばメールやニュースなどの環境において、Unicodeで記述されたメールを送信することを可能にするために開発されました。

しかしながら、現在ではUTF-7を正しく実装していないアプリケーションにおいて、セキュリティ上の脆弱性が発見されることがあるため、利用される頻度は少なくなっています。一方で、IMAP4では、UTF-7を改良した「修正UTF-7」という規格が使用されており、2010年代現在でも頻繁に利用されています。

UTF-7の仕組み

UTF-7では、以下のルールに従って文字を符号化します。

直接表記: 62個のアルファベット（a-z, A-Z）と9個の記号（' ( ) , - . / : ?）は、そのまま表記します。
符号化: それ以外の文字は、UTF-16のビッグエンディアンで符号化した後、修正BASE64で符号化します。修正BASE64とは、BASE64エンコードから「=」を取り除いた形式のことです。
変換記号: BASE64で変換した文字列の前には「+」を、後には「-」を置きます。
「+」の表現: 「+」という文字自体は「+-」と表記します。

例:

「Hello, World!」 → 「Hello, World!」（そのまま）
「1 + 1 = 2」 → 「1 +- 1 = 2」（「+」は「+-」に変換）
「£1」 → 「+AKM-1」（ポンド記号U+00A3はBASE64で表記）

エンコードとデコードの例

エンコードの例:

「£†」（U+00A3 U+2020）の場合

1. U+00A3とU+2020をUTF-16のビッグエンディアンで表現すると、それぞれ「00A3」と「2020」になります。
2. これらを連結して「00A32020」とします。
3. これをBASE64でエンコードすると「AKMgIA」となります。
4. 修正BASE64で「AKMgIA」となり、前後に「+」「-」を付与して「+AKMgIA-」となります。

デコードの例:

1. 「+AKMgIA-」は、前後の「+」「-」を取り除き、修正BASE64の文字列「AKMgIA」を得ます。
2. 「AKMgIA」をBASE64でデコードすると、「00A32020」となります。
3. これをUTF-16のビッグエンディアンとして解釈すると、「00A3」はU+00A3（£）、「2020」はU+2020（†）となります。

修正UTF-7

修正UTF-7（Modified UTF-7）は、IMAP4において多言語のフォルダ名（ディレクトリ名）を扱うために使用される規格です。これは、UTF-7をベースに、メールの一般的な利用環境を考慮して改良されたものです。

修正UTF-7の主な特徴:

直接表記: 「&」以外の印字可能なUS-ASCII文字は、そのまま表記されます。
符号化: それ以外の文字は、UTF-16のビッグエンディアンで符号化後、修正BASE64で符号化されます。
変換記号: BASE64変換された文字列の前には「&」を、後には「-」を置きます。
「&」の表現: 「&」という文字自体は「&-」と表記します。

導入の背景:

UTF-7には、メール環境で問題となるいくつかの点がありました。

UTF-7では、シフト文字として「+」を使用しますが、メールボックス名やニュースグループ名で「+」が頻繁に使われるため、衝突が生じる可能性がありました。
UTF-7の符号化には、「/」が含まれるBASE64が使われますが、「/」は階層区切り文字として広く利用されているため、混乱を招く可能性がありました。
UTF-7では、「\」や「~」の利用が禁止されていますが、これらはディレクトリ区切りやホームディレクトリを示す文字として使われることがあります。
UTF-7では、同じ文字列を表現するための複数の形式が存在し、特に印字可能なUS-ASCII文字が符号化された形式でも表現可能です。これにより、可読性が低下する可能性がありました。

修正UTF-7では、これらの問題を解決するために、メールやフォルダ名で頻出する文字を修正BASE64変換せずに、ほぼ平文のまま読めるように設計されています。

関連項目

文字コード

出典

RFC 1642
RFC 2152
* RFC 2060 （修正UTF-7の規格）

脚注

もう一度検索