[2] [DFN[[RUBYB[[[本体部分]]]@en[body part]]]]は、 [CODE(MIME)@en[[[multipart/*]]]] [[実体]]に含まれるそれぞれの[[実体]]のことをいいます。 ;; [3] ある [CODE(MIME)@en[[[multipart/*]]]] [[実体]]の[[本体部分]]というときは[[子供]]に当たる[[実体]]のことを指し、[[孫]]以降の世代の[[実体]]のことは指しません。 * 仕様書 [REFS[ - [34] '''[CITE@en[RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types]] ([TIME[2015-03-22 13:14:46 +09:00]] 版) ''' ]REFS] * 定義 [FIG(quote)[ [FIGCAPTION[ [1] [[RFC 2045]] 2.5 ]FIGCAPTION] > The term "body part" refers to an entity inside of a multipart entity. > 用語「本文部分 body part」は多部分実体の中の実体を指します。 ]FIG] * 構文 [5] [[本体部分]]は、[[MIME実体]]です。 [[ヘッダー部]]、[[空行]]、[[本体]]部で構成されます。 [SRC[>>34]] [FIG(railroad)[ = * == [[ヘッダー欄]] = ? == [[空行]] == [[本体]] ]FIG] ;; [37] [[本体部分]]は [[RFC 822]] [[メッセージ]]と構文が似ていますが、 意味は異なります [SRC[>>34]]。 [38] [[本体部分]]では、必須の[[ヘッダー欄]]はありません [SRC[>>34]]。 ;; [39] 従って[[本体部分]]が[[空行]]から始まることがあります。 [25] [[本体]]が無い場合、[[空行]]も省略できます [SRC[>>34]]。 [6] [[本体部分]]は、その外側の[[境界区切子]]と一致する、または[[境界区切子]]から始まる[[行]]を含んでは[['''なりません''']] [SRC[>>34]]。 [21] [[境界区切子]]の前には [CODE[[[CRLF]]]] があります。これは区切りの一部であり、 前の[[本体部分]]や[[前書き]]の一部ではありません [SRC[>>34]]。 ;; [4] [[本体部分]]が含まれる外側の [CODE(MIME)@en[[[multipart/*]]]] の構文については、 [CODE(MIME)@en[[[multipart/*]]]] や[[境界区切子]]の項を参照してください。 * HTTP における本体部分 [7] [[HTTTP]] でも [CODE(MIME)@en[[[multipart/*]]]] は [[MIME]] の定義に従い解釈することになっています。 ;; [8] 外側の[[HTTPメッセージ]]は、[[MIME実体]]ではありません。 [[MIME]] ではなく [[HTTP]] の規定に従い解釈されます。 [9] [CODE(MIME)@en[[[multipart/byteranges]]]] の[[本体部分]]では、 [CODE(HTTP)@en[[[Content-Type:]]]] や [CODE(HTTP)@en[[[Content-Range:]]]] が使われます。後者は [[MIME]] に存在しない [[HTTP]] 独自の[[ヘッダー]]です。前者は [[MIME]] にも存在しますが、 [[HTTP]] とは微妙に構文が違い、若干の解釈の違いが存在し得ます。 ;; [12] [[HTTP]] の[[鯖]]や[[クライアント]]があえてここだけ [[MIME]] に従って実装しているとは思い難いので、実際には [[HTTP]] の定義に従っていると考えるべきでしょう。 [11] [CODE(MIME)@en[[[multipart/byteranges]]]] の[[本体部分]]は [CODE(HTTP)@en[[[Content-Range:]]]] で指定された範囲のデータのみ含むものなので、 [[MIME実体]]とは性質が異なります。 [CODE(HTTP)@en[[[Content-Type:]]]] の指定があったとしても、[[本体部分]]単体ではその[[MIME型]]に従って解釈できる可能性は低いです。 [[本体部分]]には記述されていない [CODE(HTTP)@en[[[Content-Encoding:]]]] が適用されている可能性もあります。 [10] このような [[MIME]] と [[HTTP]] の微妙な違いについて [[HTTP]] の仕様書は何も言及していません。 * 本体部分内のヘッダー [212] [[本体部分]]で意味が規定されている[[ヘッダー欄]]は、 [CODE(MIME)@en[[[Content-]]]] から名前が始まるものだけです [SRC[>>34]]。 [15] それ以外の[[欄]]は無視して構いません [SRC[>>34]]。 あっても構いませんが、それに依存してはなりません [SRC[>>34]]。 [[関門]]でも可能なら残しておくべきではありますが、必要なら捨てても構いません [SRC[>>34]]。 [16] [CODE[[[X-]]]] で始まる名前の[[欄]]を実験や私的な目的で使っても構いませんが、 [[関門]]で失われるかもしれません [SRC[>>34]]。 [213] [[HTTP]] の旧仕様である [[RFC 1945]] と [[RFC 2068]] では、任意の [[HTTPヘッダー]]を指定できるとされていました。 [CODE(HTTP)[[[Expires]]]] とか [CODE(HTTP)[[[Link]]]] とか、 メッセージではなく実体の頭欄・・・つまり[[実体頭欄]]ですね、 そういうのを入れることを意図していたんだと思います。 MIME 的思想では、 MIME の制定をもってメッセージ (822) と実体は意味的に分割されて、 以後新たに実体の属性を頭欄として実装するときには [CODE(MIME)[Content-[VAR[*]]]] 名前空間に置こうと考えたのでしょう。ところが、その設計思想は HTTP の実装には反映されなかった。[WEAK[HTTP の設計した人達はその命名規則を理解していたかもしれませんが —きっと理解していたでしょうが、設計よりも実装がどんどん先走ったのは周知の通り。]] 結局、 HTTP では (名前からは機械的に決定できない) 実体頭欄だのなんたら頭欄だのという分類ができることになるわけです。 [214] ところが、 RFC 2616 で以前の規定はなくなってしまっています。 本体部分の実体の頭欄は MIME 的に解釈されると書いてあります。 やっぱり MIME と非互換ではいかんということでしょうか。 [215] ''Met-cast HTTP'' の実装例では [CODE(HTTP)[[[Content-Length]]]] や [CODE(HTTP)[[[Last-Modified]]]] が本体部分の頭欄に使われています。 [19] [[HTTP]] では [CODE[Content-]] で始まらない[[頭欄]]が、[[複数部分]]実体内でも意味を持ちえます。 [218] RFC 2068 までの規定では、本体部分の頭欄には HTTP 頭欄をいれることができましたから、素直に解釈すればそこは HTTP により解釈します。ということは、 RFC 1945 では [[US-ASCII]] + 任意の8ビット符号, RFC 2068 では [[ISO-8859-1]] が使えるということになります。 MIME 的には [[US-ASCII]] しか使えず、それ以外は [CODE(ABNF)[[[encoded-word]]]] ということになるのですが。。。 [219] RFC 2616 の規定では、 MIME 的な意味でと言っているので、 MIME の規定に従えと解釈すれば、 US-ASCII を使わないといけません。 [WEAK[(Semantic は MIME と言ってるけど syntax も MIME とは言ってないから ISO-8859-1 を使ってもいいという主張もできるのですが。。。)]] [10] 複数部分内の実体の頭は [[MIME]] によると [[US-ASCII]] でしかありえませんけど、実際には生 [[JIS]] とか生[[シフトJIS]]とかがないわけではないですね。(特に [[Content-Disposition:]] 欄のファイル名。) [13] [[MIME]] の規定をよく読むと、 [CODE(MIME)@en[[[Content-]]]] から始まるもの以外は [[MIME]] 的な意味を持たないというだけで、 [[MIME]] 以外の意味を持たせることは否定していないようです。 [14] [[HTTP]] の [CODE(MIME)@en[[[multipart/encrypted]]]] で使われる [CODE(MIME)@en[[[application/HTTP-Kerberos-session-encrypted]]]] な[[本体部分]]では [CODE(MIME)@en[[[OriginalContent:]]]] [[ヘッダー]]が使われるようです。 [22] [[本体部分]]では、一般に必須の[[ヘッダー]]はありません [SRC[>>34]]。 ;; [23] [[MIME型]]によっては必須のものもあるかもしれません。 [24] [CODE(MIME)@en[[[Content-Type:]]]] [[ヘッダー]]が省略される場合、 [CODE(MIME)@en[[[multipart/digest]]]] では [CODE(MIME)@en[[[message/rfc822]]]]、 それ以外では [CODE(MIME)@en[[[text/plain]]; [[charset]]=[[US-ASCII]]]] が既定値です [SRC[>>34]]。 [26] [CITE[Wayback Machine]], [TIME[2023-07-31T13:42:37.000Z]] [27] >>26 [[DDIポケット]]の[[オープンネットコンテンツ]]。 キャリア運用の中継サーバーと端末の間の[[インターネットメール]]風メッセージの[[本体部分]]で [CODE[X-PmailDX-[VAR[*]]:]] [[ヘッダー]]を使っていました。 * 本体部分の内容符号化 [17] [[MIME]] では、 [CODE(MIME)@en[[[Content-Transfer-Encoding:]]]] [[ヘッダー]]により[[内容転送符号化]]を指定し、適用することができます。 ;; [18] [CODE(MIME)@en[[[multipart/*]]]] の[[実体]]全体に [[CTE]] を適用することは禁止されていますが、個別の[[本体部分]]の中の[[本体]]については適用できます。 [216] MIME の [CODE(MIME)[[[Content-Transfer-Encoding]]]], HTTP の [CODE(MIME)[[[Content-Encoding]]]] はそれぞれ固有のものです。 ではこれらを本体部分の実体の頭欄で使うことができるのか。 HTTP RFC ではどこにもその規定はありません。 [217] RFC 2616 で、本体部分実体頭欄は MIME 的に解釈されるという規定になりました。 これに従うなら、 [CODE(MIME)[Content-Transfer-Encoding]] 欄があったなら MIME 的に解釈するべきでしょう。 一方 [CODE(MIME)[Content-Encoding]] 欄は MIME で規定されていないので、 解釈なしになってしまいます。 RFC 2068 までの規定に従えば任意の HTTP 頭欄が使えるので、 HTTP 的に適当に解釈してもらえるはずなのですが・・・。 [20] [[HTTP]] の多くの実装は、 [[CTE]] に対応していません。 特に [CODE(MIME)@en[[[multipart/byteranges]]]] や [CODE(MIME)@en[[[multipart/form-data]]]] では、 [[CTE]] は利用できないと考えるべきです。