[14] Content-Type:
ヘッダーは、
対応するデータの型 (MIME型) を指定するものです。
[878] 現在用いられている Content-Type:
の仕組みは、はじめ
MIME で電子メールのために導入され、その後 HTTP
など色々なプロトコルでも採用されたものです。
[879] HTTP では、関連付けられた表現のMIME型を表します。
同じメッセージに payload body が含まれていれば、その MIME型です。
HEAD
メソッドに対する応答の時は、
GET
メソッドだったとしたら応答に含まれるであろう表現の
MIME型です。 >>877
[888] 実際に表現がメッセージに含まれる場合にはそのMIME型を表しますが、
HTTP HEAD
メソッドに対する応答では、
GET
だったなら返される表現の MIME型を表します。
[219] HTTP OPTIONS
要求に payload body を含める場合、
Content-Type:
ヘッダーを生成しなければなりません
>>218。
[41] WebDAV クライアントからの PUT
要求にあっては、新しい資源の Content-Type:
がわかっているなら、これを指定するべきです >>40。
[43] FCAST でも Content-Type:
HTTPヘッダーを使うことができます
>>42。
[22] Content-Type:
ヘッダーの値は、
MIME型です。引数を含めることもできます。 >>877
[881] 構文の子細は規格によって異なりますが、 おおむね次のように表せます。
Content-Type 欄 := "Content-Type" ":" Content-Type 欄本体
Content-Type 欄本体 := 媒体型
媒体型 := 型 "/" 亜型 *(";" 引数指定)
引数指定 := 引数名 "=" 引数値)
[23] 例えば MIME では、 >>881 の構文字句間に
LWS
を挿入できます。
型
・亜型
・引数名
の大文字・
小文字や引数指定
の順序は意味を持ちません。
HTTP は MIME とほぼ同じですが、
型
や引数値
の定義
(>>881 では省略しています。) に使われている
token
の定義が少々異なります。
[34] DAV:getcontentype
特性では、
Content-Type:
ヘッダーの OWS や BWS
を含めるべきではありません >>36。
[24] また、 MIME は RFC 2231 で改訂され、 実際に実体の頭部に出現する構文で >>22 よりも複雑な指定方法が使えるようになっています。 (長い引数値を電子メイルで使う場合の対策や言語指定を含める手段が用意されています。) しかし、 HTTP など MIME から派生したプロトコルにまでこの改訂が及ぶのかどうかは曖昧になっています。 (HTTP のように仕様書で構文を再定義している仕様は影響しないという説が有力です。)
text/plain; charset=US-ASCII
[48] 本体部分で Content-Type:
が指定されない場合、
text/plain; charset=US-ASCII
を表しています >>47。
[49] ただし multipart/digest
では
message/rfc822
を表しています >>47。
[882] HTTP においては、 payload body を含むメッセージを生成する送信者は、
含まれる表現の MIME型が分からない場合を除き、 Content-Type:
ヘッダーを生成するべきです >>877。
[883] HTTP においては、 Content-Type:
ヘッダーがなければ、受信者は MIME型が application/octet-stream
であるとみなしても構いませんし、 sniffing しても構いません。 >>877
[27] BEEP における MIME 実体で
Content-Type:
頭欄が省略された場合の既定値は
application/octet-stream
です。
RFC 3080 2.2
[21] 電子メイル (822) の
Content-Type:
欄の規定は RFC 1049
と MIME の2種類があります。両者の構文は全然違います。
同じメッセージに MIME-Version:
欄があれば
MIME によって解釈し、なければ RFC 1049
で解釈するのが正しいそうです。
(という話は仕様書には載っていなくて、ietf-822 かどこかでそう聞きました。)
(もっとも、構文が全然違うのでどちらの構文も扱えるようにするのは難しくありませんし、 古いメッセージを扱わないのであれば RFC 1049 の構文は無視しても良いかもしれません。)
[8] Content-Type:
欄には狭義の媒体型に加えて、
任意の個数の引数を指定できます。
引数は、名前と値の組からなります。値の解釈は名前に依存します。
そして引数の解釈は、(狭義の) 媒体型に依存します。
(引数は媒体型の属性であり、 Content-Type:
欄の属性ではありません。)
[11] 引数名は、大文字・小文字の区別なしで定義されています。
MIME など多くの規格では、頭欄に大文字・
小文字どちらで書いても同じ意味です。引数名として使用できる文字は、
規格によって異なります。 MIME と HTTP では共に
token
ですが、その token
の定義が両規格で異なります。現実に使われている文字は
token
で使える文字の共通集合の更に小さな部分集合です。
[18] 引数値では、大文字・小文字を区別するかどうかは 引数名 (正確には、媒体型と引数名) に依存します。 例えば、 text/plain の charset 引数では区別しませんが、 application/octet-stream の name では区別します。
MIME では、引数値は value
であり、
token
または quoted-string
として定義されていますから、
前者では引数名同様の文字種しか使えませんが、後者により
RFC 822 で使えるすべての
ASCII 文字が使えます。
それでも使える文字はわずかに限られますが、 RFC 2231
の方法で事実上あらゆる文字の指定が可能です。
HTTP でも token
と quoted-string
が使えますが、前述のように token
の定義は
MIME と異なりますし、 quoted-string
の定義も異なります。 RFC 2231
の方法は使用できないと一般には考えられています。
MIME・HTTP 以外の規格も token
と
quoted-string
が使えることが多いですが、
詳細はばらばらです。
[19] 引数は媒体型の定義と共に登録することになっています。
そのためか、電子メイルや MIME
の多くの他の字句
のような名前付けに関する規定がありません。
(x- で始まる引数名を私用してもよいという規定もありません。)
[16] >>8 の通り、引数は媒体型各々固有のものであるのが原則ですが、 必然的に、または間違いにより、 媒体型にかかわらず比較的共通に使われている引数が何種類か存在します。
引数名 | 説明 | 備考 |
charset | Charset | |
x-mac-creator | 作成プログラム識別子 (Macintosh) | |
x-mac-type | 型 (Macintosh) | |
name | ファイル名 | Content-Disposition の filename 引数を使用するべき |
x-unix-mode | アクセス権 (Un|x) |
[9] charset
引数は、 MIME
本体規格でも特別に定義されている引数です。 MIME
では text/*
で使うことを規定していますが、
他の媒体型でも同じ、または似た意味でよく使われます。
[18] name
引数は、古い MIME の規格で
application/octet-stream
などごく一部の媒体型に定義されていましたが、
任意の媒体型でファイル名を指定するためのものとして間違って実装されました。
現在の MIME には Content-Disposition:
欄に filename
引数があり、最近のほとんどの
UAはそちらに移行しています。
[10] x-unix-mode
は 0777
のように Un|x におけるファイルの permission
を指定するようです。 AppleMail
などが使用していることがわかっています。
x-mac-creator
と x-mac-type
は、 Macintosh のファイル・システムの属性を記述するようです。
application/applefile (>>1)
をご覧下さい。
これら3つの引数は、本来は Content-Disposition:
欄に入れたほうが良い情報かもしれません。
[28] Content-Disposition:
ヘッダーの
handling
引数は、 SIP において未対応の内容型が指定された時の処理を指定します。
handling
を参照。[45] FCAST の実装は、 Content-Type:
HTTP
ヘッダーに対応しなければなりません >>44。
[57] Content-Type:
ヘッダーで指定された値は
(computed MIME type に対して)
supplied MIME type と呼ばれ、
check-for-apache-bug flag と共に応答から
supplied MIME type detection algorithm で次のように決定されます >>58。
Content-Type
ヘッダーの値に設定します。[67] ファイルの場合はファイルシステムとプラットフォームの設定から決定される
MIME型になり、 check-for-apache-bug flag は設定されません。
data:
の場合 check-for-apache-bug flag は設定されません。
FTP の場合、仕様書には MIME型の指定があれば使う >>58
とありますが、実際には指定されることはないと思われます。ただし FTP over HTTP
の場合は HTTP の場合同様に扱うべきと思われます。
[68] 複数の Content-Type:
ヘッダーが指定された場合、
常に最後のものが使われます。最初のものが非構文解析可能MIME型で最後のものが非構文解析可能MIME型であっても、最後のものが採用され、
指定なしと扱われます。
[69] supplied MIME type と check-for-apache-bug flag は、算出MIME型の決定時に参照されます。
meta
要素から符号化を取り出す算法[855] HTML では meta
要素から符号化を取り出す算法が定義されており、
meta
要素の http-equiv
属性が
Content-Type
の時に文字符号化 (charset)
の値を取り出す時に使われます。
[857] 元々の HTTP の Content-Type:
欄の構文と HTML
の meta
要素の構文には細かな違いがあり、この算法は HTML
の構文に特化しています。
[1] 主に古い時代の HTTP UA において、パラメーターの存在を知らないためにうまく扱えないことがあります。
単に無視するだけならまだ良いのですが、中にはパラメーターも含めて一つの媒体型とみなし、例えば
text/html;charset=iso-2022-jp
という媒体型と認識し、保存しますか?
と聞いてきたりします。
[2] Mosaic variant にこういうのがいるみたいです。 古い Mosaic は対応していなかったんでしょうか? 同じ 1996年の Mosaic でも、 MosaicView (NEC) はちゃんと扱えるのに Infomosaic (富士通) は扱えなかったりします。
[3] ちなみに、古い NN (2以前) は charsetパラメーターの扱いにまた別の問題があります。
[15] 初め RFC 1049 が定義していましたが、これと互換性のない MIME が再定義した形式が普及し、 HTTP など他のプロトコルでも採用されています。
RFC 1049 の CT: は MIME の CT: とは互換性がありません。 また、 1049 の型の全てに対応する Internet (MIME) 媒体型が 定義されたわけでもありません。 幾ら RFC 1049 が実際にはあまり使われなかったとはいえ、 ひどい処遇です。
son-of-RFC1036 は RFC 1341 を参照していて、別途 CT: 領域を定義していません。 usefor-article もそうです。
HTTP の定義は RFC 2045 と同じ物ですが、 RFC 2231 の拡張に 追随していません。 CGI の定義は HTTP と同じです。
MIME//parameter値拡張 RFC 2184, RFC 2231 により Content-Type: 領域の parameter の定義などが 修訂されました。実際にはあまり実装されていません。
[25] XML で要素の内容として Base16 または
Base64 で含められたものの媒体型を記述するための
属性があります。取り得る値は RFC 2045 (MIME)
の xmlmime:contentType
Content-Type:
欄本体と同じです。
(特に注記がないから LFWS
も認められるのか!?)
Describing Media Content of Binary Data in XML http://www.w3.org/TR/2005/NOTE-xml-media-types-20050504/#contentType
[20] Microsoft Windows XP Service Pack 2 での機能の変更点 : ブラウズのセキュリティ強化 http://www.microsoft.com/japan/technet/prodtechnol/winxppro/maintain/sp2brows.mspx
WinIE の型判別の仕様が変更されたそうです。相変わらず Content-Type
以外の情報を使うようですが、以前より幾分ましにはなっている模様。
[26] Re: Approved TAG finding: Authoritative Metadata from Ian Hickson on 2006-08-09 (www-tag@w3.org from August 2006) http://lists.w3.org/Archives/Public/www-tag/2006Aug/0027
[29]
html5/cts/ (2007-09-22 11:17:46 +09:00
版) http://dev.w3.org/cvsweb/html5/cts/
(名無しさん)
[30]
プロフネット (2007-11-18 14:32:36 +09:00
版) http://prof.teacup.com/fprof/?p=fprof_guide
Content-Type: text/html; charset=Shift_JIS lang=ja
(名無しさん)
[32]
Bug 385166 – Gecko applies style sheets with Content-Type:"null" in standards mode (2008-01-07 19:33:34 +09:00
版) https://bugzilla.mozilla.org/show_bug.cgi?id=385166
[823] http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf
CONTENT_TYPE
(CGI)[824] CGI のメタ変数 CONTENT_TYPE
は、
メッセージ本体のMIME型を表します >>835。
HTTP などの Content-Type:
欄に相当します。
[832] メタ変数 CONTENT_TYPE
に値が設定される場合の構文は HTTP
の Content-Type:
頭欄の構文と同じです。
[837] RFC では構文は >>836 のように定義されています。これは RFC 2616 の HTTP の定義と一致しているのですが、 HTTP の RFC とは違って LWS の挿入箇所は明記されてません。
[840] CONTENT_TYPE
の既定値はありません。CGIスクリプトは値が設定されていない場合、
その場合に限ってMIME型を受信したデータから推測して構いません。それでも不明な場合にあっては
application/octet-stream
として扱っても構いませんし、誤りとしても構いません。
>>835
[842] 鯖は、 HTTP 要求に Content-Type:
欄が含まれている場合、
それを設定しなければなりません。
クライアントが指定しなかった場合は鯖が推定しても構いません。
そうでない場合は設定しないべきです。 >>835
[851] スクリプトは CONTENT_TYPE
が値を持たないときは 415
応答により拒絶することができます。 >>852
If the request includes a message-body, CONTENT_TYPE is set to the Internet Media Type [9] of the attached entity if the type was provided via a "Content-type" field in the request header, or if the server can determine it in the absence of a supplied "Content-type" field. The syntax is the same as for the HTTP "Content-Type" header field.
要求が message-body
を含んでいる場合、
CONTENT_TYPE
は、
要求頭部の Content-Type
欄によってインターネット媒体型が指定されていればそれに設定されます。
Content-Type
欄が明示されていない時で鯖がインターネット媒体型を決定できるときは、
それに設定されます。構文は HTTP の Content-Type
頭欄のものと同じです。
CONTENT_TYPE = "" | media-type media-type = type "/" subtype *( ";" parameter) type = token subtype = token parameter = attribute "=" value attribute = token value = token | quoted-string
The type, subtype, and parameter attribute names are not case-sensitive. Parameter values MAY be case sensitive. Media types and their use in HTTP are described in section 3.7 of the HTTP/1.1 specification [8].
型、部分型、引数属性名は大文字・小文字を区別しません。 引数値は大文字・小文字を区別するかもしれません。 HTTP における媒体型とその用法は HTTP/1.1 仕様書の3.7節で説明されています。
Example:
application/x-www-form-urlencoded
There is no default value for this variable. If and only if it is unset, then the script MAY attempt to determine the media type from the data received. If the type remains unknown, then the script MAY choose to either assume a content-type of application/octet-stream or reject the request with a 415 ("Unsupported Media Type") error. See section 7.2.1.3 for more information about returning error status values.
この変数の既定値はありません。この値が設定されていなければ、
また設定されていない場合に限り、スクリプトは受信データから
媒体型を決定しようとしても構いません]]。
それでも型が未知である時は、スクリプトは内容型を
application/octet-stream
と仮定するか、
415
(「未対応の媒体型」)
誤りによって要求を却下するのどちらかを選んで構いません。
誤り状態値の返却についての詳細は7.2.1.3節をご覧ください。
Servers MUST provide this metavariable to scripts if a "Content-Type" field was present in the original request header. If the server receives a request with an attached entity but no "Content-Type" header field, it MAY attempt to determine the correct datatype, or it MAY omit this metavariable when communicating the request information to the script.
鯖は、元々の要求頭部に Content-Type
頭欄が存在する場合、
このメタ変数を提供しなければなりません。
鯖は、添付実体があって Content-Type
頭欄がない要求を受信した場合、
正しいデータ型を決定しようと試みて構いませんし、
スクリプトに要求情報を伝える際にこのメタ変数を省いても構いません。
[825] CGIスクリプトは CONTENT_TYPE
を HTTP
仕様にのっとり正しく処理していないことがよくあります。具体的には、
CONTENT_TYPE
をチェックせずに常に
application/x-www-form-urlencoded
(など特定のMIME型)
であると仮定するLWS
が認められている場所で、 SP
1個だけなど特定のパターンのみ受け付ける... というような実装があります。
[830] Perl でよく使われる CGI.pm はMIME型が小文字で指定されていると仮定しています。
[843] application/x-www-form-urlencoded; charset=utf-8
のように引数が指定されていると正しく扱えない
CGIスクリプトも昔はよくありましたが、最近は一部のWebブラウザーが引数をつけるようになったため、
正しく扱えるものが多くなっています。
[831] HTTP 要求に含まれている頭欄は原則的にメタ変数 HTTP_*
として CGIスクリプトに渡されますが、 Content-Type
→
CONTENT_TYPE
は例外となっています。これは HTTP_*
が存在しなかった CGI/1.0 時代の仕様に由来します。
[10] HTTP では Content-Type:欄の既定値は text/plain; charset=iso-8859-1
なんだが、 CGI ではこの既定値は採用しないってことか。
Content-Type:
欄 (CGI)[844] CGI の Content-Type:
欄は、応答本体のMIME型を表します。
[846] この欄の構文は次のように定義されています >>845。
Content-Type = "Content-Type:" media-type NL
[847] media-type
の前には空白を挿入できます。 media-type
は >>832 で定義されています。
[848] CGI応答が応答本体を含む場合、 Content-Type:
欄は必須です。それが含まれていない場合、鯖はMIME型を勝手に推定するべきではありません。
指定されている場合であっても、 charset
引数を除き、
変更せずにクライアントに送信するべきです。 >>845
[849] 局所リダイレクト応答では Content-Type:
欄を指定できません。
[876] MIME型が Content-Type:
ヘッダーによって指定されていない場合や、
指定されていても特定の条件をみたす場合には、本体データのバイト列を検査して、
それによって MIME型を決定することがあります。これを MIME Sniffing
といいます。
document()
関数 (常に XML として解釈される)DAV:getcontenttype
特性 (WebDAV)[35] DAV:getcontenttype
特性は、
accept header なしで GET
した時に返されるである
Content-Type:
ヘッダーの値を表します
>>31。
[37] 鯖が自身でMIME型を割り当てるのであれば、保護特性となります >>31。
[38] COPY
や MOVE
でも特性の値を保持するべきです >>31。
[39] GET
に対する応答で Content-Type:
ヘッダーを返す WebDAV に従う資源は、この特性を定義しなければなりません
>>31。
[880] Content-Type:
によって記述されたMIME型は、
Content-Encoding:
によって指定された内容符号化が適用されている場合は、
それを復号した後のデータに関するものです >>877。
Transfer-Encoding:
によって指定された転送符号化が適用されている場合は、
それも復号した後に内容符号化を復号したデータに関するものです。
RFC 1049 に定義されていない型は IANA に登録申請できることになっていますが、 現在 IANA 登録簿でそれらしいものはありません。
「text」型が使われていたようです(CT:省略時の既定値)。 = text/plain
IETF のメイル・サーバー mailto:mailserv@ietf.org は、 未だに Content-Type: text のメッセージを返してきます。
古い ML の archive とかには、大量の text 型のがあったりします。 (そういうメッセージは Content-Length:欄を持ってたりもします。 RFC 1049 ではないかもしれません。)
「x-uuencode-apple-single」型。中身は uuencoded Macintosh binary (未対応読者への注釈つき)っぽい。
「x-be2」。古い版の Andrew System で使われていたと、 RFC 2046 だったかに 書いてありました。 Google で探してみると、古い archive から幾つか 実例が見つかります。 Andrew Mail System の古い版とやらもどっか 探したら出て来ますかね?
この他にも、幾つかの型が使われていたっぽい形跡はありますが、 まとまった文書は見当りません。
ちなみに RFC 2049 によりますと、 MIME の CT: 定義的に不正な 値は MIME 適合 UA は application/octet-stream媒体型として 取り扱います。
[866] 電子メイルで使われる Content-Type:欄の最新の定義は、 MIME RFCs の1つ目、 RFC2045 urn:ietf:rfc:2045 にあります。
[869] この定義は RFC 1521 の改訂版です。 (でもほとんど同じです。) RFC2231 で更に改訂されています。
[873] 電子メイルの MIME より厳格で、どこでも適当に comment とか WSP を 入れてはいけませぬ。
[885] Document
オブジェクトにおいては、
contentType
属性が Content-Type:
ヘッダーに相当します。
[886] 内容折衝においては、 Accept:
ヘッダーが期待する表現の
MIME型、すなわち Content-Type:
ヘッダーを指定します。
[887] HTML などのリンク系の属性にある type
属性は、リンク先の Content-Type
に相当するものですが、
ヒントであって、実際の資源のMIME型としては使われません。
[884] Content-Type: 欄やその値のことを、 CT と呼ぶこともあります。 但し MIME の文脈以外では普通通じませんし、 MIME な文脈でも最初に Content-Type (以下 CT) のように断っておかないと通じないかもしれません。
[833] Working Group Decision on ISSUE-125 charset-vs-quotes ( (Sam Ruby 著, 版)) http://lists.w3.org/Archives/Public/public-html/2011Mar/0304.html
[834] Apache HTTP Server Project ( ( 版)) http://httpd.apache.org/docs/1.3/misc/known_client_problems.html#content-type-persistence
[854] SOAP over Java Message Service 1.0 ( ( 版)) http://www.w3.org/TR/2012/REC-soapjms-20120216/#contentType
[862] RFC 4463 - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks ( ( 版)) http://tools.ietf.org/html/rfc4463#section-5.4.4
[863] RFC 4975 - The Message Session Relay Protocol (MSRP) ( ( 版)) http://tools.ietf.org/html/rfc4975#page-37
[864] RFC 6787 - Media Resource Control Protocol Version 2 (MRCPv2) ( ( 版)) http://tools.ietf.org/html/rfc6787#section-6.2.6
[865] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.4.2
[870] Content-Type: text/html; みたいなのがたまにありますが、厳密には間違いですね。 (名無しさん 2004-07-11 01:22:18 +00:00)
[871] >>870 spam に多い。 (名無しさん 2004-07-11 01:25:03 +00:00)
[889] Fix request and response's body story · 578768a · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/578768a0c40b673ed9ce3e23020115af15d6ac49
[890] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) http://tools.ietf.org/html/rfc7252#section-5.10.3
[894] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.4.2
[46] Bug 28391 – Investigate missing content-type for fetching stylesheets ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=28391
[53] Clarify package data algorithm for FormData (eehakkin著, ) https://github.com/whatwg/fetch/commit/e03ee6fc7f6234005a058d9784e95861b9a0a301
[54] Editorial: name mimeType variable consistently (annevk著, ) https://github.com/whatwg/fetch/commit/82c30aa94dc9efd6173d089e954d796d74f5c0f3
[55] Define MIME type extraction better (annevk著, ) https://github.com/whatwg/xhr/commit/f3377022d3f415280530f3cb03f8435955c869d6
[71] Define Content-Type manipulation in terms of MIME Sniffing (annevk著, ) https://github.com/whatwg/xhr/commit/edc6f8f16f58d201afb49e40ca166b8bc1ae74a3
[72] Define Content-Type manipulation in terms of MIME Sniffing by annevk · Pull Request #176 · whatwg/xhr () https://github.com/whatwg/xhr/pull/176
[73] Fix overrideMimeType() again (annevk著, ) https://github.com/whatwg/xhr/commit/121cee50b6f51215f046266642964b4c53a02a7c
[74] Editorial: rewrite send()'s body/content-type processing (domenic著, ) https://github.com/whatwg/xhr/commit/f47bbab42dabe1f52e5e9f1ed1fa6df06a6eb310
[75] Editorial: less-confusing content-type manipulation algorithm for send() · Issue #197 · whatwg/xhr () https://github.com/whatwg/xhr/issues/197
[76] Editorial: rewrite send()'s body/content-type processing by domenic · Pull Request #205 · whatwg/xhr () https://github.com/whatwg/xhr/pull/205
[77] Strengthen requirements on CORS-safelisted request-headers (annevk著, ) https://github.com/whatwg/fetch/commit/9288c8f85c809a0ac371be6843ad2cf4046ee35b
[78] Be strict on request's Content-Type (annevk著, ) https://github.com/whatwg/fetch/commit/e06e2613f9eef720d0df8640be793efca2af89bc
[79] Be strict on request's Content-Type by annevk · Pull Request #829 · whatwg/fetch () https://github.com/whatwg/fetch/pull/829
[81] Define the Content-Type header parser (annevk著, ) https://github.com/whatwg/fetch/commit/0b2bc05b2550dcbefe1321ea3e8026702514a798
[82] Define the Content-Type header parser (annevk著, ) https://github.com/whatwg/fetch/commit/0b2bc05b2550dcbefe1321ea3e8026702514a798
[83] Redesign "extract header values" and "extract header list values" · Issue #814 · whatwg/fetch () https://github.com/whatwg/fetch/issues/814
[84] "Extract a MIME type" algorithm should pick the first entry? · Issue #529 · whatwg/fetch () https://github.com/whatwg/fetch/issues/529
[85] Content-Type parsing (MIME type parsing) · Issue #30 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/30
[86] Define the Content-Type header parser by annevk · Pull Request #831 · whatwg/fetch () https://github.com/whatwg/fetch/pull/831
[87] チケット #47296: メールの文字コード指定 - スラド - OSDN, shibuyak, 登録: 2023-02-03 13:00, 最終更新: 2023-02-03 13:00, https://ja.osdn.net/projects/slashdotjp/ticket/47296
スラドの記事のメール受信を利用しています。時々文字化けが起こることがあり、調べてみた所、スラドから送られてくるメールの文字コード指定方法が間違っているため、メールアプリが正しくデコードできないことがあるということがわかりました。
Content-type: text/plain; charset="iso-2022-jp"
というヘッダが送られてきていますが、文字コード指定はクオートせず、
Content-type: text/plain; charset=iso-2022-jp
というのが正しいMIMEの記述です。 このため、メールアプリはこの文字コード指定を正しく解釈できず、本文を独自に文字コード判断することとなり、文面によってはたまにコードの判断を誤ることがあるようです。
[88] これは仕様書が曖昧でちょっと解釈論的には厄介なのだが、 どちらも正しいと解釈されるべきもので、これが原因で文字化けするとしたらその MUA が壊れている。
name
引数でファイル名を指定しているようです。