[1] MIME 実体の頭領域で、実体に使われている 内容転送符号化 — CTE を示します。 CTE が使われていない時は、 使っているオクテット種を示します。
[53] 各プロトコルの既定値については、 MIME を参照。
[35] BEEP
BEEP で伝送される MIME実体に
Content-Transfer-Encoding:
頭欄が明記されていない場合の既定値は
binary
です。 RFC 3080 2.2
application/octet-stream
とするべき[225] GNU gettext により拡張された POファイルの頭部には
MIME-Version 欄などと合わせて
Content-Transfer-Encoding 欄を指定する必要がありますが、
実際にはまったく意味を持ちません。値は常に 8bit で構いません。
[3] MSA との関係
MSA は、必要で、かつ使用している
Content-Type に無害なら、
転送符号化を適用して構いません。
RFC 4409 8.4
値の大文字・小文字は区別しません。
MIME での既定値は "7bit" です。 HTTP には (RFC になった最終仕様には) CTE は存在しませんが、 相当する既定値的なものは "binary" です。
See also RFC-2045のCTE:の定義
符号化無し。一行998オクテット以下 (SMTPの制限)で、 行区切は CRLF。7ビットでは値 128 以上は出現しない。
値 0 (NULL) は出現しない。 13 (CR) と 10 (LF) は CRLF 以外としては出現しない。
ietf-token の登録簿は http://www.iana.org/assignments/transfer-encodings。 追加名は登録されていない。 MIME RFC は、相互通信性の観点から 新しい CTE は定義するべきじゃないって言ってる。
MIME 以前から使われて来た、 uuencode 用に、 x-uuencode とか x-uue とか x-uu とかが使われてる。
x-gzip64 は、 gzip で圧縮して base64 したもの。 Perl だと MIME::Decoder::Gzip64 てのがあるみたい。
圧縮 CTE が MIME で標準化されてない理由みたいなもの http://www.mew.org/ml/mew-dist-1.94/msg07639.html。なるほど。 納得できないけど理解はできるな。
| 7bit | %x01-09 / %x0B-0C / %x0E-7F / CRLF | MIME |
| 8bit | %x01-09 / %x0B-0C / %x0E-FF / CRLF | MIME |
| base64 | 64進数 Base64 | MIME |
| binary | %x00-FF | MIME |
| quoted-string | = | |
| x-gzip64 | GNU Zip + Base64 | |
| x-uu | uuencode | |
| x-uue | uuencode | |
| x-uuencode | uuencode | |
| x-uuencoded | uuencode |
[30] Uuencode を表す CTE 名は MIME ができてすぐの頃から複数種類使われています。 MIME が uuencode を採用しなかったのは電子メイル輸送路で必ずしも安全で無い文字を使うからで、 MIMEr の立場では uuencode は使うな、 Base64 を使え、ということで、そのために uuencode の CTE 名は標準化されませんでした。
現実には、すべての MUA が MIME を実装したわけではなく、しかも Base64 を復号するソフトウェアはまったく普及していなかったので (あるとしたら MIME 用ばかり)、 MIME MUA の利用者も含めた多くの人達が Base64 より uuencode を使いました。 MIME を実装した MUA の開発者も、 その需要に応えて uuencode を実装しましたが、その際に MIME の枠組みの中で CTE として使用するのは自然なことです。しかし標準化された CTE 名はない。かくして数々の uuencode のための CTE 名が生まれることになったのです。 (後から追加しようにも、 MIMEr に CTE の追加は RFC に書いてあるとおり、互換性のためによくないのだと一蹴されるだけです。)
MIMEr としては彼らの目指す美しき将来を描いていたのでしょうが、現実を甘く見過ぎていたという点で、 MIME の失敗の一つと言えるでしょう。
[39] HTTP には転送符号化 (Transfer-Encoding:)
と内容符号化 (Content-Encoding:) が存在します。
これらは CTE とは異なるものとされています。転送符号化と CTE
は用途が似ていますが、利用できる値と符号化は全く異なっていて、
直接変換できる関係にはありません。
[41] MIME から HTTP に変換するなら CTE を復号しないといけませんし、 HTTP から MIME に変換するなら必要に応じて CTE を適用することになります >>32。
[46] HTTP92 は MIME を HTTP に採用することを意図していたので、
Content-Transfer-Encoding: をHTTPヘッダーの一つに挙げ、
具体的には MIME の RFC を参照していました >>47。
(HTTP 向けの規定も必要 >>47 としていました。)
[50] RFC 4229 は HTTP92 を出典に状態「provisional」で
Content-Transfer-Encoding: を HTTPヘッダーとして
IANA登録簿に登録しています >>49。
[48] しかしその後の RFC となった HTTP 仕様書では、 HTTP
は MIME から派生したメッセージ形式とされており、
Content-Transfer-Encoding: は HTTPヘッダーとはされていません。
HTTP does not use the Content-Transfer-Encoding (CTE) field of
RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTPRFC 1521MIMEmustMUST remove any{Errata で削除} non-identityCTE{Errata で削除} ("quoted-printable" or "base64")encoding prior to delivering the response message to an HTTP client.
[15] HTTP は RFC 2045 の Content-Transfer-Encoding (CTE) 欄を使いません。 MIME に従ったプロトコルから HTTP への串や関門は「同等」でない CTE ("quoted-printable" と "base64") 符号化を HTTP クライアントへの応答メッセージで渡す前に解かなければなりません。
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway
shouldSHOULD label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.
[16] HTTP から MIME に従うプロトコルへの串と関門は、メッセージが適切な形式であってそのプロトコルでの安全な転送のために符号化することに責任を持ちます。 ここで「安全な転送」とは、使用するプロトコルの制限により決まります。 そうした串や関門は、向こうのプロトコルでの安全な転送のためになりそうであれば、適切な Content-Transfer-Encoding でデータを札付けするのが良いです。
注意: 注記のない修正点は RFC 1945 → RFC 2068 もの。
[43] OData は HTTP 応答メッセージに
Content-Transfer-Encoding: binary
を指定することを求めています >>42。
[45] OData は HTTP 応答メッセージに含まれる
multipart/mixed の本体部分のヘッダー
(こちらは定義上 MIMEヘッダー) でも
Content-Transfer-Encoding: binary
を指定することを求めています >>44。
[62]
FIPA MTP HTTP要求 multipart/mixed の実体のMIMEヘッダーで指定することが認められています。
8 bit っていう値を見ました。 spam でしたが。。。MIME 形式という言葉はしばしば用いられますけど、その意味は曖昧ですよね。本当に MIME 実体を指している事もあれば、単に Base64 の意味だったり、 uuencode 風に Base64 を包んだものだったり、或いは媒体型のことを言っていたり。7bits とかいう値を返したりするらしいですよ。x-base8, x-base10, x-base16 に対応しています。x-base-8 みたいに - が3つ共に入ってます。おまけに base-64 にまで入ってます。。。なお、 Base8/10/16 の説明はこの文書にあります。X-URL というのが使われています。 URI符号化かと思えばそうではなくて、 Content-Type: message/external-body; access-type=url みたいな意味 (本体が URI) のようです。7-bit, 8-bit, x-uu, x-uue, x-uuencode, uu, uue, uuencode, x-xx, x-xxe, x-xxencode, xx, xxe, xxencode, x-binhex, x-gzip64, gzip64 に触れています。x-unknown を送る MUA があるっぽい。x-uuencode が一番多くの MUA に理解されそうです。なんとなくですが。[13] File - ドリームキャストでできること http://www.mars.jstar.ne.jp/~a_zone/dc/file.htm : x-dreamcast-file というのを使ってます。単に binary のような気がしますが。。。
謎ですが意外と用例が見つかります。 なんでそんなに普及してるんでしょう? わけがわからん。
[14] Bommanews technical http://b-news.sourceforge.net/tech.html : 内部用として、 X-Bommanews-224-ZZZ というのを使っています。 224 は使用オクテット数 (0x20〜0xFF で 224), ZZZ は encoding block size で現時点では 40 固定。
内部用なのにニュースにうじゃうじゃ流れていたりします。なぜか。
なお、
X-Bommanews-224-40 以外の実例はまだ見つかっていません。
x-pp-base128 : 8ビットの怪しい形式 (参考 PostPet V3はOpenGL採用 http://slashdot.jp/comments.pl?sid=39332&cid=150006)x-ferrum-uids : IronDoc febase.h http://www.treedragon.com/ged/irondoc/febase.htm#fe_boxx-postpet/* という媒体型でセットで使われるみたい。 CTE と CT を分離できるものなのかは不明。x-ferrum-head/* 又は x-ferrum-menu/* という媒体型とセットで使用されるぽ。X-Zm-base64 : Zm は MUA 名の略号だろうな。 http://hp.ujf.cas.cz/mail/WA98_official/199707/19970718.html に例があるけど、単なる Base64。content-transfer-encoding 属性の値は x-native-xml 又は base64 とされています。前者は、 XML の標準の方法で文字実体を使うんだ云々といっていますが、実際には実体の展開は XML 処理系の仕事ですから、 XML 文書内における 7bit とか 8bit とか binary に相当するものとみていいでしょう。[21] gzip というのもしばしば見かけますが、ほとんどが HTTP での用例なので Content-Encoding と勘違いしているのでしょう。ほんとにそんなので機能しているのですかね? (WWWブラウザで見て確認くらいしないのかなー。)
[28] >>21 x-gzip というのも多数。
どこまで本気なんだか。。。
x-ace : 電子メイルで IDN どうするよ? と IDN ML でちょっと話題になったものですが、具体的に形式がどうとかいう話にまでは至ってないみたいです。x-base65 : http://groups.google.com/groups?selm=3AB60548.B2C16EF0%40remotepoint.com base65 じゃなくて x-base65 ってのは奇妙な間違い方ではあるんだよなあ。[25] >>10 xxe ってのは実際用例はあるんだけど正体がよくわかんない。
[29] >>25 uuencode
変種で、字母に +-0〜9A〜Za〜z を使うものらしい。
x-custom3to4 : 不明。 uuencode のような感じだけど、違うものなのかな? 誰か検証してください。[27]
x-pgp-version : PGP/MIME を CTE として実現しようとした過去の案。実際に仕様としてまとめた草案や実装や用例があるのかは不明。
[28] x-yenc : yEnc。
関連 ML で激論になった曰くつき。おかげで yEnc 界の一部は MIME 嫌いになったとかならないとか。
なんだかんだでも結局用例はあります。
本体は x-uuencode のように、 yEnc
の符号化をまるごと (メタ情報部も含めて) つっこみます。
なかには、こんな素晴らしいのもありました。
Content-Type: application/binary Content-Transfer-Encoding: x-yenc; line=128; size=2345436; name=021005-301.dwg.zip
謎の媒体型 application/binary
もそうですが、 CTE で引数を使っているのが素敵。
(CTE でも引数を使うのは、 MIME のもともとの思想には反するけど、妥当な態度だと思いますよ。現状では規格違反ですが。(一般論としては正しいと思うんですが、 yEnc の場合本体のめた情報として line とか size とか name とかを持ってるんですよね。それを MIME のレベルで重複させる意味があるのかは謎。それとも純粋な yEnc (謎) を CTE として使って、メタ情報は MIME レベルで指定しようという意味なのかなあ。))
[25] x-usercode : xxencode のように見えるけど謎。
[31] Content-Transfer-Encoding: packet というのが提案されたこともありました。 (今の Transfer-Encoding: chunked)
[33]
plain: spam で流行中らしいです
(名無しさん 2004-06-13 13:19:31 +00:00)
[36]
無料の電子メイル・サービスやメイリング・リストなどでは、
メッセージの本文の最初や最後に広告やメイリング・リスト情報などをつけたすことがあります。
往々にして Content-Type: や
Content-Transfer-Encoding:
に対応していないので、非 text/plain
メッセージや Base64 化されたメッセージは壊れてしまうことがあります。
(名無しさん)
[37]
元々合成型 (message/* や
multipart/*)
での (非同一) 内容転送符号化 (Base64 など) の使用が禁止されていましたが、
message/* については RFC 5335
で緩和され、亜型毎に個別に禁止するか規定できるようになりました
(従来の亜型については禁止のままです)。実際に
message/global では内容転送符号化の使用が認められています。
[227] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.5
[228] RFC 4130 - MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) ( ( 版)) http://tools.ietf.org/html/rfc4130#appendix-A.3
[51] RFC 6838 - Media Type Specifications and Registration Procedures ( 版) http://tools.ietf.org/html/rfc6838#section-4.8
ところがMicrosoft Internet Mailではこのとき、「Content-Transfer-Encoding: 8bit」という、明らかに誤ったヘッダーを付ける。ISO-2022-JPは7ビットなので明らかに間違いで、このためメールが相手に送信される途中で問題が発生してしまう。
[54] 最近は電子メールでも Content-Transfer-Encoding: binary
で届くのが普通ですね。
[55] 電子メールで CTE が明示されていないのに実質 8bit
なこともあります。
A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], containing the certificates described in the following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of "base64" [RFC2045].
Amazon SES allows you to specify 8-bit Content-Transfer-Encoding for MIME message parts. However, if Amazon SES has to modify the contents of your message (for example, if you use open and click tracking), 8-bit content isn't preserved.
[60] w3m おぼえがき(2001年12月) (, ) http://www2u.biglobe.ne.jp/~hsaka/w3mnote.cgi?month=200112
[61] rfc2060, https://datatracker.ietf.org/doc/html/rfc2060#page-66