#?SuikaWiki/0.9 page-icon="字β" [3] UTF-7 は [[UCS]] ([[ISO/IEC10646]]/[[Unicode]]) の[[符号化方式]]の一つで、 U+0080〜U+10FFFF を ASCII の[[図形文字]]に [[Base64]] を使って転写するものです。 Experimental RFC である [[RFC1642]] で定義されていましたが、 この RFC は [[RFC2152]] (Informational) で廃止されました。 RFC 2152 は editorial な変更以外は RFC 1642 と同じ内容です。 UTF-7 は 7ビットの制限がある[[電子メイル]] (特に [[SMTP]]) での使用を想定して設計されたものですが、現在では 使用は非推奨とされています。 ([[UTF-8]] を [[MIME]] の [[Base64]] で包むなりして送るのが [[IETF]] お勧めらしいです。) [[IMAP]] では修正 UTF-7 が使われています。 *符号化方式 :集合 D (直接符号化文字): [A-Za-z0-9'(),-./:?] :集合 O (任意符号化文字): [!"#$%&*;<=>@[]^_`{|}] :集合 B (修正 Base64): Base64 字母 ("=" を除く。) 規則1 (直接符号化): 集合 D と集合 O の文字は、そのまま 1オクテットの [[ASCII]] で符号化。集合 O の文字は使用する頭欄 や通過する関門によっては問題があり得るから注意。 規則2 (Unicode シフト符号化): 任意の Unicode 文字 ([[UTF-16]]BE で表したもの。) を修正 [[Base64]] で符号化。この前に "+" を置く。これは集合 B に無い文字 (CR や LF などを含む。) が出現する まで続く。「集合 B に無い文字」が "-" の時は、これを棄てる。 規則2を別の言い方で説明すると、こう。任意の Unicode 文字(列)は修正 Base64 で符号化して、頭とお尻に "+" と "-" をつける。但し、この塊の直後が集合 B に含まれない文字である場合は、 "-" を省略しても良い。 "+-" は、 "+" を表す。 規則3: SP (U+0020), HT (U+0009), CR (U+000D), LF (U+000A) は、そのまま1オクテットの ASCII で表現。 RFC 2152 は集合 O の "`" を "'" に誤植しています。 (RFC 1642 はあってるのに。) 気になるなら両方とも集合 O として扱うのが良いかも知れません。 *修正 Base64 詰め物 "=" は使わずに、 0 のビットがあるとして処理する。 (復号の時は余ったのを棄てるだけで良い。) (だけど最後が U+0000 だと困るような。 U+0000 は NUL だし、 ステステなのかな。) [[#comment]] *例 -A+ImIDkQ. (AΑ.) (U+0041 U+2262 U+0391 U+002E) -Hi Mom -+Jjo--! (Hi Mom --!) (U+0048 U+0069 U+0020 U+004D U+006F U+006D U+0020 U+002D U+263A U+002D U+0021) -+ZeVnLIqe- (日本語) (65E5,672C,8A9E) -Item 3 is +AKM-1. (£) (RFC 2152 より。この例はもはや伝説になりつつあるな。。) *修正 (modified) UTF-7 RFC 2060 (IMAP) 5.1.3 で定義されています。 "&" を除く印字可能 ASCII 文字 (SP を含む。) は全て、そのままにします。 それ以外の文字 ([[C0]], DEL を含む。) は修正修正 Base64 を使います。 修正修正 Base64 は、前に "&" が、後に "-" が来ます。 (明記されてはいませんが、 "-" は省略不能だと思います。) Base64 字母の "/" は "," で代用します。 "&-" が "&" を表します。 例: ~peter/mail/&ZeVnLIqe-/&U,BTFw- - 2002-08-16 (Fri) 21:13:11 ''[[和]]'' : これだけ違うと別の名前付けた方がよかったと思うぞ。 [[#comment]] *MIME での使用 [[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 が観測されてます。 [[SMTP]] で使う時は、 LINE SEPARATOR (U+2028) PARAGRAPH SEPARATOR (U+2029) を CRLF に変換してあげたら良さげ、って RFC 2152 に書いてあります。 でも実際 LS とか PS を使ってる文書ってあるんですかね? MUST じゃないし、無視していいと思います。 PS を CRLF に変換するのは 明らかに情報劣化ですし。 (plain-text で PS なんて使うなっていう 話もありますが。) [[#comment]] **修正 UTF-7 IMAP の修正 UTF-7 の名前としては、 X-IMAP4-Modified-UTF7, UTF-7-for-IMAP が観測されてます。 IANA 登録簿に登録しようという 動きがありましたが、情報交換用でない charset を登録する必要は無いという意見があって、立ち消えになってしまいました。 ちなみに、 [[PHP]] では UTF7-IMAP という名前を使っています。 [[#comment]] *UTF-7 一般について - [1] 2002-10-29 (火) 20:31 ''[[名無しさん]]'': ''UNICODE-1-1-UTF-7'' は、 [[Unicode1.1]] ([[ハングルの大移動]]以前) のデータを UTF-7 で符号化したものに対して使います。 - [2] 2002-10-29 (火) 20:32 ''[[名無しさん]]'': [[perl]] での実装としては、 [[Encode::Unicode::UTF7]] () があります。 - [4] >>2 は修正 U7 にも対応してますね。 - [5] >>2-4 標準の [[Encode]] にないのが不思議。 [[#comment]] - [6] 古い [[NN]] は [CODE[+-]] に対応していないらしいです。。。 - [7] >>6 のように間違った実装では [CODE(CHARNAME)[PLUS SIGN]] をそのまま [CODE[+]] と表すみたいです。 - [8] もし >>6-7 のような問題が気になるのなら、「+」は規則2で符号化することにすれば、(きっと) 問題ないでしょう。