Content-Transfer-Encoding:

Content-Transfer-Encoding: ヘッダー (MIME)

[1] MIME 実体の頭領域で、実体に使われている 内容転送符号化 — CTE を示します。 CTE が使われていない時は、 使っているオクテット種を示します。

仕様書

構文

BNF の章を書きなおす

一覧表を書きなおす、メモで報告されている非標準の値も追加
転送符号化の WikiPage との関係はどうする??

既定値

[53]プロトコルの既定値については、 MIME を参照。

MIME の規定は? 電子メイルでは 7bit

[35] BEEP

BEEP で伝送される MIME実体Content-Transfer-Encoding: 頭欄が明記されていない場合の既定値binary です。 RFC 3080 2.2

未対応の値への対処

MIME によれば、 application/octet-stream とするべき

応用

PO ファイル

[225] GNU gettext により拡張された POファイル頭部には MIME-Version 欄などと合わせて Content-Transfer-Encoding 欄を指定する必要がありますが、 実際にはまったく意味を持ちません。値は常に 8bit で構いません。

関連

[3] MSA との関係

MSA は、必要で、かつ使用している Content-Type に無害なら、 転送符号化を適用して構いませんRFC 4409 8.4

Content-Type, Content-Encoding, Transfer-Encoding との関係
Content-Type が CTE を限定している場合について

RFC 2045 BNF

  1. encoding := "Content-Transfer-Encoding" ":" mechanism
  2. mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token

値の大文字・小文字は区別しません。

MIME での既定値は "7bit" です。 HTTP には (RFC になった最終仕様には) CTE は存在しませんが、 相当する既定値的なものは "binary" です。

See also RFC-2045のCTE:の定義

個別の CTE に関しては、個別の WikiPage に移動する

転送路の性能を表す転送符号化の値

"7bit", "8bit" 転送符号化

符号化無し。一行998オクテット以下 (SMTPの制限)で、 行区切は CRLF。7ビットでは値 128 以上は出現しない。

値 0 (NULL) は出現しない。 13 (CR) と 10 (LF) は CRLF 以外としては出現しない。

"binary" 転送符号化

[57] binaryは、 符号化無し、制限無しのオクテット列。 SMTP 電子メイル では使用不可。

プロトコルの転送符号化

[58] プロトコル転送符号化 (の既定値と限界) については、 MIME の項のプロトコルの章を参照。

ietf-token 転送符号化

ietf-token の登録簿は <http://www.iana.org/assignments/transfer-encodings>。 追加名は登録されていない。 MIME RFC は、相互通信性の観点から 新しい CTE は定義するべきじゃないって言ってる。

x-token 転送符号化

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 / CRLFMIME
8bit%x01-09 / %x0B-0C / %x0E-FF / CRLFMIME
base6464進数 Base64MIME
binary%x00-FFMIME
quoted-string=
x-gzip64GNU Zip + Base64
x-uuuuencode
x-uueuuencode
x-uuencodeuuencode
x-uuencodeduuencode

[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 の失敗の一つと言えるでしょう。

歴史

HTTP における CTE

[39] HTTP には転送符号化 (Transfer-Encoding:) と内容符号化 (Content-Encoding:) が存在します。 これらは CTE とは異なるものとされています。転送符号化CTE は用途が似ていますが、利用できる値と符号化は全く異なっていて、 直接変換できる関係にはありません。

[41] MIME から HTTP に変換するなら CTE復号しないといけませんし、 HTTP から MIME に変換するなら必要に応じて CTE を適用することになります >>32

[46] HTTP92MIMEHTTP に採用することを意図していたので、 Content-Transfer-Encoding:HTTPヘッダーの一つに挙げ、 具体的には MIMERFC を参照していました >>47。 (HTTP 向けの規定も必要 >>47 としていました。)

[50] RFC 4229HTTP92 を出典に状態「provisional」で Content-Transfer-Encoding:HTTPヘッダーとして IANA登録簿に登録しています >>49

[48] しかしその後の RFC となった HTTP 仕様書では、 HTTPMIME から派生したメッセージ形式とされており、 Content-Transfer-Encoding:HTTPヘッダーとはされていません。

[38] RFC 1945 (HTTP/1.0) C.4; RFC 2068 (HTTP/1.1) 19.4.4; RFC 2616 (HTTP/1.1) 19.4.5 No Content-Transfer-Encoding

HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 1521 MIME RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP must MUST remove any {Errata で削除} non-identity CTE {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 should SHOULD 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] ODataHTTP 応答メッセージContent-Transfer-Encoding: binary を指定することを求めています >>42

[45] ODataHTTP 応答メッセージに含まれる multipart/mixed本体部分ヘッダー (こちらは定義上 MIMEヘッダー) でも Content-Transfer-Encoding: binary を指定することを求めています >>44

メモ

[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 以外の実例はまだ見つかっていません。

[21] gzip というのもしばしば見かけますが、ほとんどが HTTP での用例なので Content-Encoding と勘違いしているのでしょう。ほんとにそんなので機能しているのですかね? (WWWブラウザで見て確認くらいしないのかなー。)

[28] >>21 x-gzip というのも多数。 どこまで本気なんだか。。。

[25] >>10 xxe ってのは実際用例はあるんだけど正体がよくわかんない。

[29] >>25 uuencode 変種で、字母に +-0〜9A〜Za〜z を使うものらしい。

[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>

[52] Content-Transfer-Encoding問題 ‐ 通信用語の基礎知識 ( 版) <http://www.wdic.org/w/WDIC/Content-Transfer-Encoding%E5%95%8F%E9%A1%8C>

ところがMicrosoft Internet Mailではこのとき、「Content-Transfer-Encoding: 8bit」という、明らかに誤ったヘッダーを付ける。ISO-2022-JPは7ビットなので明らかに間違いで、このためメールが相手に送信される途中で問題が発生してしまう。

[54] 最近は電子メールでも Content-Transfer-Encoding: binary で届くのが普通ですね。

[55] 電子メールCTE が明示されていないのに実質 8bit なこともあります。

[56] RFC 7030 - Enrollment over Secure Transport () <https://tools.ietf.org/html/rfc7030#section-4.1.3>

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].