何时使用 JavaScript MIME 类型 application/javascript 而不是 text/javascript？答案

【问题标题】：When to use the JavaScript MIME type application/javascript instead of text/javascript?何时使用 JavaScript MIME 类型 application/javascript 而不是 text/javascript？
【发布时间】：2011-05-05 07:45:17
【问题描述】：

基于问题jQuery code not working in IE，text/javascript 在 HTML 文档中使用，以便 Internet Explorer 可以理解。

但我想知道，你什么时候会使用application/javascript，更重要的是，你为什么要使用它而不是text/javascript？

【问题讨论】：

可能的欺骗/解释：stackoverflow.com/questions/876561/…
另见stackoverflow.com/questions/2325571/…
What is the Javascript MIME Type? What belongs in the type attribute of a script tag?的可能重复
When serving JavaScript files, is it better to use the application/javascript or application/x-javascript的可能重复

标签： javascript mime-types

【解决方案1】：

application 因为.js-文件不是用户想要阅读的东西，而是应该被执行的东西。

【讨论】：

这是官方答案，但 IE 卡住了。
@Benn：可能是因为IE用户没有正确执行而必须阅读所有的JS文件？至少，微软是诚实的；）
喜欢你的评论，但不幸的是，无法阅读 javascript 的人仍然使用 IE，所以我们必须处理它:(.
我不认为你是否想读它与为什么有任何关系。它与数据如何转码有关——或者更确切地说，它是否可以转码。
从技术上讲，HTML 和 CSS 也由浏览器“执行”（解析）以将代码的结果作为可视内容生成，而不是让用户“阅读”它，所以，这答案没有多大意义。我想关于什么是“文本”和什么是“应用程序”存在很大的混淆。如果我可以在这件事上投票，我会说 IETF 应该将“文本”内容视为text，并将binary 视为application - 或将所述类型的“目的”视为“图像”，或“文档”等

【解决方案2】：

Javascript 的 MIME 类型的问题在于多年来一直没有标准。现在我们将 application/javascript 作为官方 MIME 类型。

但实际上，MIME 类型根本不重要，因为浏览器可以自行确定类型。这就是 HTML5 规范声明不再需要 type="text/javascript" 的原因。

【讨论】：

【解决方案3】：

application/javascript 是正确使用的类型，但由于 IE6-8 不支持它，因此您将被 text/javascript 卡住。如果您不关心有效性（不包括 HTML5），那么就不要指定类型。

【讨论】：

你从哪里得到这个的？我很确定它是受支持的。或者，至少，它会被忽略。
@Zenexer 阅读 his answer to another question。貌似 IE 兼容意味着没有application/javascript。
@CamiloMartin 我在 IE 中一直使用它，直到 6 。它们只是默认为 JavaScript。
@Zenexer 嗯，奇怪。我想知道其他问答中有什么问题。
@Zenexer 我不得不处理这个问题已经有一段时间了，但是here are some other accounts of this causing issues 使用 IE6-8。不完全确定为什么这似乎只在某些时候很重要，但根据我的经验，它已经引起了问题。

【解决方案4】：

理论上，根据RFC 4329，application/javascript。

它应该是application 的原因与该类型是否可读或可执行无关。这是因为语言/类型本身制定了自定义字符集确定机制，而不仅仅是通用的charset 参数。 text 的子类型应该能够被代理转码为另一个字符集，从而更改字符集参数。这不适用于 JavaScript，因为：

一个。 RFC 说用户代理应该对脚本进行 BOM 嗅探以确定类型（我不确定是否有任何浏览器实际上这样做）；

b.浏览器使用其他信息（包括页面的编码以及在一些浏览器中的script charset 属性）来确定字符集。因此，任何试图对资源进行转码的代理都会破坏其用户。（当然实际上没有人使用转码代理，但这就是目的。）

因此，必须准确地保留文件的确切字节，这使其成为二进制application 类型，而不是技术上基于字符的text。

出于同样的原因，application/xml 正式优于 text/xml：XML 有自己的带内字符集信号机制。对于 XML，每个人都会忽略 application。

text/javascript 和 text/xml 可能不是官方的 Right Thing，但出于兼容性原因，今天每个人都在使用它们，而它们不是正确的东西的原因实际上完全不重要。

【讨论】：

最“兼容”的解决方案是根本不在响应中包含任何内容类型。 RFC 指出，如果没有明确的内容类型，接收者将 “按上下文” 对其进行解释，这对于所有浏览器来说始终是正确的行为，从最初的浏览器开始
小心application/javascript 和在与IE=8 兼容的模式下运行的IE。似乎内联脚本没有正确评估。 text/javascript 在那里工作正常。
@Pacerier - 我知道这条评论已有 5 年历史了，但如今出于安全原因，通常最好包含 mime 类型，尤其是对于论坛类型的网站。让接收者解释该类型，通过上传恶意 javascript 文件作为图像，然后让浏览器解释并运行该脚本，从而使人容易受到攻击。最好让服务器为所有响应返回 mime 类型，并使用标头 X-Content-Type-Options: nosniff 来防止浏览器解释类型。
@sammy_winter 我到处看到这样的警告，每次都畏缩。如果我允许用户上传内容，我可能会做更多的验证，而不是“哦，是的，png 文件的名称匹配正则表达式，我可以相信”，不是吗？如果不正确的标题成为“安全问题”，问题可能更深层次，你不觉得吗？这与隐藏 Server: nginx 或任何 nginx 发送的内容相同。好像任何能够找到漏洞的人都需要明确的标头才能知道您运行的是什么服务器......
WHATWG HTML 标准似乎不同意 IETF 关于应该使用哪种 MIME 类型。 html.spec.whatwg.org/#scriptingLanguages 但在实践中没关系，因为mimesniff.spec.whatwg.org/#javascript-mime-type