[1] text/javascript
は、
JavaScript の MIME型です。
[25] JavaScript の MIME型はいろいろありますが、そのうち、
text/javascript
を常に使うべきです。
[88] script
要素については type
属性の項を参照。
[87] サーバーは、 JavaScript に text/javascript
を使うべきです。それ以外の JavaScript MIME型を使うべきではなく、
その他の MIME型を使ってはなりません。 >>37
[60] 長らくこのことを明確に規定した仕様書は存在していませんでした。
HTML Standard は 「RFC 4329 は text/javascript
を廃止しているが、実際には最も良く用いられる MIME型なので、
本仕様書では text/javascript
を用いる」
>>61
としています。 (仕様書内で使うと述べるだけで著者にそれを要求していなかったのは、
JavaScript の仕様書が規定するべきで HTML が規定するべきではないとの立場なのでしょうか。)
[38] JavaScript MIME型は、次のものです >>37。 いずれも JavaScript を表します >>37。
[33] JavaScript に関してこれ以外のMIME型に対応してはなりません >>37。
[28] 利用者エージェントは、 script
要素の処理でこの JavaScript MIME型 すべてを認識しなければなりません >>37。
script
要素の type
属性や language
属性の値の解釈に関する規定です
(スクリプトの媒体型も参照)。外部スクリプトの HTTPヘッダー
Content-Type:
のMIME型は、原則として無視されます。
(X-Content-Type-Options: nosniff
ヘッダーが指定された場合には、
JavaScript MIME型かどうかの検査も行われます。)[29] JavaScript の MIME型がこうも増殖してしまったのは、 数々の歴史的不幸が重なったためです。
script
要素のスクリプト言語は
language
属性で判別することとなっており、
これは MIME型ではありませんでした。それが後に W3C で標準化された際、
スクリプト言語の識別には MIME型を使うのが政治的に正しいと考えられたため、
広く普及していた language
属性を非推奨とし、
新たに type
属性を導入しました。
仕様書が求めていたわけではありませんが、実装によっては (後に HTML5 により標準化)、
type
属性が存在しないとき、
language
属性の値の前に
text/
をつけた MIME型が指定されたものとみなすこととしました。
そのため language
属性値のバリエーションが
MIME型のバリエーションとなりました。x-
を付けさせる方針を採っていました。 MIME
に関する知識がある人達は、 x-
のない MIME型を使うことを忌避し、
x-
をつけた値を使うようにしました。そのため x-
付きと x-
なしのバリエーションが生まれました。text/*
をプログラミング言語に用いるべきではないとの
IETF の神話があり、 application/*
を使うのが好ましいと考え、実践する人達がいました。そのため
text/
と application/
のバリエーションが生まれました。language
属性や type
属性の値で区別していました。この区別はあまり有効に機能せず、
00年代までに廃止されていますが、それまでに色々な値が生まれました。
改版のたびに MIME型が増殖するのはけしからんと version
属性や e4x
属性が作られたりもしました
(いずれも現在は使われていません)。language
属性しかなかったためか、
Netscape は JavaScript の公式な MIME型を明確に定めませんでした。application/x-javascript
を採用していましたが、 Netscape も開発に参加していた W3C
の HTML4 は text/javascript
を採用しました。
その W3C も SVG では text/ecmascript
を採用しました。text/javascript
を >>65 より廃止扱いにしました。
一般世間はほとんど無視しましたが、一部の仕様書を尊重する人達がそれに従い、
かえって混乱の種を蒔くこととなりました。script
要素から参照されている URL
にアクセスしたとき応答で指定される MIME型は、
JavaScript (または language
属性で指定された他のスクリプト言語)
であることが明白であり、Webブラウザーはその検査を行いませんでした。
鶏が先か卵が先か、MIME型を正しく設定しないサーバーも多く、
Web互換性のため今でもこの検査を完全には行えていません。[91] 他に Node.js のモジュール用の MIME型として
application/node
があります。
[40] W3C HTML の仕様書に登場しますし、実際にもかなり使われています。
IANAREG には登録されていません。
application/javascript 媒体型 に対応します。 (See also text/*媒体型に対応するapplication/*媒体型)
charset | mime.charset | 省略可 | MIME・[ID] (See charsetパラメーター) |
version | 省略可 | [ID] |
[109] RFC 4329 は JavaScript (非ECMAScript) のMIME型としつつ、 廃止としていました >>110。
[111] 一部の好事家を除き、完全に無視されていました。
[145]
RFC 9239
は、
HTML Standard
が
text/javascript
を採用したことを理由に、
廃止処分を撤回しました。
>>107
[39] SVG 1.0 が初見です [ID]。 ECMAScript (ECMA 262) は ECMA によって標準化された JavaScript です。
[117] RFC 4329 は ECMAScript のMIME型としつつ、 廃止としていました >>110。
[151] RFC 9239 は、 廃止された ECMAScript 系 MIME型の代表をこれとしました。 >>107
[115] WinIE は JScript として解釈します。
charset | mime.charset | 省略可 | MIME・[ID] (See charsetパラメーター) |
version | 省略可 | [ID] |
text/x-ecmascript
[41] Microsoft の JScript (JavaScript の亜種) に使われることがある媒体型です。 IANAREG には登録されていません。
IE が解釈出来ます。 (名無しさん 2004-03-17 00:38:07 +00:00)
[130]
RFC 4329
は
text/jscript
に言及していました。
非推奨としていました。
>>110
[149]
RFC 9239
は、
text/javascript
の非推奨の別名に改めて IANAREG
に登録しました。
>>107
[23] application/x-ms-jscript
というのを見ました。 WinIE が解釈できるのかは不明。
(名無しさん 2004-03-20 03:54:55 +00:00)
[24] LiveScript は JavaScript の古称です。 受信側実装で対応しているものがありますが、実際に使用している文書や送信側実装があるのかはわかりません。 IANAREG には登録されていません。
[42] Netscape Navigator が解釈できるようです。
[43] >>42 手元にある NN では確認出来ません。 ScriptTest 参照。
[132]
RFC 4329
は
text/x-javascript
に言及していました。
非推奨としていました。
>>110
[146]
RFC 9239
は言及していますが、なぜか
text/javascript
の別名にはしていません。
>>107
[44] 実際に幾らか使用されているようです。
[45] text/javascript に対応する媒体型です。 text/*媒体型, application/*媒体型の定義からすると、 application/javascript の方を使うべきですが、旧来の実装は text/javascript にしか対応していないものが少なくないですから、 application/javascript は LIMITED USE とされています [ID]。
[113] RFC 4329 が JavaScript (非 ECMAScript) の MIME型として規定していました >>110。
[146]
RFC 9239
は、
text/javascript
の非推奨の別名に改めて IANAREG
に登録しました。
>>107
charset | mime.charset | 省略可 | MIME・[ID] (See charsetパラメーター) |
version | 省略可 | [ID] |
[48] 受信側実装で対応している ものがありますが、実際に使用している文書や送信側実装が あるのかはわかりません。
[49] Apache HTTP server などが使用しています。 application/javascript と同義であり、そう扱うよう [ID] は要請しています。
[51] Mozilla のソースでは application/x-javascript
が主流で、 text/javascript
もよく使われています
[22] VRML では JavaScript の媒体型は
application/x-javascript
と規定しています。
>>26
[128] 次の種類が確認されています。
[129]
RFC 4329
は
text/javascript1.0
,
text/javascript1.1
,
text/javascript1.2
,
text/javascript1.3
,
text/javascript1.4
,
text/javascript1.5
に言及していました。
非推奨としていました。
>>110
[148]
RFC 9239
は、
text/javascript
の非推奨の別名に改めて IANAREG
に登録しました。
>>107
[15] text/javascript
では、
少なくても2つの引数が知られています。
名前 | 値 | 既定値 | 意味 |
charset | charset | (プロトコル依存) | 文字コード |
version | 不明 (1*DIGIT "." 1*DIGIT か?) | (実装依存) | JavaScript の版 |
e4x |
[17] きちんと定義した仕様が無いので、 未知の引数・引数値に遭遇した時の実装の振舞いは予測不能です。
実装によっては、引数の存在自体や引数の順序、 引数指定内での空白の挿入・引数名や引数値の大文字・小文字などで不具合が生じる虞もあります。
[18]
version
引数は多くの実装では無くても実装している適当な版で処理されますから、
どうしても必要でなければ省略するのがよいと考えられます。
charset
引数は、他の媒体型やプロトコルとの関係により、
たとえば MIME や HTTP では必ず指定し、
HTML では指定しないのがよいと思われます。
その他の引数はできれば指定しないのがよいでしょう。
charset
引数[21] JavaScript または ECMAScript の版を書きます。 どういう値を取るのかや既定値は規定されていません [ID]。
[53] Mozilla 1.3a で確認したところ、値が
"1".("0"/../"5")
なら script が実行されます。
[54] >>53 text/javascript
と application/x-javascript
での話。
[137]
RFC 4329
は、
application/ecmascript
に
version
が指定された場合、指定されていない場合と同じように処理してはならないとしていました。
>>110
[138] その規定に従った実装が実在したかは不明です。
[139] JavaScript 2.0 (ES4) のような将来の非互換変更を含んだ ECMAScript 仕様への対応のための布石という意味合いがあったものと推測されます。
[105]
Node.js
ではモジュールに
application/node
を使っています。
[144]
RFC 9239
は
text/javascript
等の MIME型でモジュールも使うことができる
(古典スクリプトと MIME型では区別できない)
としていました。
>>107
[16] HTML の script
要素で使用してみる例:
<script type="text/javascript" src="script.js"/>
版引数つきの例:
<script type="text/javascript; version=1.3" src="script.js"/>
[19] HTTP や MIME の実体として JavaScript を送る例:
Content-Type: text/javascript; charset=iso-2022-jp Content-Disposition: attachment; filename=script.js var i = 0;
[20] .htaccess
で接尾辞 .js
と text/javascript
を関連付ける例:
AddType text/javascript .js
text/javascript
[10] (要調査: text/javascript
の初出は HTML 3 Scripting draft または HTML 4 draft でしょうか。)
[14] JavaScript 関連の媒体型を遅ればせながら IANAREG に登録するための Internet Draft も書かれましたが、 残念ながら成立にはいたっていません。
(TODO: I-D の名前は?)
[8] JavaScript 系の媒体型を一挙に登録する試みも上手く行かなかったみたいだし、このまま非標準の歴史的媒体型名としてゆくゆくは消えるんだろうか?
[9] まあ当分は生き残り続けると思われるけど。
[11] text/javascript
は、しばしば望ましくないとされます。
[12] そもそも JavaScript を使うなどけしからん: JavaScript は Web の可接性やしばしば可用性を損なうので使用するべきではないとの意見があります。 しかし、 JavaScript を使うかどうかと、使う時にどういう名前でラベル付けするかは別の次元の問題です。
[2] IANAREG (媒体型に関する IANA 登録簿) に登録されていない:
text/javascript
は現時点で IANAREG
に登録されていません。媒体型を使う幾つかの規格は IANA
に登録されていない型の使用を認めていません。
[3] しかしながら、 >>2 だけを理由に text/javascript
を使うのはよくないと言う人は、もっとよく勉強するべきだと言わざるを得ません。 Web の幾つかの規格では、 IANA 登録名の使用が強制されていません。
[4] >>3 これは HTTP が出来た時に、 HTTP 通信で使われる媒体型指定はサーバーとクライアントの折衝の結果であって世界的に一意である必要はないと考えられていたことによります。 (この考えが現在でも通用するかはちょっと疑問です。それに、違う識別子を使うよりは同じ識別子を使う方が相互運用性が向上することは確かです。)
[5] しかしまあ、 MIME で使うときには登録しないといけないのでして。 (でも結局登録しようという I-D は expire されちゃったしねぇ。)
[6] とまれ、 HTML 4 で使うことは何も問題ないでしょう。 HTML 4 の仕様書の例に出てくるくらいですから。
[13] text/*
を使うのは不適切である:
text/*
は予備知識がなくても大意が掴める文に使うと定義されているので、
ほとんどすべての場合において JavaScript に
text/javascript
という名前を充てるのは不適当です。
ウェブでは歴史的に text/*
を plain text base の諸形式の媒体型として濫用してきました。
text/javascript
もその一つです。
[7] >>2,>>13 の問題から最近は application/x-javascript
が使われることが多くなってますし、そっちの方がよさげではあります。
application/javascript
,
ECMAScript 用の application/ecmascript
を正規のものとし、text/javascript
,
ECMAScript 用の text/ecmascript
を廃止として、[123] RFC 4329 はそれまでの JavaScript 関係の MIME型を巡る混乱を俯瞰し、 IETF における MIME型の標準化の方向性とも整合性を付けながら適切な方向へど誘導することを目指したものでした。
[124] 既存標準規格に対する深い知識を背景に現実と規格を融和させ進展させようとする、 著者 Bjoern Hoehrmann らしい当時としては優れたWeb標準仕様だったといえます。
[125]
しかし RFC 化に時間がかかったこともあったでしょうし、
Webブラウザー業界や Webサーバー業界、
サーバー運営者や著者、
核種関連規格といった莫大な数の利害関係者に影響力を与えるのが難しいこともあったのでしょう。
text/*
から application/*
に移行させようとする
IETF の方針
[126] 当時としては先進的だったとはいえ、 HTML5 を経た現在のWeb標準化の考え方から見れば、 現実世界の実情を軽視しており、 誰も相手にしていない過去の規格との整合性の方を優先させた、 机上の空論から脱出しきれていないものでしかなかった、 と辛辣に評価せざるを得ません。
[127] だとしても、技術的には後世への影響をほぼ与えていないとはいえ、 RFC 4329 は HTML5 のスクリプト関連の規定の前段階というべきものです。 HTML5 がこの点に関して現実的な路線を選べたのは、 RFC 4329 (とそれに至る I-D) の開発過程と失敗という経緯があってのことです。 より広くみれば、 現実と規格が一致しないときの折り合いの付け方の試行錯誤という点まで含めて、 標準技術開発史において重要な位置にあるといえます。
[136]
RFC 4329 は E4X や将来の JavaScript は範囲外としていました。
E4X とは当時一部で実装されていた e4x
引数を想定していたものです。
JavaScript の将来の版とは当時開発中だった (そして頓挫した)
JavaScript 2.0 を想定していたものです。
どちらも構文その他に多くの (場合によっては非互換な)
変更が含まれ得るものでした。
[55] 2002-11-16 (土) 16:32 名無しさん: 色々使われてて嫌ですね... Netscape が最初に決めておくべきだった。
[56] Mozilla 1.3a は text/javascript
や application/x-javascript
に対応しています。
# 03:39] <Philip`> Hixie: "the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type." - most commonly used where? http://canvex.lazyilluminati.com/misc/stats/scripttypes2.html says the HTTP Content-Type 1.5 years ago was almost always "application/x-javascript" instead
[03:45] <Hixie> hm, most commonly used isn't what i meant
[03:45] <Hixie> most recognisable, maybe?
[03:46] <Hixie> it's most commonly used in <script type="">, i think
[03:46] <Hixie> but i haven't checked recently
[03:47] <Philip`> http://canvex.lazyilluminati.com/misc/stats/scripts2.html - it was the most common <script type> by far
[03:51] <Hixie> ok
[03:51] <Hixie> then i'll claim that's what i meant :-P
[03:51] <Hixie> after all, i don't think i talk about the HTTP type anywhere
Script
Content-Type
values (total count)
application/x-javascript 2954 (81.5%) text/html 229 (6.3%) text/javascript 123 (3.4%)
script
type
values (total count)
text/javascript 31761 (53.8%) [missing] 25676 (43.5%) text/JavaScript 1339 (2.3%)
script
language
values (total count)
[missing] 27315 (46.3%) JavaScript 18198 (30.9%) javascript 6689 (11.3%) JavaScript1.2 2569 (4.4%) JavaScript1.1 1559 (2.6%) Javascript 1077 (1.8%) javascript1.2 513 (0.9%)
[58] application/x-ms-jscript
があります。
[47] Give JavaScript MIME types a <dfn> to refer to · whatwg/html@8d7fe57 ( 版) https://github.com/whatwg/html/commit/8d7fe572bca136e1397ab8fae57db791fbf8ec13
[34] Reference JavaScript MIME type now the HTML Standard defines it · whatwg/fetch@80540f2 ( 版) https://github.com/whatwg/fetch/commit/80540f2b891b4d9301c60c5e1e216f40be3d6b80
[35] JSの MIME-Type は text か application か、x- は必要か – カラクリ.jp (更新日2015年11月15日版) http://xn--lcki7of.jp/153/
[36] IETF が現実に合わない RFC を長年放置しているせいで、 >>35 のような混乱させられている記事が未だに執筆されたりしています。
[70] Add <script type="module"> and module resolution/fetching/evaluation · whatwg/html@cd1a9fb ( 版) https://github.com/whatwg/html/commit/cd1a9fb1e83f7d0bc30be8b34ecdaf444a0b19a4
[72] Add `application/javascript+module` mime to remove ambiguity · Issue #322 · tc39/ecma262 () https://github.com/tc39/ecma262/issues/322
[73] clarify the exact MIME for .mjs by bmeck · Pull Request #61 · nodejs/node-eps () https://github.com/nodejs/node-eps/pull/61
[74] On ES.next features prototype implementations in web browsers () https://mail.mozilla.org/pipermail/es-discuss/2011-August/016267.html
[75] draft-bfarias-javascript-mjs-00 - EMCAScript Media Types Updates () https://tools.ietf.org/html/draft-bfarias-javascript-mjs-00
[76] [Json] Add Extension to JS MIME () https://www.ietf.org/mail-archive/web/json/current/msg04202.html
[77] Re: [Json] Add Extension to JS MIME () https://www.ietf.org/mail-archive/web/json/current/msg04209.html
[78] Re: [Json] Add Extension to JS MIME () https://www.ietf.org/mail-archive/web/json/current/msg04211.html
[79] I-D/javascript-mjs at master · bmeck/I-D () https://github.com/bmeck/I-D/tree/master/javascript-mjs
[80] Re: [Json] Add Extension to JS MIME () https://www.ietf.org/mail-archive/web/json/current/msg04212.html
[81] [Json] ECMAScript Media Types Updates Work () https://www.ietf.org/mail-archive/web/json/current/msg04214.html
[82] Register some more JavaScript MIME types · Issue #2 · bmeck/I-D () https://github.com/bmeck/I-D/issues/2
[83] Clarify prose around JavaScript MIME types (annevk著, ) https://github.com/whatwg/html/commit/470e168aaddc54e0abcfa302639870c299473c99
[84] Clarify "Scripting languages" · Issue #2301 · whatwg/html () https://github.com/whatwg/html/issues/2301
[85] Simplify and clarify prose around JavaScript MIME types by annevk · Pull Request #3045 · whatwg/html () https://github.com/whatwg/html/pull/3045
[86] Require servers to use text/javascript for JavaScript (annevk著, ) https://github.com/whatwg/html/commit/d6b4a00acb47dfb0bf93285e4def7b89227929d2
[89] Register some more JavaScript MIME types · Issue #2 · bmeck/I-D () https://github.com/bmeck/I-D/issues/2
[90] Require servers to use text/javascript by annevk · Pull Request #3096 · whatwg/html () https://github.com/whatwg/html/pull/3096
[95] Move JavaScript and JSON MIME types from HTML (domenic著, ) https://github.com/whatwg/mimesniff/commit/2ca219fd45c764267d37506d989c77751c171e59
[96] Move JavaScript and JSON MIME types from HTML by domenic · Pull Request #58 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/pull/58
[97] Editorial: update usage of the MIME Sniffing Standard (domenic著, ) https://github.com/whatwg/html/commit/fc82f4f8774a2e7e80f6c9477bd881f6c783b186
[98] Editorial: update usage of the MIME Sniffing Standard by domenic · Pull Request #3455 · whatwg/html () https://github.com/whatwg/html/pull/3455
[99] Updated JS MIMEs under 2 week review from IETF · Issue #102 · whatwg/meta () https://github.com/whatwg/meta/issues/102
[100] dispatch () https://mailarchive.ietf.org/arch/browse/dispatch/?gbt=1&index=X3aBzTbPFT8bJRAYcO7ldjJmAls
[101] All `text` JavaScript types are deprecated according to RFC 4329 · Issue #76 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/issues/76
[102] Error in Section 4. Registration · Issue #21 · bmeck/I-D () https://github.com/bmeck/I-D/issues/21
[103] Enforce strict MIME type checks for worker-imported scripts (mikewest著, ) https://github.com/whatwg/html/commit/d1c3679934f52450666750464effb97e14f555e0
[104] Nosniffing for Worker Scripts · Issue #3255 · whatwg/html () https://github.com/whatwg/html/issues/3255
[107] RFC 9239: Updates to ECMAScript Media Types, Matthew A. Miller, May 2022, https://www.rfc-editor.org/rfc/rfc9239
[108] 、 RFC Editor は情報提供RFC RFC 9239 を発行しました。 これによって RFC 4329 は廃止されました >>107。
[140] 現実に合わない RFC 4329 の規定はすべて削除されて、 おおむね実情に合う形のものに置き換えられました。 ただし IETF 外で開発されたものに由来し IETF の best practice には反している、不適切であるが例外的に認めるものである、 という旨の注意書きがそこかしこに挿入されていて、 失敗を素直に認めきれない IETF の姿勢が現れています。
[141] ともかくこの RFC の出版によって形式的に残存していた JavaScript 処理に関する矛盾した規定は消失しました。
[142] 標準仕様の関係性としての形式的な地位はこれが新しい「現行」規格 (の1つ) でありますが、 実効的には ECMA-262 と HTML Standard (および Fetch Standard, Encoding Standard, MIME Sniffing Standard) に必要十分な規定がすべて揃っているので、 IETF の JavaScript 仕様に対する影響力が完全に消滅した形となります。
scripting_language
欄の値がjavascript
なら、 JavaScript MIME型です。