UTF-7

[3] UTF-7 は UCS (ISO/IEC 10646/Unicode) の符号化方式の一つで、 U+0080〜U+10FFFF を ASCII の図形文字に Base64 を使って転写するものです。

[2] Experimental RFC である RFC 1642 <urn:ietf:rfc:1642> で定義されていましたが、この RFC は RFC 2152 <urn:ietf:rfc:2152> (Informational) で廃止されました。 RFC 2152 は editorial な変更以外は RFC 1642 と同じ内容です。

[12] UTF-7 は 7ビットの制限がある電子メイル (特に SMTP) での使用を想定して設計されたものですが、現在では使用は非推奨とされています。 (UTF-8 を MIME の Base64 で包むなりして送るのが IETF のお勧めらしいです。)

IMAP では修正 UTF-7 が使われています。

[4] UTF-7 は任意のUnicode文字を ASCII文字として表現するため、利用可能な文字の検査を迂回して XSS のような脆弱な状況を作り出したり、自動判別に UTF-7 と誤認させて不正なプログラムを実行させたりすることが容易でした。このため UTF-7 を実装すること自体が深刻なセキュリティーの問題と認識されるようになり、現在では使われなくなりました。

仕様書

符号化方式

[13]

集合 D (直接符号化文字): [A-Za-z0-9'(),-./:?]
集合 O (任意符号化文字): [!"#$%&*;<=>@[]^_`{|}]
集合 B (修正 Base64): Base64 字母 (= を除く。)

[14] 規則1 (直接符号化): 集合 D と集合 O の文字は、そのまま 1 オクテットの ASCII で符号化。集合 O の文字は使用する頭欄や通過する関門によっては問題があり得るから注意。

[15] 規則2 (Unicode シフト符号化): 任意の Unicode 文字 (UTF-16BE で表したもの。) を修正 Base64 で符号化。この前に + を置く。これは集合 B に無い文字 (CR や LF などを含む。) が出現するまで続く。集合 B に無い文字が - の時は、これを棄てる。

規則2を別の言い方で説明すると、こう。任意の Unicode 文字(列)は修正 Base64 で符号化して、頭とお尻に + と - をつける。但し、この塊の直後が集合 B に含まれない文字である場合は、 - を省略しても良い。

+- は、 + を表す。

[16] 規則3: SP (U+0020), HT (U+0009), CR (U+000D), LF (U+000A) は、そのまま1オクテットの ASCII で表現。

[17] RFC 2152 は集合 O の ` を ' に誤植しています。 (RFC 1642 はあってるのに。) 気になるなら両方とも集合 O として扱うのが良いかもしれません。

[18] これをみるとわかるように、 UTF-7 は他の UTF-8 などの符号化方式とは違って UCS 専用の転送符号化のような趣です。 Charset の一種ではなく、 MIME の一部であったなら、もう少しは普及したかもしれません。

UTF-7 の修正 Base64

[19] 基本的には MIME の Base64 なのですが、詰め物 = は使わずに、 0 のビットがあるとして処理します。 (復号の時は余ったのを棄てるだけで良い。)

(だけど最後が U+0000 だと困るような。 U+0000 は NUL だし、ステステなのかな。)

[11] >>19 C 以来 (それ以前から??) NULL って冷遇されてますよねぇ。 (っていうか NULL ってそういうもの?)

[35] MIME の改行に関する規定もないことになってるような。 UTF-7 RFC にそう明記されていたっけ?

Korean mess と UTF-7

[1] Charset 名 UNICODE-1-1-UTF-7 は、 Unicode 1.1 (ハングルの大移動以前) のデータを UTF-7 で符号化したものに対して使います。

修正 UTF-7

[24] IMAP 修正 (modified) UTF-7 は、 RFC 2060 <urn:ietf:rfc:2060> (IMAP) 5.1.3 で定義されています。 (決まった呼び名はなく、IMAP の UTF-7 とか呼びたい人が好きな名前で呼んでいます。)

[25] & を除く印字可能 ASCII 文字 (SP を含む。) は全て、そのままにします。それ以外の文字 (C0, DEL を含む。) は修正修正 Base64 を使います。

修正修正 Base64 は、前に & が、後に - が来ます。 (明記されてはいませんが、修正前の UTF-7 とは異なり、 - は省略不能だと思います。) Base64 字母の / は IMAP 的意味との衝突防止から , で代用します。

&- が & を表します。

[27] これだけ違うと別の名前付けた方がよかったと思うぞ。

UTF-7 を採用した規格

[34] UTF-7 を積極的に (単なる可能な選択肢の一つとしてではなく、実装必須であろうが任意選択であろうが規格の完全な一部として) 採用している規格には次のようなものがあります。

IMAP
- IMAP は名前に UTF-7 を使っています。但し、素の UTF-7 ではなく、アルゴリズムが同じなだけで互換性のない修正版 UTF-7 です。
PICS (application/pics-service)
- 記述に UTF-7 を使っています。
- 区切子と使う二重引用符以外の集合 O の文字は直接符号化します。
- 仕様書: REC-PICS-services-961031 <http://www.w3.org/TR/REC-PICS-services#Syntax>

[42] sdfs (名無しさん 2007-04-17 04:43:31 +00:00)

MIME での使用

素の UTF-7

[28] MIME で使用する時は、 charset 名 UTF-7 または UNICODE-1-1-UTF-7 (RFC 1642) を使います。

IANA 登録簿に無い名前では、 UTF7, CP65000, UNICODE-2-0-UTF-7, UNICODE-2-0-UTF7, X-UNICODE-2-0-UTF-7 が観測されてます。

[29] SMTP で使う時は、 LINE SEPARATOR (U+2028) tp PARAGRAPH SEPARATOR (U+2029) を CRLF に変換してあげたら良さげ、って RFC 2152 に書いてあります。でも実際 LS とか PS を使ってる文書ってあるんですかね?

MUST じゃないし、無視していいと思います。 PS を CRLF に変換するのは明らかに情報劣化ですし。 (plain‐text で PS なんて使うなっていう話もありますが。)

修正 UTF-7

[30] IMAP の修正 UTF-7 の名前としては、 X-IMAP4-Modified-UTF7, UTF-7-for-IMAP が観測されてます。 IANA 登録簿に登録しようという動きがありましたが、情報交換用でない charset を登録する必要は無いという意見があって、立ち消えになってしまいました。 (登録派の意見は、プログラムの内部名として使うときに IANA 名が標準化されていたほうが便利、というもの。確かに根拠としては弱い。)

ちなみに、 PHP では UTF7-IMAP という名前を使っています。

内容転送符号化

[36] MIME で使用する場合、 Content-Transfer-Encoding は不要です。 (7bit で十分です。)

ASCII すら保証されない転送路 (いまどきあるのか?) を通す必要がある時は、適当な CTE を使うか、集合 O の文字も UTF-7 で修正 Base64 を使って符号化すればよいでしょう。 (集合 D の文字が危険な場合は CTE を使うしかありません。関門などで charset を勝手に変えたくない場合も CTE を使うしかありません。)

CTE を使う場合は Base64 ではなく、 Quoted-Printable を使うべきです。 Base64 を使うのは無駄過ぎです。