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

[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 を使うのは無駄過ぎです。

符号化語

[37] MIME encoded-word で使用する場合、 B 符号化ではなく Q 符号化を使うべきです。 (Base64 を使うのは無駄過ぎです。) ほとんどの場合は Q 符号化でも実質無変換で使用できます。

その他

CodePage

[33] Windows CodePage 65000 が素の UTF-7 に割り当てられているようです。

ファイル名

[32] 素の UTF-7 で書かれたファイルであることをファイル名の接尾辞 (拡張子) を使って示すことがたまにあります。

そのような場合に使われる接尾辞の例:

実装について

[6] 古い NN<anchor xmlns="urn:x-suika-fam-cx:markup:suikawiki:0:9:">Netscape Navigator</anchor> は +- に対応していないらしいです。。。

[7] >>6 のように間違った実装では PLUS SIGN をそのまま + と表すみたいです。

[8] もし >>6-7 のような問題が気になるのなら、 + は規則2で符号化することにすれば、(きっと) 問題ないでしょう。

[32] Outlook Express (版不明) では、 UTF-7 で本文を符号化すると、 Message-ID: 欄などでも意味もなく UTF-7 で符号化してしまうらしいです。 (encoded-word などではなく、欄本体が生の UTF-7。)

例

素の UTF-7

(RFC 2152 より。この例はもはや伝説になりつつあるな。。)

修正 UTF-7

メモ

[38] スラッシュドット ジャパン | UTF-7エンコードされたタグ文字列によるXSS脆弱性に注意 http://slashdot.jp/security/05/12/21/2318216.shtml (名無しさん 2005-12-22 01:14:03 +00:00)

[39] Bug 4868 - ASCIIと互換性のない文字コードはユーザーの指定で選択可能にすべきでない http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4868

>>38 の問題はUTF-7に限らずどんな文字コードでも、可能なビット列の組合わせによって生じうる。

(名無しさん [sage])

[40] The Old New Thing : Some files come up strange in Notepad http://blogs.msdn.com/oldnewthing/archive/2004/03/24/95235.aspx

BOM (名無しさん [sage])

[43] I'm not a Klingon : Please avoid UTF-7 (2007-05-02 10:19:34 +09:00 版) http://blogs.msdn.com/shawnste/archive/2007/05/01/please-avoid-utf-7.aspx (名無しさん 2007-05-02 01:22:20 +00:00)

[44] >>43 UTF-8 over MIME が使えない legacy な mail/NNTP の実装ってあるのか? UTF-7 over MIME only な UA なんて UTF-7 がでてきた極々初期くらいにしか存在しなかったのでは?

(名無しさん 2007-05-02 01:24:35 +00:00)

[45] 葉っぱ日記 - そろそろ UTF-7 について一言いっとくか (2007-07-22 01:39:26 +09:00 版) http://d.hatena.ne.jp/hasegawayosuke/20070717/p1 (名無しさん)

[47] REC-PICS-services-961031 ( ( 版)) http://www.w3.org/TR/REC-PICS-services/#Syntax

[5] Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting ( 版) https://code.google.com/p/browsersec/wiki/Part2#Character_set_handling_and_detection

[9] DRAFT-PICS-services-970620 () https://www.w3.org/PICS/Member/NG/DRAFT-PICS-services-970620.html#Syntax

[10] REC-PICS-services-961031 () https://www.w3.org/TR/REC-PICS-services-961031