/
565.txt
1300 lines (1023 loc) · 70 KB
/
565.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
[45] [DFN[[RUBYB[[[MIME型]]]@en[MIME type]]]]は、[[ファイル]]の種別を表す短い[[識別子]]です。
大分類と小分類を [CODE[text/plain]] のように[[斜線]]で区切って識別子とするのが特徴です。
[21] [[MIME]] ([[電子メール]]) の他、[[Web]] ([[HTTP]]/[[HTML]]) や [[SIP]]、
[[RTP]] など様々な[[応用]]でデータ形式の記述方式として広く採用されています。
;; [143] [[ファイルシステム]]における[[拡張子]]など[[ファイル]]の種類におおむね対応する概念です。
* 仕様書
[REFS[
- [35] '''[CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]] ([TIME[2015-02-11 00:35:08 +09:00]] 版) <http://tools.ietf.org/html/rfc6838>'''
-- [166] [CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]] ([TIME[2015-02-11 00:35:08 +09:00]] 版) <http://tools.ietf.org/html/rfc6838#section-4.1>
-- [170] [CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]] ([TIME[2015-02-11 00:35:08 +09:00]] 版) <http://tools.ietf.org/html/rfc6838#section-4.2>
-- [191] [CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]] ([TIME[2015-02-11 00:35:08 +09:00]] 版) <http://tools.ietf.org/html/rfc6838#section-4.3>
-- [208] [CITE@en[RFC 6838 - Media Type Specifications and Registration Procedures]] ([TIME[2015-02-11 00:35:08 +09:00]] 版) <http://tools.ietf.org/html/rfc6838#section-5.5>
- [71] [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.1>
- [84] [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-5.3.2>
- [131] [CITE[Media Types]] ([TIME[2015-04-16 05:20:38 +09:00]] 版) <http://www.iana.org/assignments/media-types/media-types.xhtml>
]REFS]
* 呼称
[144] [[MIME型]]は、他に次のような名前で呼ばれています。
[FIG(short list)[
- [DFN[[RUBY[媒体型][メディアタイプ]@en[media type]]]]
- [DFN[[RUBYB[インターネット媒体型]@en[Internet Media Type]]]]
- [DFN[[[MIME]] [RUBY[媒体型][メディアタイプ]@en[media type]]]]
- [DFN[[RUBYB[[[内容型]]]@en[content type]]]]
]FIG]
[145] [[MIME型]]は大分類と小分類の組で表されますが、この大分類も「[RUBYB[型]@en[type]]」、
全体も「型」と呼ばれるため、どちらを指すかがしばしば曖昧となっています。
[146] 「[[MIME型]]」などと修飾される場合は全体を指していることが多く、
「型」とのみ呼ばれる時は大分類を指していることが多いようですが、例外もあります。
大分類であることを明示する時は、「[DFN[[RUBYB[最上位型]@en[top-level type]]]]」
のように[RUBYB[最上位]@en[top-level]]と修飾するのが一般的です。
[EG[
[147] ほとんどの場合「[[MIME型]]」や「[[内容型]]」と言えば [CODE(MIME)@en[text/plain]]
全体を指しますが、稀に [CODE(MIME)@en[text]] のみを指していることがあります。
]EG]
[148] [[HTML Standard]] や [[Fetch Standard]] などの現在の [[Web]]
の仕様書は、最も普及した用語である「[[MIME型]]」を採用しています。
[[MIME Sniffing Standard]] は「[[MIME型]]」などの用語を定義しています。
[149] [[IETF]] は「[[媒体型]]」を正式な用語と考えているようで、
近年の [[RFC]] の多くはこの語を採用しています。しかし次に示す通り歴史的には相当な混乱があり、
現在でも完全に統一されているわけではないようです。
[104] [[RFC 1341]]/[[RFC 1521]] は「[CODE(MIME)@en[Content-Type]] の値」といったような表現を使っており、現在の「[[MIME型]]」に相当する特別な用語は用意していなかったようです。
「content-type/subtype pair」という表現もあります。また登録雛形では
「MIME type name」/「MIME subtype name」となっています [SRC[>>102, >>105]]。
[108] [[RFC 1341]]/[[RFC 1521]] は各1箇所だけ「[RUBYB[媒体型]@en[media type]]」
という語を使っています [SRC[>>106, >>107]]。
[113] [[RFC 1590]] には従来の「MIME [RUBYB[型]@en[Type]]」を「[RUBYB[媒体型]@en[''M''edia ''T''ype]]」
と呼ぶ [SRC[>>111]] との記述があります。しかし
「Content-type/subtype pair」という表現も残っています。また
「Media type name」/「Media subtype name」という記述もあります。
[117] [[RFC 2048]] は「[RUBYB[[[媒体型]]]@en[''m''edia ''t''ype]]」
[SRC[>>114]] と表現しています。1箇所だけ「MIME type and subtype」
との記述もあります。「MIME media type」という表現や、
「MIME media type name」/「MIME subtype name」という表現も数箇所だけ登場します。
[124] [[RFC 4288]] や [[RFC 6838]] は「[RUBYB[[[媒体型]]]@en[''m''edia ''t''ype]]」[SRC[>>121]]
に統一しています。
[133] [[IANA登録簿]]の題名は当初は「MIME Media Types」[SRC[>>132]] でした。
「Content Types」/「Content Subtypes」という表現もありました。
[134] 現在の[[IANA登録簿]]の題名は「Media Types」[SRC[>>131]] となっています。
「Media Types (formerly known as MIME types) and Media Subtypes」
という記述もあります。
[135] 多くの [[RFC]] は「Internet Media Type」とも呼んでいます。
古いものでは [[RFC 1866]] がこの語を使っています [SRC[>>137]] (最古のものが何かは不明)。
[[RFC 3420]] では題名にもなっています [SRC[>>136]] (が本文中では
「MIME 媒体型」と呼ばれています)。
;; [139] 「"MIME types" (renamed "Internet Media Types" in later specs [RFC2046])」
と述べた文書 [SRC[>>138]] もありますが、 [[RFC 2046]] には
「Internet Media Type」は登場していません。
[141] [[HTML4]] は「[RUBYB[[[内容型]]]@en[content type]]」と呼んでいました。
理由として、当時の用法により沿っている点、[[CSS]] の[[媒体型]]と区別できる点を挙げています
[SRC[>>140]]。しかしその説明と同じ章で「MIME 型」という語も使われています [SRC[>>140]]。
;; [142] この当時から「[[MIME型]]」が最も一般的な用語だったように思います。
[REFS[
- [137] [CITE@en[RFC 1866 - The 'text/html' Media Type]] ([TIME[2015-04-06 15:12:54 +09:00]] 版) <https://tools.ietf.org/html/rfc1866>
- [136] [CITE@en[RFC 3420 - Internet Media Type message/sipfrag]] ([TIME[2015-04-05 20:24:31 +09:00]] 版) <https://tools.ietf.org/html/rfc3420>
- [138] [CITE@en[draft-masinter-mime-web-info-02 - MIME and the Web]] ([TIME[2015-01-18 18:04:50 +09:00]] 版) <https://tools.ietf.org/html/draft-masinter-mime-web-info-02>
- [140] [CITE@en[Basic HTML data types]] ([TIME[1999-12-25 08:25:40 +09:00]] 版) <http://www.w3.org/TR/html4/types.html#h-6.7>
]REFS]
* 意味
[150] [[MIME型]]は、大分類である[RUBYB[型]@en[type]]と小分類である[RUBYB[部分型]@en[subtype]]で構成されます。
[151] [DFN[[RUBYB[型]@en[type]]]] ([DFN[[RUBYB[[[最上位型]]]@en[top-level type]]]]) は、元々は[[媒体]]の種類を区別することを意図していたようで
(「[[媒体型]]」の語源)、 [CODE[[[text]]]]、[CODE[[[audio]]]]、[CODE[[[video]]]]
などがあります。しかし [CODE[[[text]]]] の意味するところが曖昧だったり、
ほとんどが [CODE[[[application]]]] に分類されていたりして、
ほとんど機能していません。
[152] [DFN[[RUBYB[部分型][subtype]]]]は、[[型]]内における細かな分類であり、
実際のファイル形式の相当するものです。 [CODE[[[text/plain]]]] の [CODE[plain]]、
[CODE[[[image/png]]]] の [CODE[png]]、[CODE[[[application/pdf]]]] の [CODE[pdf]]
などがあります。
[153] [[型]]と[[部分型]]は、組として1つの [[MIME型]]を構成します。
異なる[[型]]と[[部分型]]を組み合わせることはできません。例えば
[CODE[[[image/png]]]] の [CODE[image]] を [CODE[video]] に置き換えるような使い方はできず、
まったく異なる [[MIME型]]となります。
;; [154] [CODE[[[video/ogg]]]] と [CODE[[[audio/ogg]]]] のように異なる[[型]]で同じ[[部分型]]の
[[MIME型]]が定義されていることはありますが、すべての[[型]]に対して定義されているわけではありません。
また、[[部分型]]が同じだからといって異なる[[型]]の [[MIME型]]が同じファイル形式を表しているとは限りません。
[177] [[部分型]]の決定には[[型]]の意味を考慮しなければ[['''ならず''']]、
[[部分型]]は[[型]]の制約に適合しなければ[['''なりません''']] [SRC[>>170]]。
[EG[
[178] 例えば [CODE(MIME)@en[[[multipart/[VAR[*]]]]]] に属する[[部分型]]は
[CODE(MIME)@en[[[multipart/[VAR[*]]]]]] の共通の構文に従う必要があります。
]EG]
[155] ファイル形式と [[MIME型]]は、一対一対応関係にはありません。
同じ形式に複数の[[MIME型]]を割り当てるのは[RUBYB[非推奨]@en[discouraged]]です
[SRC[>>170]] が、実際には数多くあります。
[EG[
[156] [[XML]] の [[MIME型]]には [CODE(MIME)@en[[[text/xml]]]] や
[CODE(MIME)@en[[[application/xml]]]] があります。
[[XHTML]] の [[MIME型]]には [CODE(MIME)@en[[[application/xhtml+xml]]]] や
[CODE(MIME)@en[[[application/xml]]]] があります。
]EG]
[182] [[IANA登録簿]]は[RUBYB[好ましい]@en[prefer]]ものを1つ選び、
それ以外を「deprecated alias」とすることを求めています [SRC[>>170]]。
その場合[[応用]]は好ましいものを使わなければ[['''なりません''']] [SRC[>>170]]。
[157] [[MIME型]]には、零個以上の[[引数]]を指定することができます (詳細は後述)。
[[MIME型]]という用語が[[引数]]を含んでいるかどうかは、文脈により異なります。
明確に定義されていないことも少なくありません。
;; [159] [[MIME型]]によっては[[引数]]を必須と規定していることもありますが、
[[引数]]を指定できない文脈や、指定されていると正しく処理できない実装も少なくありません。
[184] 世間で用いられる [[MIME型]]は、その本来の意味を逸脱しているものも少なくありません。
[EG[
[186] 例えば [[HTTP]] で[[ダウンロード]]させたい時に
[CODE(MIME)@en[[[application/octet-stream]]]] や
[CODE(MIME)@en[[[application/download]]]] が用いられることがあります。
]EG]
[EG[
[185] 例えば [[Web API]] の [CODE(HTTP)@en[[[Accept:]]]] [[ヘッダー]]では、
[[API]] の動作モードの指定に独自の [[MIME型]]が用いられることがあります。
]EG]
* MIME 型の一覧
[161] [[MIME型]]は、標準仕様で規定されているものもそうでないものも、
よく使われているものもそうでないものも含め、実に数多く、様々なものが存在しています。
[162] 次の表で [CODE[[[*]]]] は、複数の [[MIME型]]のパターンを表しています。
所属する [[MIME型]]は、リンク先の各ページを参照してください。
ただし、場合によっては複数の [[MIME型]]を表すため、あるいは設定ミスその他の理由でしばしば
[[MIME型]]として使われるものもいくつかあります。
[FIG(list short)[
[FIGCAPTION[
[26] [[MIME型]]の一覧
]FIGCAPTION]
,[CODE(MIME)@en[[[*/*]]]]
,[CODE(MIME)@en[[[vnd.android.cursor.dir/[VAR[*]]]]]]
,[CODE(MIME)@en[[[app/gg]]]],[[Google Desktop]] [[gadget]]
,[CODE(MIME)@en[[[x-application/*]]]]
,[CODE(MIME)@en[[[zz-application/zz-winassoc-tgz]]]]
,[CODE(MIME)@en[[[archive/[VAR[*]]]]]]
,[CODE(MIME)@en[[[audio/[VAR[*]]]]]]
,[CODE(MIME)@en[[[audio-file]]]]
,[[auth/sicily]] ,[[FrontPage]]
,[CODE(MIME)@en[[[avro/binary]]]]
,[CODE(MIME)@en[[[x-be2]]]]
,[CODE(MIME)@en[[[bin/application]]]]
,[CODE(MIME)@en[[[binary/octet-stream]]]]
,[CODE(MIME)@en[[[chemical/[VAR[*]]]]]]
,[CODE(MIME)@en[[[coloreal/embedded]]]]
,[[x-conference/x-cooltalk]] ,[[CoolTalk]] [Netscape]
,[CODE(MIME)@en[[[content/unknown]]]]
,[CODE(MIME)@en[[[x-data/xact-error]]]]
,[CODE(MIME)@en[[[unknown]]]]
,[CODE(MIME)@en[[[database/x-unknown]]]]
,[CODE(MIME)@en[[[default]]]]
,[CODE(MIME)@en[[[defiant/xsl-template]]]]
,[[x-device/floppy]] ,[GNOME]
,[CODE(MIME)[[[x-directory/normal]]]]
,[CODE(MIME)@en[[[document/x-epub]]]]
,[CODE(MIME)@en[[[drawing/x-dwf]]]]
,[CODE(MIME)@en[[[dsmcc-[VAR[*]]/[VAR[*]]]]]]
,[CODE(MIME)@en[[[dsmcc-download/jpeg]]]]
,[CODE(MIME)@en[[[dsmcc-file/mpeg2-ps]]]]
,[CODE(MIME)@en[[[dsmcc-file/html]]]]
,[CODE(MIME)@en[[[dsmcc-stream/mpeg2-ts]]]]
,[CODE(MIME)@en[[[dvi]]]],[[RFC 1049]]
,[CODE(MIME)@en[[[example/[VAR[*]]]]]]
,[[x-ferrum-head/*]]
,[[x-ferrum-menu/*]]
,[CODE(MIME)@en[[[font/[VAR[*]]]]]]
,[CODE(MIME)@en[[[x-font/[VAR[*]]]]]]
,[CODE(MIME)@en[[[x-form/x-openscape]]]]
,[CODE(MIME)@en[[[gadget/x-googlegadget]]]]
,[CODE(MIME)[[[graphics/x-inventor]]]] ,Open Inventor 3次元 scenes
,[CODE(MIME)@en[[[gzip/document]]]]
,[CODE(MIME)@en[[[image/[VAR[*]]]]]]
,[CODE(MIME)@en[[[in/share]]]]
,[CODE(MIME)@en[[[inode/[VAR[*]]]]]] ,[freedesktop.org]
,[CODE(MIME)@en[[[interface/x-winamp-skin]]]]
,[CODE(MIME)@en[[[x-jigsaw/config]]]]
,[CODE(MIME)@en[[[x-kom/basic]]]]
,[CODE(MIME)@en[[[x-lml/x-lml]]]]
,[CODE(MIME)@en[[[math/[VAR[*]]]]]]
,[[matter-transport/*]] ,[RFC1437]
,[CODE(MIME)@en[[[mail-file]]]]
,[CODE(MIME)@en[[[mce-text/javascript]]]]
,[CODE(MIME)@en[[[message/[VAR[*]]]]]]
,[CODE(MIME)@en[[[mforge/x-mirage]]]]
,[CODE(MIME)@en[[[midi/mid]]]]
,[CODE(MIME)@en[[[misc/ultravox]]]]
,[CODE(MIME)@en[[[model/[VAR[*]]]]]]
,[CODE(MIME)@en[[[x-model/x-mesh]]]]
,[CODE(MIME)@en[[[more/less]]]]
,[CODE(MIME)@en[[[mozilla.application/cached-xul]]]]
,[CODE(MIME)@en[[[multipart/[VAR[*]]]]]]
,[CODE(MIME)@en[[[x-wap.multipart/vnd.uplanet.header-set]]]]
,[CODE(MIME)@en[[[x-music/x-midi]]]]
,[CODE(MIME)@en[[[none]]]]
,[CODE(MIME)@en[[[octet/stream]]]]
,[CODE(MIME)@en[[[plain/text]]]]
,[CODE(MIME)@en[[[plugin/[VAR[*]]]]]]
,[CODE(MIME)@en[[[x-pmaildx/x-mmctrl]]]]
,[CODE(MIME)@en[[[x-postpet/[VAR[*]]]]]]
,[CODE(MIME)@en[[[postscript]]]],[[RFC 1049]]
,[CODE(MIME)@en[[[postscript-file]]]]
,[CODE(MIME)@en[[[scribe]]]],[[RFC 1049]]
,[CODE(MIME)[[[x-script/x-wfxscript]]]]
,[CODE(MIME)@en[[[sgml]]]],[[RFC 1049]]
,[CODE(MIME)@en[[[x-shader/x-fragment]]]]
,[CODE(MIME)@en[[[x-shader/x-vertex]]]]
,[CODE(MIME)[[[x-squid-internal/vary]]]]
,[CODE(MIME)@en[[[x-sun-attachment]]]]
,[CODE(MIME)@en[[[sun-deskset-message]]]]
,[CODE(MIME)[[[x-system/x-error]]]] ,[Namazu]
,[CODE(MIME)@en[[[tex]]]],[[RFC 1049]]
,[CODE(MIME)@en[[[text/[VAR[*]]]]]]
,[CODE(MIME)@en[[[x-text-pc/ms-word]]]]
,[CODE(MIME)@en[[[troff]]]],[[RFC 1049]]
,[CODE(MIME)@en[[[unknown/unknown]]]]
,[CODE(MIME)@en[[[x-unknown/octet-stream]]]]
,[CODE(MIME)@en[[[x-unknown/x-unknown]]]]
,[CODE(MIME)@en[[[vector/[VAR[*]]]]]]
,[CODE(MIME)@en[[[video/[VAR[*]]]]]]
,[CODE(MIME)@en[[[videotex/vemmi]]]]
,[CODE(MIME)@en[[[x-visa-ii/x-auth]]]]
,[CODE(MIME)@en[[[windows/*]]]]
,[CODE(MIME)@en[[[workbook/formulaone]]]]
,[CODE(MIME)@en[[[i-world/i-vrml]]]]
,[CODE(MIME)@en[[[x-world/[VAR[*]]]]]]
,[CODE(MIME)@en[[[www/mime]]]] ,[[libwww]]
,[CODE(MIME)@en[[[www/unknown]]]] ,未知 (自動判別) [SRC[[[libwww]]]]
,[CODE(MIME)@en[[[www/source]]]]
,[CODE(MIME)@en[[[x-[VAR[*]]]]]],[[RFC 1049]]
,[CODE(MIME)@en[[[xgi/[VAR[*]]]]]]
,[CODE(MIME)@en[[[xml/user-profile]]]],[[XUP]]
]FIG]
[9] [[JSON]]形式の一覧データファイルが >>10 にあります。
[REFS[
- [10] [CITE@en[data-web-defs/mime-types.txt at master · manakai/data-web-defs]] ([TIME[2015-01-30 12:44:11 +09:00]] 版) <https://github.com/manakai/data-web-defs/blob/master/doc/mime-types.txt>
]REFS]
* 構文
[158] [[MIME型]]の構文 (本体、[[引数]]とも) は統一された規定が存在せず、
[[プロトコル]]や[[マーク付け言語]]などがそれぞれの規定を行っています。
それらは微妙に異なっていることがよくあります。また、明確な規定を欠いていることも少なくありません。
[171] [[RFC 6838]] は [[IANA登録簿]]に登録される [[MIME型]]の[[型]]と[[部分型]]、
[[引数]]名の構文を規定しています。
;; [172] しかしそれらの組み合わせ方 (区切り文字など)、登録されない
[[MIME型]]の構文には言及していません。
[72] [[HTTP]] は [[RFC 2046]] を引用しつつ、独自に [[MIME型]]の構文を定義しています [SRC[>>71]]。
[73] [[MIME型]]は、[[型]]、[CODE[[[/]]]]、[[部分型]]、零個以上の[[引数]]で構成されます。
ただし[[引数]]の前には、 [CODE[[[;]]]] が必要で、 [CODE[[[;]]]]
の前後には [[OWS]] を挿入できます。 [SRC[>>71]]
[74] [[型]]と[[部分型]]は、 [[HTTP]] では[[字句]]です [SRC[>>71]]。
[[IANA登録簿]]では、[[制限名]]です [SRC[>>170]]。
[[IANA登録簿]]では64文字[[以下]]である[['''べきです''']] [SRC[>>170]]。
[173] [[型]]と[[部分型]]は、[[大文字・小文字不区別]]です [SRC[>>71, >>170]]。
[FIG(railroad)[
= [[型]]
= [CODE[[[/]]]]
= [[部分型]]
= *
== [[OWS]]
== [CODE[[[;]]]]
== [[OWS]]
== [[引数]]
]FIG]
[75] [[引数]]は、名前、[CODE[[[=]]]]、値で構成されます [SRC[>>71]]。
[77] [[引数]]の名前は、 [[HTTP]] では[[字句]]です [SRC[>>71]]。
[[IANA登録簿]]では、[[制限名]]です [SRC[>>191]]。
[174] [[引数]]の名前は、[[大文字・小文字不区別]]です [SRC[>>71, >>191]]。
[78] 値は[[字句]]または[[引用文字列]]です。
[[引用符]]の有無は、意味を持ちません。
値の大文字と小文字が区別されるかは、[[引数]]によります。 [SRC[>>71]]
[FIG(railroad)[
= [[引数]]名
= [CODE[[[=]]]]
= |
== [[字句]]
== [[引用文字列]]
]FIG]
;; [80] [CODE[[[=]]]] の前後には [[BWS]] も認められていません [SRC[>>71]]。
[198] [[引数]]の順序には意味がありません。同じ[[引数]]が複数あるのは[RUBYB[[[誤り]]]@en[error]]です。 [SRC[>>191]]
;; [199] 誤りをどう処理するべきなのかは不明です。
[76] [[引数]]の有無は、[[MIME型]]の定義によっては処理に影響があるかもしれません [SRC[>>71]]。
[175] [DFN[[RUBYB[[[制限名]]]@en[restricted-name]]]]は、
[[ASCII英数字]]、 [CODE[[[!]]]], [CODE[#]], [CODE[[[$]]]],
[CODE[[[&]]]], [CODE[[[-]]]], [CODE[[[^]]]], [CODE[[[_]]]],
[CODE[[[.]]]], [CODE[[[+]]]] で構成される1文字[[以上]]126文字[[以下]]の文字列です
[SRC[>>170]]。
;; [176] このうち [CODE[[[.]]]] の初出は[[木]]、[CODE[[[+]]]] は[[構造化構文接尾辞]]を表すことになっています [SRC[>>170]]。
[[部分型]]はそれでよいとして、 [[型]]や[[引数]]名についてこれをどう解釈するべきかは不明瞭です。
また未登録の [[MIME型]]はこれらの規則に従っていないものもあります。
;; [183] [CODE[[[!]]]], [CODE[#]], [CODE[[[$]]]],
[CODE[[[&]]]], [CODE[[[^]]]] を使った [[MIME型]]が実在するのかは不明です。
* 木と [CODE[x-]]
[28] [[部分型]]は [CODE[[[.]]]] を区切り文字とする階層構造によって分けられています。
これは[DFN[[RUBYB[[[木]]]@en[tree]]]]と呼ばれています。
[EG[
[164] [CODE(MIME)@en[[[image/png]]]] は[[標準木]]に、
[CODE(MIME)@en[[[image/vnd.microsoft.icon]]]] は[[事業者木]]に属しています。
]EG]
;; [[木 (IETF)]]を参照。
[165] また [CODE[[[x-]]]] ではじまる[[部分型]]は、かつては[[私用]]のために予約されていました。
現在は特別な扱いはされておらず、 [CODE[[[x-]]]] から始まる[[部分型]]も
[[IANA登録簿]]に登録されています。
;; [[木 (IETF)]]をも参照。
* 構造化構文接尾辞
[68] [CODE(MIME)@en[[[image/svg+xml]]]] の [CODE(MIME)@en[[[+xml]]]] のように、
[[MIME型]]の末尾に [CODE[+]] と構文名がついているものは、その構文の一応用であることを表します。
この例では、 [[XML]] という構文に基づいた[[マーク付け言語]]の一種である [[SVG]]
ということを表しています。このようなものを[DFN[[RUBYB[[[構造化構文接尾辞]]]@en[structured syntax suffix]]]]といいます。
詳しくはそちらの項を参照してください。
* 引数
[192] [[MIME型]]には、0個[[以上]]の[[引数]]を指定できます [SRC[>>191]]。
;; [193] しかし[[MIME型]]を使う文脈によっては、[[引数]]を指定できないこともあります。
[67] [[引数]]は、個別の[[MIME型]]で規定されているものもあれば、
[[最上位型]]に属する[[MIME型]]全体で規定されるものもあります [SRC[>>191]]。
複数の [[MIME型]]で定義を共有しているものもあります。
すべての[[MIME型]]で共通して利用できる[[引数]]は、正式には存在しませんが、
現実には幾つかの[[引数]]が [[MIME型]]と独立に使われています。
;; [194] 本来の [[MIME]] の設計思想に従うなら、すべての [[MIME型]]に適用可能な[[引数]]は他の[[ヘッダー]]で記述するべきです。
[195] 全部または多数の [[MIME型]]で使われる[[引数]]には、次のものがあります。
[FIG(list short)[
- [CODE(MIME)@en[[[base64]]]]
- [CODE(MIME)@en[[[boundary]]]]
- [CODE(MIME)@en[[[capture]]]]
- [CODE(MIME)@en[[[charset]]]]
- [CODE(MIME)@en[[[charset-edition]]]]
- [CODE(MIME)@en[[[charset-extension]]]]
- [CODE(MIME)@en[[[codecs]]]]
- [CODE(MIME)@en[[[name]]]]
- [CODE(MIME)@en[[[odata[VAR[*]]]]]]
- [CODE(MIME)@en[[[profile]]]]
- [CODE(MIME)@en[[[q]]]]
- [CODE(MIME)@en[[[qs]]]]
- [CODE(MIME)@en[[[version]]]]
]FIG]
[85] [[引数名]]「[CODE(HTTP)@en[[[q]]]]」は[RUBYB[非推奨]@en[discouraged]]です [SRC[>>84]]。
本来は [CODE(HTTP)@en[[[Accept:]]]] [[ヘッダー]]など一部の場面で使われるもので、
[[MIME型]]ではなく[[ヘッダー]]側に属する構文です。
[2] [[OData]] は [[OData]] の実装に対して [CODE(MIME)@en[[[odata]]]]
から始まる ([[OData]] で規定されていない) [[引数]]の利用を禁止しています [SRC[>>1]]。
[197] [[標準木]]に登録する [[MIME型]]は、[[引数]]の名前と値と意味を完全に規定しなければ[['''なりません''']]。
[CODE[[[vnd.]]]] や [CODE[[[prs.]]]] の[[木]]に登録する [[MIME型]]は、
可能な限り規定する[['''べき''']]です。 [SRC[>>191]]
;; [202] なぜ[[木]]によって要求度が異なるのか謎です。 [CODE[[[vnd.]]]] や
[CODE[[[prs.]]]] の登録の敷居を下げるためかもしれませんが、
[[相互運用性]]に支障が出るのでは...
[200] [[引数]]の値の構文は、[[引数]]によります。[[MIME型]]を登録する際は規定しなければ[['''なりません''']] [SRC[>>191]]。
;; [201] プロトコルによっては[[バイナリー]]を値として指定できるかもしれませんが、
他のプロトコルでは使えないので、避けたほうが無難です [SRC[>>191]]。
[203] [[標準木]]の [[MIME型]]に対して新機能を追加する方法として新しい[[引数]]を定義する[['''べきではありません''']]。
既存の機能を変更せずに追加情報を与える新しい[[引数]]を定義するのは構いません。
[CODE[[[vnd.]]]] や [CODE[[[prs.]]]] の[[木]]においても同様とする[RUBYB[べき]@en[encourage]]ですが、必須ではありません。
[SRC[>>191]]
[EG[
[204] 例えば [[JPEG]] の改訂水準を表す [CODE[revision]] [[引数]]が挙げられます [SRC[>>191]]。
]EG]
;; [205] この規定の意図するところはあまりよくわかりません。
処理に影響を与えないなら、[[引数]]が存在する意義がない気がしますが...
改訂によってそのような機能を追加するべきではないということなのでしょうか。
[CODE(MIME)@en[[[text/plain]]]] に [CODE(MIME)@en[[[format]]]]
[[引数]]を後から追加したのは、かなり大きな変更のような気がしますが、
これは許されていいのですかねぇ。
[196] その他の個別の[[引数]]は、各[[MIME型]]や[[最上位型]]の項を参照してください。
[REFS[
- [1] [CITE[OData Version 4.0 Part 1: Protocol Plus Errata 01]] ([TIME[2014-09-04 16:00:00 +09:00]] 版) <http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html#_Toc393958670>
]REFS]
[220] 次の[[引数]]には[[自然言語]]文を記述できるようです。
[FIG(list short)[
- [CODE(MIME)@en[[[name]]]] ([CODE(MIME)@en[[[application/octet-stream]]]])
- [CODE(MIME)@en[[[padding]]]] ([CODE(MIME)@en[[[application/octet-stream]]]])
]FIG]
* 分類
[179] 次の [[MIME型]]の分類があります。
[FIG(short list)[
- [[XML MIME型]]
- [[composite type]]
- [[font type]]
]FIG]
* MIME 型の登録
[12] [[MIME]] は元々[[電子メール]]のための[[プロトコル]]であり、
[[相互運用性]]のために[[MIME型]]は限られた種類のみに限定することが好ましいと考えられていました
[SRC[>>35]]。そのため [[MIME型]]の [[IANA登録簿]]は用意されていましたが、
登録のハードルは高く設定されていました。
[44] しかし実際には既存の多くのファイル形式が[[添付ファイル]]や [[HTTP]]
でやり取りされるファイルなどの形で [[MIME]] および派生プロトコルの環境下で用いられるようになりました。
[[Windows]] や [[Linux]] 上の[[デスクトップ環境]]などでファイル形式を表す識別子
(の1つ) として [[MIME型]]が採用されたこともあり、ネットワーク上でやり取りされないファイル形式にも
[[MIME型]]が割り当てられるようになりました。
この結果、[[IANA登録簿]]に登録されていない [[MIME型]]が ([CODE[[[x-]]]] を使ったものも使わないものも含め)
相当数利用されることとなりました。
[96] 後に [[MIME型]]の登録手続きは緩和され、 [CODE[[[vnd.]]]] 木であれば比較的簡単に登録できるようになりました。
しかし既存の [[MIME型]]を [[IETF]] 側から積極的に [[IANA登録簿]]に登録しようとする動きはありません。
以前に比べれば [[IANA登録簿]]に登録される [[MIME型]]が多くなったとはいえ、
現実の利用状況と乖離しているという問題は解消されていません。
[163] 未登録の [[MIME型]]を使うべきではないと主張する人もいますが、
現実的ではありません。
[79] [[MIME型]]は、 [[BCP 13]] の手続きにより[[IANA]]に登録する[RUBYB[べき]@en[ought to]]です [SRC[>>71]]。
[167] [[MIME型]]として [[IANA登録簿]]に登録できるのは、
「[RUBYB[[[媒体]]書式]@en[media format]]」に限られます [SRC[>>166]]。
例えば [[Base64]] は[[内容転送符号化]]なので、 [[MIME型]]として登録することはできないとされています。
[168] この制約は [[MIME]] の仕組みに由来するもので、他の文脈には有用な区別ではないかもしれませんし、
曖昧です。これが[[IANA登録簿]]と現実が乖離する一因にもなっています。
[EG[
[169] [[gzip]] の [[MIME型]]は [[IANA登録簿]]に登録されておらず、色々な未登録の
[[MIME型]]が実際には使われています。(標準の[[MIME型]]が存在しないことが[[相互運用性]]の問題を引き起こしています。)
]EG]
[EG[
[189] 同様に[[アーカイブ]]系ファイル形式もほとんどが登録されていません。
[CODE(MIME)@en[[[application/zip]]]] は1993年と早い時期に登録されているものの、
非推奨であり [CODE(MIME)@en[[[multipart/mixed]]]] を使うべきとの記述があります。
もちろん今となっては頓珍漢で誰も相手にしないような記述です。
]EG]
[180] [[最上位型]]は、 [[IETF]] の手続きで追加することは可能 [SRC[>>170]] ながら、
新たなものが必要なことは稀である [SRC[>>170]] として比較的高いハードルが設定されており、
私用の仕組みも用意されていません。これまでに正式に追加されたのは
[CODE(MIME)@en[[[model/*]]]] だけです。
[181] その他にも幾つか提案はありましたが、却下または立ち消えとなっています。
実際にはやはり他の[[最上位型]]に馴染まない [[MIME型]]は存在するので、
非標準のものが使われたり、 [CODE(MIME)@en[[[application/*]]]]
に押し込まれたりしています。
[209] 登録された[[MIME型]]は削除できません [SRC[>>208]]。
[210] 登録された[[MIME型]]は[[廃止]] ([[OBSOLETE]]) 状態に変更することができます
[SRC[>>208]]。
;; [211] しかしこの[[廃止]]の意味は明確になっていません。[[廃止]]されているからといって、
それを利用してはならないとの明示的な規定は無さそうです。
[EG[
[213] 例えば [CODE(MIME)@en[[[text/javascript]]]] は[[廃止]]状態になっています。
しかし現実には [[JavaScript]] の[[MIME型]]として最も広く用いられている
[[MIME型]]なので、「[[廃止]]」とは一体どういう意味なのかは不明です。
]EG]
[212] なお他に状態らしきものとして非推奨 ([[DEPRECATED]]、
>>182 の Deprecated Alias とは別) や一時 (TEMPORARY) と注記されたものが
[[IANA登録簿]]上にありますが、これらが何を表しているのかは明確にはなっていません。
[[RFC]] にも言及がありません。
* MIME 型の構文に従わない型
[5] [[MIME型]]のように「型/部分型」の構文となっていない値が [[MIME型]]と同じ文脈で使われることがあります。
[6] [CODE(822)@en[[[Content-Type:]]]] [[ヘッダー]]を [[MIME]]
以前から定義していた [[RFC 1049]] は、 [CODE[[[/]]]] が入らない型を規定していました。
;; [[RFC1049とInternet媒体型の対応]]参照。
[7] [[Atom]] の [[Text construct]] および [CODE(XMLe)@en[[[atom:content]]]]
[[要素]]の [CODE(XMLa)@en[[[type]]]] [[属性]]では、 [[MIME型]]以外に特殊な意味を持つ
[CODE(XML)@en[[[text]]]]、[CODE(XML)@en[[[html]]]]、[CODE(XML)@en[[[xhtml]]]]
を指定できます。
[8] [[Metalink]] の [CODE(XMLe)@en[[[metaurl]]]] [[要素]]の [CODE(XMLa)@en[[[mediatype]]]]
[[属性]]には [[MIME型]]以外に [CODE(XML)@en[[[torrent]]]] を指定できます。
* パターン
[86] [[MIME型]]の集合を表す構文がいくつかあります。
[FIG(list)[
- [[媒体範囲]] ([CODE(HTTP)@en[[[Accept:]]]] [[ヘッダー]])
- [[HTML]] [CODE(HTMLa)@en[[[accept]]]] [[属性]]
]FIG]
* 文脈
[94] [[MIME型]]は色々なところで利用されています。
[FIG(short list)[
- [CODE(MIME)@en[[[Content-Type:]]]]
- [CODE(HTTP)@en[[[Accept:]]]]
- [CODE(HTTP)@en[[[Content-Style-Type:]]]]
- [CODE(HTTP)@en[[[Content-Script-Type:]]]]
- [CODE(HTMLa)@en[[[type]]]] [[属性]] ([[HTML]])
- [CODE(MIME)@en[[[type]]]] [[引数]] ([CODE(MIME)@en[[[application/vnd.pwg-multiplexed]]]])
- [CODE(HTMLa)@en[[[accept]]]]
- [CODE(HTMLa)@en[[[enctype]]]]
- [CODE(HTMLa)@en[[[srctype]]]]
- [CODE(XMLa)@en[[[contentStyleType]]]]
- [CODE(XMLa)@en[[[contentScriptType]]]]
- [CODE(DOMa)@en[[[contentType]]]]
- [CODE(DOMm)@en[[[overrideMimeType]]]]
- [CODE(URI)@en[[[data:]]]]
- [CODE(URI)@en[[[ct=]]]]
- [CODE(JS)@en[[[navigator.mimeTypes]]]]
]FIG]
[187] [[MIME型]]に関わる次のプロトコルがあります。
[FIG(short list)[
- [[MIME]]
- [[HTTP]]
- [[MIME Sniffing]]
- [CODE(HTTP)@en[[[X-Content-Type-Options:]]]]
- [CODE(HTMLa)@en[[[typemustmatch]]]]
- [[素片識別子]]
- [CODE(HTMLa)@en[[[language]]]] [[属性]]
]FIG]
* 他の識別子との関係
[206] [[MIME型]]の [[IANA登録簿]]は、[[拡張子]]や[[魔法数]]、
[[Mac OS File Type]] といった識別子を (あれば) 登録時に記述することを推奨しています。
[207] [[Apache]] や [[Windows]] をはじめ多くの [[MIME型]]の実装は、
[[ファイルシステム]]上の[[ファイル]]の [[MIME型]]を決定する際に[[ファイル名]]の[[拡張子]]を使っています。
;; ただし[[拡張子]]と [[MIME型]]の関係は多対多であり、確実に決定することはできません。
また[[拡張子]]がない [[MIME型]]や [[MIME型]]がない[[拡張子]]も珍しくありません。
* 歴史
[101] [[MIME型]]の前身となるものは [[RFC 1048]] で規定されていました。
後に [[MIME]] により現在の「型/部分型」の形に変更されました。
** RFC 1049
[81] [[RFC1049とInternet媒体型の対応]]参照。
** MIME
[REFS[
- RFC 1341 <urn:ietf:rfc:1341> (廃止)
- RFC 1437 <urn:ietf:rfc:1437> matter-transport/* 媒体型
- RFC 1521 <urn:ietf:rfc:1521> (廃止)
- RFC 2046 <urn:ietf:rfc:2046> 媒体型
- RFC 2077 <urn:ietf:rfc:2077> model/* 媒体型
- RFC 2376 <urn:ietf:rfc:2376> XML 媒体型 (廃止)
- RFC 3023 <urn:ietf:rfc:3023> XML 媒体型
- [30] [[IANA登録簿]] <http://www.iana.org/assignments/media-types/>
-- [132] [CITE[IANA | MIME Media Types]] ([TIME[2015-04-19 12:15:10 +09:00]] 版) <http://web.archive.org/web/20020805230715/http://www.iana.org/assignments/media-types/>
]REFS]
[103] [[MIME型]]の登録手続きは当初 [[RFC 1341]] [SRC[>>102]]、[[RFC 1521]] [SRC[>>106]] と
[[MIME]] 第1部の[[附属書]]で規定されていました。
[REFS[
- [106] [CITE@en[RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies]] ([TIME[2015-02-01 12:14:56 +09:00]] 版) <http://tools.ietf.org/html/rfc1341#page-52>
- [102] [CITE@en[RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies]] ([TIME[2015-02-01 12:14:56 +09:00]] 版) <http://tools.ietf.org/html/rfc1341#page-68>
- [107] [CITE@en[RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies]] ([TIME[2015-03-15 13:27:10 +09:00]] 版) <http://tools.ietf.org/html/rfc1521#page-55>
- [105] [CITE@en[RFC 1521 - MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies]] ([TIME[2015-03-15 13:27:10 +09:00]] 版) <http://tools.ietf.org/html/rfc1521#page-72>
]REFS]
[FIG(quote)[
[FIGCAPTION[
[90] RFC 2046 2. Definition of a Top-Level Media Type
]FIGCAPTION]
The definition of a top-level media type consists of:
上位媒体型の定義は次のものから構成されます。
[PRE[
(1) a name and a description of the type, including
criteria for whether a particular type would qualify
under that type,
]PRE]
(1) 型の名前と説明。特定の型をその型の下に置けるかどうかの適合基準
[PRE[
(2) the names and definitions of parameters, if any, which
are defined for all subtypes of that type (including
whether such parameters are required or optional),
]PRE]
(2) その型のすべての亜型用に定義するパラメーターがあればその名前と定義
(そのパラメーターが必須か省略可能かを含む)
[PRE[
(3) how a user agent and/or gateway should handle unknown
subtypes of this type,
]PRE]
(3) 利用者代理者や関門がその型の未知の亜型をどう取り扱うべきか
[PRE[
(4) general considerations on gatewaying entities of this
top-level type, if any, and
]PRE]
(4) 必要なら、この上位型の実体の関門通過に関しての考慮一般
[PRE[
(5) any restrictions on content-transfer-encodings for
entities of this top-level type.
]PRE]
(5) この上位型の実体の内容転送符号化の制限
]FIG]
[FIG(quote)[
[FIGCAPTION[
[91] RFC 2046 3. Overview Of The Initial Top-Level Media Types
]FIGCAPTION]
The five discrete top-level media types are:
5つの個々上位媒体型は次の通りです。
[PRE[
(1) text -- textual information. The subtype "plain" in
particular indicates plain text containing no
formatting commands or directives of any sort. Plain
text is intended to be displayed "as-is". No special
software is required to get the full meaning of the
text, aside from support for the indicated character
set. Other subtypes are to be used for enriched text in
forms where application software may enhance the
appearance of the text, but such software must not be
required in order to get the general idea of the
content. Possible subtypes of "text" thus include any
word processor format that can be read without
resorting to software that understands the format. In
particular, formats that employ embeddded binary
formatting information are not considered directly
readable. A very simple and portable subtype,
"richtext", was defined in RFC 1341, with a further
revision in RFC 1896 under the name "enriched".
]PRE]
(1) text —— 文字情報。亜型 "plain" は特に、いかなる類の書式化命令・指令
を含まない平文 (plain-text) を示します。平文は「そのまま」表示する
ことを意味します。文の完全な意味を得るのに、指定された文字集合への対応を
除いて特別なソフトウェアは必要ありません。他の亜型は応用ソフトウェアが
文の見た目をよくする裕福文に使われるかもしれませんが、内容の
一般的な着想を得るのにはこのようなソフトウェアは必須ではありません。
ですから "text" の亜型となりえるものにはその形式を理解するソフトウェア
無しに読むことが出来る言葉処理器 (ワード・プロセッサー) の形式を含みます。
特に、バイナリ書式付け情報を埋め込んだ形式は直接可読とは言えません。
とても単純で移植性ある亜型, "richtext" (裕福文) は RFC 1341
で定義されていましたが、 RFC 1896 で "enriched" (裕福化) という名前で
更に改訂されています。
訳注: embeddded は d が一個多い。
[PRE[
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial
subtype is defined for the widely-used image format
JPEG. . subtypes are defined for two widely-used image
formats, jpeg and gif.
]PRE]
(2) image ——画像データ。 "image" は情報を見るのに表示機器
(画像画面, 画像印刷機, FAX 機器など) が必要です。初期亜型としては
広く使われている画像形式 JPEG を定義します。。 亜型としては
2つの広く使われている画像形式, jpeg と gif を定義します。
(訳注: 誤植というか編集ミスというか。)
[PRE[
(3) audio -- audio data. "Audio" requires an audio output
device (such as a speaker or a telephone) to "display"
the contents. An initial subtype "basic" is defined in
this document.
]PRE]
(3) audio ——音声データ。 "audio" は音声出力機器 (スピーカーとか電話とか)
が内容を「表示」するのに必要です。初期亜型としては "basic"
をこの文書で定義します。
[PRE[
(4) video -- video data. "Video" requires the capability
to display moving images, typically including
specialized hardware and software. An initial subtype
"mpeg" is defined in this document.
]PRE]
(4) video 動画データ。 "video" は動く画像を表示する能力が必要です。
典型的には特別なハードウェアとソフトウェアを含みます。
初期亜型としては "mpeg" をこの文書で定義します。
[PRE[
(5) application -- some other kind of data, typically
either uninterpreted binary data or information to be
processed by an application. The subtype "octet-
stream" is to be used in the case of uninterpreted
binary data, in which case the simplest recommended
action is to offer to write the information into a file
for the user. The "PostScript" subtype is also defined
for the transport of PostScript material. Other
expected uses for "application" include spreadsheets,
data for mail-based scheduling systems, and languages
for "active" (computational) messaging, and word
processing formats that are not directly readable.
Note that security considerations may exist for some
types of application data, most notably
"application/PostScript" and any form of active
messaging. These issues are discussed later in this
document.
]PRE]
(5) appliaction 他の種類のデータ, 典型的には解釈出来ないバイナリ・データ
や応用により処理される情報です。亜型 "octet-stream" は解釈出来ない
バイナリ・データに使われ、この場合の最も簡単な推奨動作は情報を
ファイルに書き出すと利用者に申し出ることです。 "PostScript" 亜型も
PostScript 物体を転送するために定義します。他の "application"
で使うべきものには表計算, 基メイル予定系統, 「動的」(計算的)メッセージの言語,
直接可読でないワード・プロセッサーの形式があります。なお、
応用データの幾つかの型, とりわけ "application/PostScript" や動的
目セージの形式には安全性について考慮すべきことがあたりします。
この問題についてはこの文書の後の方で話します。
The two composite top-level media types are:
2つの合成上位媒体型は次の通りです。
[PRE[
(1) multipart -- data consisting of multiple entities of
independent data types. Four subtypes are initially
defined, including the basic "mixed" subtype specifying
a generic mixed set of parts, "alternative" for
representing the same data in multiple formats,
"parallel" for parts intended to be viewed
simultaneously, and "digest" for multipart entities in
which each part has a default type of "message/rfc822".
]PRE]
(1) multipart 複数の独立したデータ型の実体で構成されるデータ。
4つの亜型がはじめから定義されています。 "mixed" 亜型は
一般の混成の部分の集合を示し, "alternative" は同じデータを複数の形式で
表現していることを表し, "parallel" は同時に表示されることを意図した
部分を組み合わせたもので、 "digest" は各部分の既定値が "message/rfc822"
の多部分実体で構成されるものです。
[PRE[
(2) message -- an encapsulated message. A body of media
type "message" is itself all or a portion of some kind
of message object. Such objects may or may not in turn
contain other entities. The "rfc822" subtype is used
when the encapsulated content is itself an RFC 822
message. The "partial" subtype is defined for partial
RFC 822 messages, to permit the fragmented transmission
of bodies that are thought to be too large to be passed
through transport facilities in one piece. Another
subtype, "external-body", is defined for specifying
large bodies by reference to an external data source.
]PRE]
(2) message カプセル化メッセージ。媒体型 "message" の本文は
それ自体が何らかの種類のメッセージ物体の一部又は全部です。
この物体が今度は他の実体を含むかもしれませんし、含まないかもしれません。
"rfc822" 亜型はカプセル化内容が RFC 822 メッセージである時に使います。
"partial" 亜型は RFC 822 メッセージの一部用に定義するもので、
転送機能を一片でまとめて通過させるには大き過ぎると思われる
本文を断片化して送ることが出来ます。他の亜型, "external-body"
は外部データ源を使って大きな本文を示すのに定義します。
It should be noted that the list of media type values given here may
be augmented in time, via the mechanisms described above, and that
the set of subtypes is expected to grow substantially.
媒体型値は上述の機構でいつ増補されるかもしれませんし、
亜型の集合は本質的に増えて行くだろうことに注意して下さい。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[92] RFC 2046 6. Experimental Media Type Values
]FIGCAPTION]
[PRE[
A media type value beginning with the characters "X-" is a private
value, to be used by consenting systems by mutual agreement. Any
format without a rigorous and public definition must be named with an
"X-" prefix, and publicly specified values shall never begin with
"X-". (Older versions of the widely used Andrew system use the
"X-BE2" name, so new systems should probably choose a different name.)
]PRE]
文字 "X-" から始まる媒体型値は私用値で、相互の同意により同意系統で
使われます。厳密に公的に定義されていない形式は "X-" 接頭辞つきで
名前をつけなければなりませんし、公的規定値は "X-" で始めてはいけません。
(広く使われている Andrew の系統の古い版は "X-BE2" 名を使っていましたので、
新しい系統は違う名前を選ぶのがよろしいでしょう。)
[PRE[
In general, the use of "X-" top-level types is strongly discouraged.
Implementors should invent subtypes of the existing types whenever
possible. In many cases, a subtype of "application" will be more
appropriate than a new top-level type.
]PRE]
通常、 "X-" を上位型に使うのは強く非推奨です。実装者は出来る限り
既存の型の亜型をでっち上げるべきです。多くの場合、 "application"
の亜型にするのが新しい上位型にするのより適切です。
]FIG]
** HTTP および派生プロトコルでの扱い
[4] [[HTTP92]] は、[[電子メール]]とは違って [[HTTP]] では[[内容折衝]]が使えるので、
[[MIME]] にない[[媒体型]]も認めるべきだと述べていました [SRC[>>3]]。
[REFS[
- [3] [CITE[Object Header lines in HTTP]] ([TIME[2002-04-11 00:31:17 +09:00]] 版) <http://www.w3.org/Protocols/HTTP/Object_Headers.html#z16>
]REFS]
[FIG(quote)[
[FIGCAPTION[
[93] RFC 1945 (HTTP/1.0) 3.6; RFC 2068・2616 (HTTP/1.1) Media Types
]FIGCAPTION]
> HTTP uses Internet Media Types [DEL[[INS[{1945}]] [13] ]] [INS[[INS[{2616}]] [17] ]] in the Content-Type [DEL[[INS[{1945}]] header field]] ([DEL[[INS[{1945}]] Section 10.5]] [INS[section [DEL[[INS[{2068}]] 14.18]] [INS[[INS[{2616}]] 14.17]]]]) [INS[[INS[{2068,2616}]] and Accept (section 14.1) header fields]]
in order to provide open and extensible data typing [INS[[INS[{2068,2616}]] and type negotiation]].
[39] [[HTTP]] は Internet [[媒体型]]を Content-Type 頭欄と
Accept 頭欄において開放的で拡張可能なデータ型指定及びデータ型折衝のために使用します。
>
-media-type = type "/" subtype *( ";" parameter )
-type = token
-subtype = token
> Parameters [DEL[may]] [INS[[INS[{2616}]] MAY]] follow the type/subtype in the form of attribute/value pairs [INS[[INS[{2616}]] (as defined in section 3.6)]].
[40] 引数が型/亜型の後に属性/値の組の形で続いても'''構いません'''。
[DEL[
>[INS[{1925,2068}]]
-parameter = attribute "=" value
-attribute = token
-value = token | quoted-string
]DEL]
> The type, subtype, and parameter attribute names are case-insensitive. Parameter values [DEL[may]] [INS[[INS[{2616}]] might]] or [DEL[may]] [INS[might]] not be case-sensitive,
depending on the semantics of the parameter name. [DEL[[INS[{1945}]] LWS must not be generated]] [INS[Linear white space (LWS) MUST NOT be used]]
between the type and subtype, nor between an attribute and its value. [DEL[[DEL[[INS[{1945}]] Upon receipt of a media type with an unrecognized parameter, a user agent should treat the media type as if the unrecognized parameter and its value were not present.]] [INS[[INS[{2068}]] User agents that recognize the media-type MUST process (or arrange to be processed by any external applications used to process that type/subtype by the user agent) the parameters for that MIME type as described by that type/subtype definition to the and inform the user of any problems discovered.]]]] [INS[[INS[{2616}]] The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.]]
[41] 型, 亜型, 引数属性名は大文字と小文字を区別しません。
引数値は、引数名の意味によって、区別するかもしれませんし区別しないかもしれません。
型及び亜型の間ならびに属性及びその値の間には線形空白 ([[LWS]])
を入れては'''なりません'''。[DEL[[DEL[認識できない引数のある媒体型を受信した際は、その認識できない引数と値は現れていないものとして取扱うべきです。]] [INS[ある [CODE(ABNF)[media-type]] を認識する[[利用者エージェント]]は、その MIME 型の引数を型・亜型定義で記述されているように処理 (あるいは利用者エージェントが型・亜型を処理するのに使う外部応用に処理させるように調整) し、問題が見つかれば利用者に知らせなければ'''なりません'''。]]]] [INS[引数の有無は、媒体型登録簿中の定義によっては、媒体型の処理に意味を持つかもしれません。]]
> [INS[Note[DEL[:]] [INS[that]] some]] [DEL[[INS[{1945}]] Some]]
older HTTP applications do not recognize media type parameters. [INS[When sending data to older HTTP applications, implementations]] [DEL[[INS[{1945}]] HTTP/1.0 applications]] [DEL[[INS[{1945,2068}]] should]] [INS[SHOULD]] only use media type parameters when they are [DEL[[INS[{1945}]] necessary to define the content of a message]] [INS[required by that type/subtype definition]].
[42] 古い HTTP 応用には媒体型引数を認識しないものがあることに注意してください。
古い HTTP 応用にデータを送るときには、型・亜型定義が必須としている媒体型引数だけを使う'''べきです'''。
> Media-type values are registered with the Internet Assigned Number
Authority (IANA [DEL[[INS[{1945}]] [15] ]] [INS[[INS[{2616}]] [19] ]]).
The media type registration process is outlined in
RFC [DEL[[DEL[[DEL[1590 [13] [INS[{1945}]]]] [INS[2048 [17] [INS[{2068}]]]]]] [INS[1590 [17] [INS[{2616}]]]]]] [INS[2048 [17] [INS[{Errata}]]]].
Use of non-registered media types is discouraged.
[43] 媒体型値は Internet 割当番号事務局 (IANA)
で登録されます。媒体型登録過程は RFC 1590
にまとめられています。未登録の媒体型の使用は非推奨です。
**** 3.6.1; 3.6.7 Canonicalization and Text Defaults
→[CODE(WikiPage)[[[text/*//正規化]]]]
****3.6.2; 3.7.2 Multipart Types
→[CODE(WikiPage)[[[multipart/*]]]]
]FIG]
[FIG(quote)[
[FIGCAPTION[
[27] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 7.2.1 Type
]FIGCAPTION]
> When an [DEL[Entity-Body]] [INS[entity-body]] is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
メッセージに [CODE(ABNF)[[[entity-body]]]] が含まれているときには、
その[[本体]]のデータ型は頭欄 [CODE(HTTP)[[[Content-Type]]]] および
[CODE(HTTP)[[[Content-Encoding]]]] により決定します。
この2つの頭欄は2層順序付き符号化模型を定義します。
>
-entity-body := Content-Encoding( Content-Type( data ) )
> [DEL[A]] Content-Type specifies the media type of the underlying data. [DEL[A]]
Content-Encoding may be used to indicate any additional content
coding[INS[s]] applied to the [DEL[type]] [INS[data]], usually for the purpose of data
compression, that [DEL[is]] [INS[are]] a property of the [DEL[resource requested]] [INS[requested resource]]. [DEL[The default for the content encoding is none (i.e., the identity function).]] [INS[There is no default encoding.]]
[CODE(HTTP)[Content-Type]] はそのデータの[[媒体型]]を規定します。
[CODE(HTTP)[Content-Encoding]] は、そのデータに適用されている、
要求された[[資源]]の特性である追加の[[内容符号化]]
(通常はデータ圧縮目的。) を示すのに使うことができます。
既定の符号化はありません。
> Any [DEL[HTTP/1.0]] [INS[HTTP/1.1]] message containing an entity[INS[-]]body [DEL[should]] [INS[SHOULD]] include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type [DEL[header, as is the case for Simple-Response messages]] [INS[field]],
the recipient [DEL[may]] [INS[MAY]]
attempt to guess the media type via inspection of its content and/or the name
extension(s) of the [DEL[[INS[{1945,2068}]] URL]] [INS[[INS[{2616}]] URI]] used to identify the resource. If the media type remains unknown, the recipient [DEL[should]] [INS[SHOULD]]