-
Notifications
You must be signed in to change notification settings - Fork 4
/
974.txt
1145 lines (935 loc) · 57.6 KB
/
974.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[1] [CODE[multipart/*]] [[媒体型]]は、 [[MIME]] が汎用的に定義した、
単一メッセージ中に複数の部分 (実体) を含める方法です。
すべての亜型が同じ構造をしていますから、各型の自由度は低まりますが、対応していない[[利用者エージェント]]であっても、とりあえず
multipart/mixed 媒体型として最低限の解釈は可能になります。
* 仕様書
[REFS[
- [25] [CITE@en[RFC 2183 - Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field]] ([TIME[2014-09-07 04:20:15 +09:00]] 版) <http://tools.ietf.org/html/rfc2183#section-2.9>
- [211] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-3.1.1.4>
]REFS]
* [CODE(MIME)@en[multipart/*]] MIME 型の一覧
[15]
,[[媒体型]],説明,状態,出典
,[[multipart/alternative]] ,選択肢群 ,[MIME]
,[[multipart/appledouble]] ,Macintosh 書類 ,[MacMIME]
,[[multipart/byteranges]] ,部分塊 ,[[HTTP]]
,[[multipart/x-byteranges]] ,部分塊 ,HTTP 原案
,[[multipart/digest]] ,要約版メッセージ群 ,[MIME]
,[[multipart/encrypted]] ,暗号化メッセージ ,[RFC1847]
,[CODE(MIME)@en[[[multipart/example]]]],,"[[IETF]] [[RFC]], [[IANA]] 登録済","[[RFC]], [IANAREG]"
,[[multipart/form-data]] ,FORM 送信 ,[RFC2388]
,[CODE(MIME)@en[[[multipart/gedi-record]]]],[[GEDI]],"[[IANA]] ''未''登録, [[ISO]] [[標準]]"
,[[multipart/header-set]] ,ファイル系統物体 ,[IANAREG]
,[CODE(MIME)[[[multipart/x-mimepgp]]]] ,
,multipart/mixed ,混合一般 ,[MIME]
,[[multipart/x-mixed-replace]] ,パラパラ漫画 ,[Netscape]
,[[multipart/parallel]] ,同時再生 ,[MIME]
,[[multipart/related]] ,関連束 ,[RFC2387]
,[[multipart/report]] ,配送報告 ,[RFC1892]
,[CODE(MIME)[[[multipart/dvb.service]]]] ,Multipart DVB Services ,非標準 ,[MHP 1.1]
,[CODE(MIME)[[[multipart/x-sgml]]]] ,[[SGML]] 実体群
,[[multipart/signed]] ,署名メッセージ ,[RFC1847]
,[[multipart/voice-message]] ,音声メッセージ ,[RFC2421] [RFC2423]
,[CODE(MIME)@en[[[multipart/x-www-form-data]]]],[[フォーム・データ集合]],"時代遅れ → [CODE(MIME)@en[[[multipart/form-data]]]]",[[Emacs/W3]]
- [[IANA]] 登録簿 <http://www.iana.org/assignments/media-types/multipart/>
* 構文
** 改行
[8] HTTP は [CODE(MIME)[[[text/*]]]] については MIME とは違って
[[CRLF]] への正規化を要求していません。しかし、 [CODE(MIME)[multipart/*]]
の改行は MIME と同じで CRLF でなければなりません [SRC[>>211]]。
この点は RFC 1945 からしっかり明記されています。
** 前書き
[6] 最初の[[境界文字列]]の前には[[境界文字列]]以外の任意の [[ASCII文字]]の列を記述できます。
これを[[前書き]]といいます。その場合[[前書き]]の後に [[CRLF]]
が必要です。
;; [10] 前書きが空の場合、 [[CRLF]] なしで最初が[[境界文字列]]の [CODE[--]]
となります。
[18] [[前書き]]は、 [[MIME]] 未対応の[[利用者エージェント]]で表示される (人間向けの)
メッセージとして使うことを意図したものです。[[前書き]]が含まれる場合、
多くの場合は [[MUA]] によって自動生成される「[[MIME]] 対応 [[MUA]] で開いてください」
のような文言です。
[19] [[HTTP]] では[[前書き]]は使わないのが普通です。
** 境界文字列
[20] [CODE(MIME)@en[[[boundary]]]] [[引数]]の項を参照。
** 後書き
[220] MIME の規定では、最後の本体部分の終わりの境界の後に任意の (US-ASCII) 文字列を入れることができます。
その部分は MIME UA には無視されます。
この部分のことを[DFN[[[後書き]]]]といいます。
[224] [[HTTP]] では、 [[RFC 2616]] までは[[後書き]]を禁止していました。
しかしこの規定は [[RFC 7230]]/[[RFC 7231]] では無くなっています。
[225] [[RFC 2616]] までは、本来 [CODE(HTTP)@en[[[Content-Length:]]]]
[[ヘッダー]]が必要な場合でも [CODE(MIME)[[[multipart/byteranges]]]]
を使っていれば省略してもいいことになっていました。
これは本体部分の最後の境界で終わりを示せるからです。
ところが後書きがあるとこの仮定が崩れます。
だから禁止しているのです。
しかしこの規定も [[RFC 7230]]/[[RFC 7231]] では無くなっています [SRC[>>211]]。
;; [[メッセージ本体]]の項も参照してください。
* 本体部分
[5] [CODE(MIME)@en[[[multipart/*]]]] に含まれる[[実体]]のことを、
[[本体部分]]といいます。
;; [4] 詳しくは[[本体部分]]の項を参照。
* [CODE(MIME)@en[Content-Disposition:]] ヘッダーとの関係
[26] [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] [[実体]] (個別の[[本体部分]]ではなく、
全体) に対して [CODE(MIME)@en[[[Content-Disposition:]]]] [[ヘッダー]]が指定された場合、
それは全体に適用されます [SRC[>>25]]。
[27] 当該 [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] [[実体]]が[[表示]]されていない間は、
各[[本体部分]]に対する [CODE(MIME)@en[[[Content-Disposition:]]]] の指定も適用されません
[SRC[>>25]]。
[EG[
[28] 例えば [CODE(MIME)@en[[[multipart/*]]]] [[実体]]に
[CODE(MIME)@en[[[Content-Disposition: attachment]]]] が指定されている場合、
その [CODE(MIME)@en[[[multipart/*]]]] [[実体]]全体が[[利用者]]の指示があるまで[[表示]]されません。
[29] [[利用者]]の指示で表示する際、 [CODE(MIME)@en[[[Content-Disposition: inline]]]]
の[[実体本体]]と [CODE(MIME)@en[[[Content-Disposition: attachment]]]]
の[[実体本体]]がその中に含まれていれば、前者は自動的に表示し、
後者は更に[[利用者]]の指示があるまで表示しません。
]EG]
* HTTP における [CODE(MIME)@en[multipart/*]]
[22] HTTP での [CODE(MIME)[[[multipart/*]]]] 媒体型の使用について。
[23] [[MIME]] で複数の[[実体]]を一つの[[メッセージ]]に詰め込むために用意されている
[CODE(MIME)[multipart/[VAR[*]]]] 型は、 [[HTTP]] でも使うことがあります。
しかしながら、実際には使えるとも使えないともいえない中途半端な状態で実装されています。
[3] HTTP RFC は [CODE[multipart/*]] 媒体型が HTTP でも使えると言っているものの、対応している実装はそうないと思われます。せいぜい、
[[multipart/x-mixed-replace]] と、 [[HTML]] [[form]]
送信用の [[multipart/form-data]], [[multipart/mixed]] 位ではないでしょうか。
- [7] HTTP は [[Content-Transfer-Encoding:]] 欄がないとか [[Content-Encoding:]] 欄があるとか [[MIME]] と異なる点が幾つかあるわけですが、これが複数部分についてどう適用されるのか、 [[RFC2616]] を読むと MIME と同じ、すなわち CTE: binary の記述が必須とか、 CE: は使えないとか、そう読めますが、後者はともかく前者は実情に合いませんよね。
- [8] >>3 [[multipart/byteranges]] を忘れていた。
- [9] >>19 [[RFC2616]] では該当する記述が削除されている。 [[Base:]] 欄が実質廃止されたのとかも関係するのかな。つまり、 MIME との協調のためにそういうのは止めていこうという方向?
[16] HTTP 応用では、幾つかの亜型は対応している実装がかなりありますが、
全体としてはほとんど無視している状態です。 MIME でも HTTP
でも、未対応の [CODE(MIME)[multipart/[VAR[*]]]] に出会ったら
[CODE(MIME)[[[multipart/mixed]]]] と同じに振舞うことになっていますが、
ほとんどの応用が [CODE(MIME)[multipart/mixed]] に対応していないのだからどうしようもありません。。。
[207]
: [CODE(MIME)[[[multipart/form-data]]]] : [CODE(HTMLe)[[[form]]]] 要素などの[[フォーム]]からデータを送信する時に [CODE(HTTP)[[[POST]]]] 要求でよく使われる型です。
[[ファイルうp]]には必須とあって一気に普及しましたが、行き当たりばったりな実装ばかりで無難にやり過ごすとしたら最低限のこともできないかもしれません。[WEAK[まあ Web 関連規格は大体がそういう状態ですな。]]
: [CODE(MIME)[[[multipart/byteranges]]]] : [CODE(HTTP)[[[206]]]] 応答で内容全体ではなく内容の一部を複数個送るときに使います。
大方のサーバーと大方の [[WWWブラウザ]]や prefetcher が対応しています。
: [CODE(MIME)[[[multipart/x-byteranges]]]] : [CODE(MIME)[byterange]] の規格制定過程の古い形式で、今でも対応している WWW ブラウザもあります。
とはいえ歴史的なものでおそらく誰も使って無いでしょう。
: [CODE(MIME)[[[multipart/x-mixed-replace]]]] : [[プッシュ]]が流行り始めた時代に
[[NN]] が実装していました。成長し始めの[[コンテンツ業界]] (謎)
でも流行ったみたいで、それ系の掲示板 (謎) で最近までたまに話題に上がっていましたが、
これに対応していない [[WinIE]] の台頭とプッシュが廃れたのでもう死滅状態でしょうか。
[WEAK[ちなみに [[Gecko]] Mozilla は対応していません。]]
逐次レンダリングしないといけないという代物。
: [CODE(MIME)@en[[[multipart/related]]]] :
[[SOAP]] [[メッセージ]]を [[HTTP]] で送信する場合で、 [[SOAP]] [[メッセージ]]内に[[バイナリ・データ]]が含まれる時には、
[CODE(MIME)@en[[[multipart/related]]]] を使えることになっています。仕様上は。
実際使われているのかは謎です。そもそも [[SOAP]] 自体(ry
[208] これ以外の亜型に対応した実装はほとんどありません。
複数個の本体があるとどうレンダリングしたらいいか困っちゃいますからねぇ。
ブラウザとしては。[[フレーム]]と同じようにしたらどうよ? という気もしないでもないですが。
[209] 電子メイルを扱える WWW ブラウザだと、 [CODE(MIME)[multipart/[VAR[*]]]]
を直接扱えなくても HTTP 的には [CODE(MIME)[[[message/rfc822]]]]
で、その中に多部分がある感じにすれば、 (電子メイルを扱う時と同程度には)
表示できたりします。でもまあこんなの HTTP での多部分に対応しているとは言わんな。
[210] HTTP が MIME を採用していれば何も問題はなかったのですが、あいにく
HTTP は「MIME 的なもの」を含んでいるので、多部分を完全に MIME
的に取扱っても良いのか、はっきり書かれていないと困ってしまいます。
何も言っていないのは特に変更しないからだと判断して MIME
的に実装してしまうのももっともなのですが、
そうすると整合性の点で問題になっちゃうこともあるような気もします。
歴代仕様書を比較すると、最新の RFC 2616 は以前の RFC
より MIME との互換性に気を遣っているような感じです。
[24] [[OData]] は [[HTTP]] で [CODE(MIME)@en[[[multipart/mixed]]]]
を使っています。
* バイナリー表現の試み
[2] MIME は電子メイルでの利用を念頭に設計しましたから、バイナリな転送プロトコル,
例えば HTTP では、境界の扱いなど無駄な部分があります。
そのため、 HTTP で分割転送のために
[[multipart/byteranges]] [[媒体型]]を採用した時には、よりバイナリ指向な
multipart に代わる仕組みを導入しようという意見も強くありましたが、結局
MIME と互換性のある multipart 形式になりました。
[13]
[[HTTP]] の [CODE(MIME)[multipart/byteranges]]
のときにも、 [CODE(MIME)[multipart/[VAR[*]]]] は overhead が大きいから binary
にしようとか揉めましたが結局 MIME 互換の [CODE(MIME)[multipart/byteranges]] に落ち着きました。
[11] [[WSP]] は多部分型のバイナリ表現を規定しています。
(<http://www.openmobilealliance.org/wapdocs/wap-230-wsp-20010705-a.pdf> 8.5 参照。)
それに伴って定義されている媒体型:
,[CODE(MIME)[[[application/vnd.wap.multipart.alternative]]]]
,[CODE(MIME)[[[application/vnd.wap.multipart.byteranges]]]]
,[CODE(MIME)[[[application/vnd.wap.multipart.form-data]]]]
,[CODE(MIME)[[[application/vnd.wap.multipart.mixed]]]]
* 歴史
[FIG[
[FIGCAPTION[
[21] RFC 2046 5.1. Multipart Media Type
]FIGCAPTION]
> In the case of multipart entities, in which one or more different
sets of data are combined in a single body, a "multipart" media type
field must appear in the entity's header. The body must then contain
one or more body parts, each preceded by a boundary delimiter line,
and the last one followed by a closing boundary delimiter line.
After its boundary delimiter line, each body part then consists of a
header area, a blank line, and a body area. Thus a body part is
similar to an RFC 822 message in syntax, but different in meaning.
一つの[[本体]]の中に1つ以上の異なるデータ集合が組み合わさっている
[[複数部分]][[実体]]の場合、
"multipart" 媒体型欄が実体の頭の中に出現しなければなりません。本体は一つ以上の[[本体]]部分から構成されていなければなりません。各本体部分には境界区切行が先にあって、最後のものは閉じ境界区切行が続きます。境界区切行の後では、各本体部分が頭欄,
空行, 本体領域から構成されます。このように本体部分は
RFC 822 メッセージと構文的には似ていますが、意味が異なります。
> A body part is an entity and hence is NOT to be interpreted as
actually being an RFC 822 message. To begin with, NO header fields
are actually required in body parts. A body part that starts with a
blank line, therefore, is allowed and is a body part for which all
default values are to be assumed. In such a case, the absence of a
Content-Type header usually indicates that the corresponding body has
a content-type of "text/plain; charset=US-ASCII".
本体部分は一つの実体であり、従って実際には RFC 822
[[メッセージ]]であるように解釈しては'''いけません'''。まず、本体部分の中で本当に必須の頭欄は'''ありません'''。ですから、空白行で始まる本体部分は認められていて、この本体部分は全て既定値であると仮定されます。このような場合に、
Content-Type 頭が無いなら通常は、対応する本体は
"text/plain; charset=US-ASCII" の content-type
を持つことを示します。
[PRE[
The only header fields that have defined meaning for body parts are
those the names of which begin with "Content-". All other header
fields may be ignored in body parts. Although they should generally
be retained if at all possible, they may be discarded by gateways if
necessary. Such other fields are permitted to appear in body parts
but must not be depended on. "X-" fields may be created for
experimental or private purposes, with the recognition that the
information they contain may be lost at some gateways.
]PRE]
本文部分に対して意味が定義されている頭領域は "Content-" で始まる名前を
持つもののみです。他の全ての頭領域は本文部分では無視されます。
これは全然可能であるならば通常はそのままにしておくべきですが、
必要ならば関門により捨てられるかもしれません。このような他の領域
が本文部分に出現することは認められますが、それに依存してはいけません。
"X-" 領域を実験あるいは私的な目的で作成しても構いませんが、
そこに含まれる情報は関門で失われ得ることを認識している必要があります。
[PRE[
NOTE: The distinction between an RFC 822 message and a body part is
subtle, but important. A gateway between Internet and X.400 mail,
for example, must be able to tell the difference between a body part
that contains an image and a body part that contains an encapsulated
message, the body of which is a JPEG image. In order to represent
the latter, the body part must have "Content-Type: message/rfc822",
and its body (after the blank line) must be the encapsulated message,
with its own "Content-Type: image/jpeg" header field. The use of
similar syntax facilitates the conversion of messages to body parts,
and vice versa, but the distinction between the two must be
understood by implementors. (For the special case in which parts
actually are messages, a "digest" subtype is also defined.)
]PRE]
RFC 822 メッセージと本文部分の区別はわずかですが、重要です。
例えば Internet と X.400 のメイル関門は、画像を含む本文部分と
本文が JPEG 画像のカプセル化メッセージが含まれている本文部分の違いを
知り得る必要があります。後者を表現するためには、本文部分に
"Content-Type: message/rfc822" をつけ、その本文 (空行の後)
に "" 頭領域を持ったカプセル化メッセージを入れなければなりません。
同様の構文を使うことでメッセージの本文部分への変換が促進されますし、
逆に実装者は2つの区別を理解しなければなりません。
(部分が実際メッセージである特別な場合のために、 "digest"
亜型も定義します。)
[PRE[
As stated previously, each body part is preceded by a boundary
delimiter line that contains the boundary delimiter. The boundary
delimiter MUST NOT appear inside any of the encapsulated parts, on a
line by itself or as the prefix of any line. This implies that it is
crucial that the composing agent be able to choose and specify a
unique boundary parameter value that does not contain the boundary
parameter value of an enclosing multipart as a prefix.
]PRE]
前述のように、本文部分の前には境界区切りを含む境界区切行が来ます。
境界区切りは、カプセル化部分の内部で行そのものあるいは行の頭に
現れては'''なりません'''。ですから、構成代理者は、
囲んでいる多部分で boundary パラメーター値に接頭辞として含まれていない、
独特な boundary パラメーター値を選択・指定できます。
[PRE[
All present and future subtypes of the "multipart" type must use an
identical syntax. Subtypes may differ in their semantics, and may
impose additional restrictions on syntax, but must conform to the
required syntax for the "multipart" type. This requirement ensures
that all conformant user agents will at least be able to recognize
and separate the parts of any multipart entity, even those of an
unrecognized subtype.
]PRE]
現在及び将来の全ての "multipart" の亜型は同じ構文を使用しなければなりません。
亜型はその意味において異なるでしょうし、構文に追加の制限を加えても
構いませんが、 "multipart" 型の要求構文に適合しなければなりません。
この要求事項があるので、全ての適合利用者代理者は、その亜型が認識出来ない
ものであっても、多部分実体の部分を少なくても認識・分離することが
出来るでしょう。
[PRE[
As stated in the definition of the Content-Transfer-Encoding field
[RFC 2045], no encoding other than "7bit", "8bit", or "binary" is
permitted for entities of type "multipart". The "multipart" boundary
delimiters and header fields are always represented as 7bit US-ASCII
in any case (though the header fields may encode non-US-ASCII header
text as per RFC 2047) and data within the body parts can be encoded
on a part-by-part basis, with Content-Transfer-Encoding fields for
each appropriate body part.
]PRE]
CTE 領域の定義で述べたように、 ... 以外の符号化は "multipart" 型の
実体には認められていません。 "multipart" 境界区切りと
頭領域は常にいかなる場合においても7ビット US-ASCII で (非 US-ASCII
頭文を RFC 2047 により符号化しても構いませんが。) 表現しなければ
なりません。また本文部文中のデータは、部分ごとに、
適切な各本文部分の CTE 領域をつけて符号化することが出来ます。
* 5.1.1. Common Syntax
[PRE[
This section defines a common syntax for subtypes of "multipart".
All subtypes of "multipart" must use this syntax. A simple example
of a multipart message also appears in this section. An example of a
more complex multipart message is given in RFC 2049.
]PRE]
この節では "multipart" の亜型の共通の構文を定義します。
"Multipart" の全ての亜型はこの構文をつかわなければなりません。
多部分メッセージの単純な例もこの節に提示します。より複雑な多部分メッセージ
の例は RFC 2049 にあります。
[PRE[
The Content-Type field for multipart entities requires one parameter,
"boundary". The boundary delimiter line is then defined as a line
consisting entirely of two hyphen characters ("-", decimal value 45)
followed by the boundary parameter value from the Content-Type header
field, optional linear whitespace, and a terminating CRLF.
]PRE]
多部分実体の CT 領域では、パラメーター "boundary" が必要です。
境界区切行は2つのハイフン文字 ("-", 10進値45) とそれに続けて
CT 頭領域から boundary パラメーター値, 省略可能な行空白間隔, 終端 CRLF
の全体から構成されます。
[PRE[
NOTE: The hyphens are for rough compatibility with the earlier RFC
934 method of message encapsulation, and for ease of searching for
the boundaries in some implementations. However, it should be noted
that multipart messages are NOT completely compatible with RFC 934
encapsulations; in particular, they do not obey RFC 934 quoting
conventions for embedded lines that begin with hyphens. This
mechanism was chosen over the RFC 934 mechanism because the latter
causes lines to grow with each level of quoting. The combination of
this growth with the fact that SMTP implementations sometimes wrap
long lines made the RFC 934 mechanism unsuitable for use in the event
that deeply-nested multipart structuring is ever desired.
]PRE]
参考: ハイフンは、かつての RFC 934 のメッセージのカプセル化方式
との大雑把な互換性と、幾つかの実装で区切りを探すのを容易にする
ためにあります。しかし、多部分メッセージは RFC 934 カプセル化と
完全には互換でないことに注意して下さい。特に、 RFC 934 の、ハイフンで始まる
埋め込み行の quote 記法には従っていません。 RFC 934 の方式では
quote の各段階ごとに行が長くなっていきます。
この成長と、 SMTP 実装がしばしば長い行を折り返すという実情から、
RFC 934 の方式は深く入れ子になった多部分構造もが望ましいところで
使うのには不適切ということになります。
[PRE[
WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
type field is such that it is often necessary to enclose the boundary
parameter values in quotes on the Content-type line. This is not
always necessary, but never hurts. Implementors should be sure to
study the grammar carefully in order to avoid producing invalid
Content-type fields. Thus, a typical "multipart" Content-Type header
field might look like this:
]PRE]
実装者への警告: CT 領域のパラメーターの文法から、 boundary パラメータ値を
CT 行において引用符で囲む必要がしばしばあります。これは常に必要では
ありませんが、囲んでおけば損傷することはありません。
実装者は不適切な CT 領域を生成しないように、文法を良く研究するべきです。
よって、典型的な "" CT 頭領域はこのようになります。
[PRE[
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
]PRE]
[PRE[
But the following is not valid:
]PRE]
しかし次のものは(コロンのため)妥当ではありません。
[PRE[
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
]PRE]
(because of the colon) and must instead be represented as
代わりに次のように表現しなければなりません。
[PRE[
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"
]PRE]
[PRE[
This Content-Type value indicates that the content consists of one or
more parts, each with a structure that is syntactically identical to
an RFC 822 message, except that the header area is allowed to be
completely empty, and that the parts are each preceded by the line
]PRE]
この CT 値は、内容が一つ以上の部分から構成されていて、
それぞれが、頭領域は完全に空でも良いことを除いて
RFC 822 メッセージと構文的には同じ構造を持っていて、
部分はそれぞれ次の行が前にあることを示します。
[PRE[
--gc0pJq0M:08jU534c0p
]PRE]
[PRE[
The boundary delimiter MUST occur at the beginning of a line, i.e.,
following a CRLF, and the initial CRLF is considered to be attached
to the boundary delimiter line rather than part of the preceding
part. The boundary may be followed by zero or more characters of
linear whitespace. It is then terminated by either another CRLF and
the header fields for the next part, or by two CRLFs, in which case
there are no header fields for the next part. If no Content-Type
field is present it is assumed to be "message/rfc822" in a
"multipart/digest" and "text/plain" otherwise.
]PRE]
境界区切りは行のはじめ、すなわち CRLF の後に出現しなければ
'''なりません'''。最初の CRLF は前の部分ではなく境界区切行の
付属するものと考えます。区切りの後には0文字以上の行空白間隔が続いても
構いません。その後の別の CRLF と次の部分の頭領域, または2つの CRLF
で終端となります。後者の場合は次の部分の頭領域はありません。
CT 領域が無い場合、 "" では "" が, それ以外では "" が仮定されます。
[PRE[
NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break). Body parts that must be
considered to end with line breaks, therefore, must have two CRLFs
preceding the boundary delimiter line, the first of which is part of
the preceding body part, and the second of which is part of the
encapsulation boundary.
]PRE]
参考: 境界区切りの前の CRLF は概念的には境界に付属するものですから、
CRLF (改行) で終わらない部分を作ることが可能なわけです。また、
改行で終わると考えなければならない本文部分では、境界区切行の前に
2つの CRLF がなければなりません。最初のものは前の本文部分の一部で、
2番目のものはカプセル化境界の一部です。
Boundary delimiters must not appear within the encapsulated material,
and must be no longer than 70 characters, not counting the two leading hyphens.
境界区切りはカプセル化されたものの中には出現してはならず、
2つの先導ハイフンを数えないで、70文字を超えてもならりません。
The boundary delimiter line following the last body part is a
distinguished delimiter that indicates that no further body parts
will follow. Such a delimiter line is identical to the previous
delimiter lines, with the addition of two more hyphens after the
boundary parameter value.
最後の本文部分に続く境界区切行は、それ以上本文部分が
続かないことを示す違った区切りになります。この区切行は今までの
区切行に、2つのハイフンを boundary パラメーター値の後に加えたもの
になります。
[PRE[
--gc0pJq0M:08jU534c0p--
]PRE]
[PRE[
NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the
boundary value with the beginning of each candidate line. An exact
match of the entire candidate line is not required; it is sufficient
that the boundary appear in its entirety following the CRLF.
]PRE]
実装者への参考: 境界文字列比較は、各候補行の最初と境界値を
比較します。候補行全体との正確な一致は必要ありません。
CRLF の直ぐ後に境界が出現すれば十分です。
[PRE[
There appears to be room for additional information prior to the
first boundary delimiter line and following the final boundary
delimiter line. These areas should generally be left blank, and
implementations must ignore anything that appears before the first
boundary delimiter line or after the last one.
]PRE]
最初の境界区切行の前と最後の境界区切行の後に追加情報の場所があります。
この領域は通常からにしておくべきで、実装は最初の境界区切行の前や
最後のの後に出現するものを全て無視しなければなりません。
[PRE[
NOTE: These "preamble" and "epilogue" areas are generally not used
because of the lack of proper typing of these parts and the lack of
clear semantics for handling these areas at gateways, particularly
X.400 gateways. However, rather than leaving the preamble area
blank, many MIME implementations have found this to be a convenient
place to insert an explanatory note for recipients who read the
message with pre-MIME software, since such notes will be ignored by
MIME-compliant software.
]PRE]
参考 この "preamble" (前書き) と "epoligue" (後書き)
は、適切な型付けが出来なく、
関門でのこれらの領域の取り扱いでの意味が明確になっていないので、通常
使われません。しかし、前書き領域を空にしておくのではなく、
多くの MIME 実装は、 MIME 以前のソフトウェアでメッセージを読む受信者への
説明メモを挿入する都合の良い場所としています。このメモは
MIME 適合ソフトウェアには無視されますから。
[PRE[
NOTE: Because boundary delimiters must not appear in the body parts
being encapsulated, a user agent must exercise care to choose a
unique boundary parameter value. The boundary parameter value in the
example above could have been the result of an algorithm designed to
produce boundary delimiters with a very low probability of already
existing in the data to be encapsulated without having to prescan the
data. Alternate algorithms might result in more "readable" boundary
delimiters for a recipient with an old user agent, but would require
more attention to the possibility that the boundary delimiter might
appear at the beginning of some line in the encapsulated part. The
simplest boundary delimiter line possible is something like "---",
with a closing boundary delimiter line of "-----".
]PRE]
参考: 境界区切りはカプセル化されている本文部分に出現してはならないので、
利用者代理者は独特な boundary パラメーター値を選ぶのに注意しなければなりません。
上の例にある boundary パラメーター値は、カプセル化されるデータを
予め確認せずに、データ中に
存在する確率が非常に低い境界区切りを生成するように設計された算法の結果
であるとしましょう。他の算法ではより「可読」な境界区切りを、
古い利用者代理者の受信者のために使うかもしれません。しかしその場合は
境界区切リがカプセル化されたデータの中の幾つかの行のはじめに
現れるかもしれない可能性により注意する必要がありましょう。
いちばん簡単な可能な境界区切行は "---" のようなもので、
この場合閉じ境界区切行は "-----" となります。
As a very simple example, the following multipart message has two
parts, both of them plain text, one of them explicitly typed and one
of them implicitly typed:
非常に単純な例として、次の多部分メッセージは2つの部分があり、
両方とも平文で、1つは明示的に型を示していませんが、他方は明示的に
示しています。
[PRE[
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
]PRE]
[PRE[
This is the preamble. It is to be ignored, though it
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.
]PRE]
[PRE[
--simple boundary
]PRE]
[PRE[
This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
]PRE]
[PRE[
This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.
]PRE]
[PRE[
--simple boundary--
]PRE]
[PRE[
This is the epilogue. It is also to be ignored.
]PRE]
これは前書きです。これは無視されますが、
非 MIME 適合読者のために説明メモを入れるのに、
構成代理者にとって手軽な場所であります。
これは暗黙の内に US-ASCII の平文に型付けしています。
改行で終わり'''ません'''。
これは明示的に US-ASCII の平文に型付けしています。
これは改行でおわり'''ます'''。
これは後書きです。これも無視されます。
[PRE[
The use of a media type of "multipart" in a body part within another
"multipart" entity is explicitly allowed. In such cases, for obvious
reasons, care must be taken to ensure that each nested "multipart"
entity uses a different boundary delimiter. See RFC 2049 for an
example of nested "multipart" entities.
]PRE]
他の "" 実体中の本文部分での媒体型 "" の使用は明示的に認められます。
その様な場合、明白な理由により、各入れ子 "" 実体が
違う境界区切を使うことが確実になるように注意しなければなりません。
入れ子の "" 実態の例は RFC 2049 を見て下さい。
The use of the "multipart" media type with only a single body part
may be useful in certain contexts, and is explicitly permitted.
一つだけの本文部分の "" 媒体型の使用は場面によっては有用かも
しれず、明白に認められます。
[PRE[
NOTE: Experience has shown that a "multipart" media type with a
single body part is useful for sending non-text media types. It has
the advantage of providing the preamble as a place to include
decoding instructions. In addition, a number of SMTP gateways move
or remove the MIME headers, and a clever MIME decoder can take a good
guess at multipart boundaries even in the absence of the Content-Type
header and thereby successfully decode the message.
]PRE]
参考: 経験的には、1つの本文部分の "" 媒体型は、
非 text 媒体型を送るのに便利です。前書きを復号指示の場所
として提供できるという利点があります。加えて、多くの
SMTP 関門が MIME 頭を動かしたり消したりします。
りこうな MIME 復号者は、 CT 頭が無くても多部分境界のうまい推定
が出来ますから、これによりメッセージの復号が成功します。
[PRE[
The only mandatory global parameter for the "multipart" media type is
the boundary parameter, which consists of 1 to 70 characters from a
set of characters known to be very robust through mail gateways, and
NOT ending with white space. (If a boundary delimiter line appears to
end with white space, the white space must be presumed to have been
added by a gateway, and must be deleted.) It is formally specified
by the following BNF:
]PRE]
"" 媒体型の共通の必須パラメーターは boundary パラメーターだけです。
これはメイル関門で非常に強いと言われている文字の集合から、
1〜70文字使って構成するもので、空白間隔で終わり'''ません'''。
(境界区切行が空白間隔で終わって現れた場合、空白間隔は
関門で追加されたものとして考えて削除しなければなりません。)
次に示す BNF が正式な規定です。
[PRE[
boundary := 0*69<bchars> bcharsnospace
]PRE]
[PRE[
bchars := bcharsnospace / " "
]PRE]
[PRE[
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
"+" / "_" / "," / "-" / "." /
"/" / ":" / "=" / "?"
]PRE]
Overall, the body of a "multipart" entity may be specified as follows:
概して、 "multipart" 実体の本文は次のように規定することが出来ます。
[PRE[
dash-boundary := "--" boundary
; boundary taken from the value of
; boundary parameter of the
; Content-Type field.
]PRE]
; CT 領域の boundary パラメーターの値から採った境界
[PRE[
multipart-body := [preamble CRLF]
dash-boundary transport-padding CRLF
body-part *encapsulation
close-delimiter transport-padding
[CRLF epilogue]
]PRE]
[PRE[
transport-padding := *LWSP-char
; Composers MUST NOT generate
; non-zero length transport
; padding, but receivers MUST
; be able to handle padding
; added by message transports.
]PRE]
; 構成者は0で無い長さの転送埋めを生成しては'''なりません'''が、
受信者はメッセージ転送者が加えた埋めを扱えなければ
'''なりません'''。
[PRE[
encapsulation := delimiter transport-padding
CRLF body-part
]PRE]
[PRE[
delimiter := CRLF dash-boundary
]PRE]
[PRE[
close-delimiter := delimiter "--"
]PRE]
[PRE[
preamble := discard-text
]PRE]
[PRE[
epilogue := discard-text
]PRE]
[PRE[
discard-text := *(*text CRLF) *text
; May be ignored or discarded.
]PRE]
; 無視したり捨てたりして構いません。
[PRE[
body-part := MIME-part-headers [CRLF *OCTET]
; Lines in a body-part must not start
; with the specified dash-boundary and
; the delimiter must not appear anywhere
; in the body part. Note that the
; semantics of a body-part differ from
; the semantics of a message, as
; described in the text.
]PRE]
; body-part 中の行は指定された dash-boundary で始まってはなりませんし、
delimiter は本文部文中のどこにも現れてはなりません。なお、
body-part の意味は、文中に述べたようにメッセージの意味とは異なります。
[PRE[
OCTET := <any 0-255 octet value>
]PRE]
IMPORTANT: The free insertion of linear-white-space and RFC 822
comments between the elements shown in this BNF is NOT allowed since
this BNF does not specify a structured header field.
重要: この BNF 中の要素間への lws と RFC 822 注釈の自由な挿入は、
この BNF が構造化頭領域を規定するものではないので、
認められま'''せん'''。
[PRE[
NOTE: In certain transport enclaves, RFC 822 restrictions such as
the one that limits bodies to printable US-ASCII characters may not
be in force. (That is, the transport domains may exist that resemble
standard Internet mail transport as specified in RFC 821 and assumed
by RFC 822, but without certain restrictions.) The relaxation of
these restrictions should be construed as locally extending the
definition of bodies, for example to include octets outside of the
US-ASCII range, as long as these extensions are supported by the
transport and adequately documented in the Content- Transfer-Encoding
header field. However, in no event are headers (either message
headers or body part headers) allowed to contain anything other than
US-ASCII characters.
]PRE]
参考: ある転送 enclave では、本文を印字可能 US-ASCII 文字
に制限するといった RFC 822 の制限が強制されていないかもしれません。
(すなわち、ある制限を除いた RFC 821 で規定された標準 Internet メイル転送に似た、
そして RFC 822 と見せかけた転送範囲が存在するかもしれません。)
こうした制限の緩和は、
例えば US-ASCII 範囲外のオクテットを含めることは、
これらの拡張を転送が対応していて、 CTE 頭領域で十分に明示される限りは、
本文の定義の局地的な拡張と解釈するべきです。しかし、頭
(メッセージ頭と本文部分かしら共に) で US-ASCII 以外の文字を含めることは
認められません。
[PRE[
NOTE: Conspicuously missing from the "multipart" type is a notion of
structured, related body parts. It is recommended that those wishing
to provide more structured or integrated multipart messaging
facilities should define subtypes of multipart that are syntactically
identical but define relationships between the various parts. For
example, subtypes of multipart could be defined that include a
distinguished part which in turn is used to specify the relationships
between the other parts, probably referring to them by their
Content-ID field. Old implementations will not recognize the new
subtype if this approach is used, but will treat it as
multipart/mixed and will thus be able to show the user the parts that
are recognized.
]PRE]
参考: "multipart" 型に目立って欠けているのは、本文部分に関する構造の記述です。
より構造化された, よりまたは統合されたメッセージ機能を提供しようと
する時は、構造的には同じであるが各部分間の関係を定義した多部分の
亜型を定義するべきです。例えば、ある多部分の亜型は、特別な部分を含み、
次にはこれが他の部分との関係を指定する (おそらくは
Content-ID 領域を参照するのに使って。) のに使われるというように定義出来ます。
この方法が使われた時に古い実装は新しい亜型を認識できませんが、
multipart/mixed であるものとして扱い、認識できる部分を利用者に示す
ことが出来るでしょう。
* 5.1.2. Handling Nested Messages and Multiparts
[PRE[
The "message/rfc822" subtype defined in a subsequent section of this
document has no terminating condition other than running out of data.
Similarly, an improperly truncated "multipart" entity may not have
any terminating boundary marker, and can turn up operationally due to
mail system malfunctions.
]PRE]
この文書の後の節で定義する "" 亜型は、データが終わる以外に
終端を示すものがありません。同様に、不適切に切られた "multipart"
実体は終端境界印を持たないかもしれません。そしてこれは、
メイル系統の不調により出現する可能性があります。
[PRE[
It is essential that such entities be handled correctly when they are
themselves imbedded inside of another "multipart" structure. MIME
implementations are therefore required to recognize outer level
boundary markers at ANY level of inner nesting. It is not sufficient
to only check for the next expected marker or other terminating
condition.
]PRE]
このような実体が他の "multipart" 構造の内側に埋め込まれていた時に
正しく扱えることが必要です。 MIME 実装は従って、内側の入れ子の
'''どの'''段階にあっても外側の境界印を認識出来る必要があります。
次に予期される印やその他の終端を確認するだけでは十分ではありません。
* 5.1.3. Mixed Subtype
[PRE[
The "mixed" subtype of "multipart" is intended for use when the body
parts are independent and need to be bundled in a particular order.
Any "multipart" subtypes that an implementation does not recognize
must be treated as being of subtype "mixed".
]PRE]
"multipart" の "mixed" 亜型は、各本文部分が独立していて、
特定の順で束ねる必要があるときに使うことを意図しています。
実装が認識出来ない "multipart" の亜型はすべて、亜型 "mixed"
であるとして扱わなければなりません。
* 5.1.4. Alternative Subtype
See [[multipart/alternative媒体型]]
* 5.1.5. Digest Subtype
See [[multipart/digest媒体型]]
* 5.1.6. Parallel Subtype
See [[multipart/parallel媒体型]]
* 5.1.7. Other Multipart Subtypes
Other "multipart" subtypes are expected in the future. MIME
implementations must in general treat unrecognized subtypes of
"multipart" as being equivalent to "multipart/mixed".
他の "multipart" 亜型が将来期待されます。 MIME 実装は通常、
認識出来ない "multipart" の亜型を "multipart/mixed" と同等であるものとして
扱わなければなりません。
]FIG]
[FIG[
[FIGCAPTION[
[221] RFC 2049 Appendix A -- A Complex Multipart Example
]FIGCAPTION]
What follows is the outline of a complex multipart message. This
message contains five parts that are to be displayed serially: two
introductory plain text objects, an embedded multipart message, a
text/enriched object, and a closing encapsulated text message in a
non-ASCII character set. The embedded multipart message itself
contains two objects to be displayed in parallel, a picture and an
audio fragment.
[PRE[
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Ned Freed <ned@innosoft.com>
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
]PRE]
[PRE[
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
]PRE]
[PRE[
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
]PRE]
[PRE[
--unique-boundary-1
]PRE]
[PRE[
... Some text appears here ...
]PRE]
[PRE[
[Note that the blank between the boundary and the start
of the text in this part means no header fields were
given and this is text in the US-ASCII character set.
It could have been done with explicit typing as in the
next part.]
]PRE]
[PRE[
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
]PRE]
[PRE[
This could have been part of the previous part, but
illustrates explicit versus implicit typing of body
parts.
]PRE]
[PRE[
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
]PRE]
[PRE[
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
]PRE]
[PRE[
... base64-encoded 8000 Hz single-channel
mu-law-format audio data goes here ...
]PRE]
[PRE[
--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
]PRE]
[PRE[
... base64-encoded image data goes here ...
]PRE]
[PRE[
--unique-boundary-2--
]PRE]
[PRE[
--unique-boundary-1
Content-type: text/enriched
]PRE]
[PRE[
This is <bold><italic>enriched.</italic></bold>
<smaller>as defined in RFC 1896</smaller>
]PRE]