[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 を実装すること自体が深刻なセキュリティーの問題と認識されるようになり、 現在では使われなくなりました。
[A-Za-z0-9'(),-./:?]
[!"#$%&*;<=>@[]^_`{|}]
=
を除く。)[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 の一部であったなら、 もう少しは普及したかもしれません。
[19] 基本的には MIME の Base64 なのですが、
詰め物 =
は使わずに、 0 のビットがあるとして処理します。
(復号の時は余ったのを棄てるだけで良い。)
(だけど最後が U+0000
だと困るような。 U+0000
は
NUL
だし、ステステなのかな。)
[11] >>19 C 以来 (それ以前から??) NULL
って冷遇されてますよねぇ。 (っていうか NULL
ってそういうもの?)
[35] MIME の改行に関する規定もないことになってるような。 UTF-7 RFC にそう明記されていたっけ?
[1]
Charset 名 UNICODE-1-1-UTF-7
は、 Unicode 1.1
(ハングルの大移動以前) のデータを UTF-7
で符号化したものに対して使います。
[24]
IMAP 修正 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] これだけ違うと別の名前付けた方がよかったと思うぞ。
[34] UTF-7 を積極的に (単なる可能な選択肢の一つとしてではなく、 実装必須であろうが任意選択であろうが規格の完全な一部として) 採用している規格には次のようなものがあります。
application/pics-service
)[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
なんて使うなっていう
話もありますが。)
[30]
IMAP の修正 UTF-7 の名前としては、 X-IMAP4-Modified-UTF7
,
UTF-7-for-IMAP
が観測されてます。
IANA 登録簿に登録しようという動きがありましたが、情報交換用でない charset
を登録する必要は無いという意見があって、立ち消えになってしまいました。
(登録派の意見は、プログラムの内部名として使うときに IANA
名が標準化されていたほうが便利、というもの。確かに根拠としては弱い。)
[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
符号化でも実質無変換で使用できます。
[33] Windows CodePage 65000 が素の UTF-7 に割り当てられているようです。
[32] 素の UTF-7 で書かれたファイルであることをファイル名の接尾辞 (拡張子) を使って示すことがたまにあります。
そのような場合に使われる接尾辞の例:
[6] 古い NN は +-
に対応していないらしいです。。。
[7] >>6 のように間違った実装では PLUS SIGN
をそのまま
+
と表すみたいです。
[8] もし >>6-7 のような問題が気になるのなら、
+
は規則2で符号化することにすれば、(きっと) 問題ないでしょう。
[32] Outlook Express (版不明) では、 UTF-7
で本文を符号化すると、 Message-ID:
欄などでも意味もなく
UTF-7 で符号化してしまうらしいです。 (encoded-word
などではなく、欄本体が生の UTF-7。)
<NOT IDENTICAL TO>
Α.)
(U+0041
U+2262
U+0391
U+002E
)<WHITE SMILING FACE>
-!)
(U+0048
U+0069
U+0020
U+004D
U+006F
U+006D
U+0020
U+002D
U+263A
U+002D
U+0021
)U+65E5
U+672C
U+8A9E
)(RFC 2152 より。この例はもはや伝説になりつつあるな。。)
[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>
[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>