是否存在应用程序/javascript（作为 Javascript 的 MIME 类型）不起作用的情况？答案

【问题标题】：Is there any case where application/javascript (as a MIME type for Javascript) won't work?是否存在应用程序/javascript（作为 Javascript 的 MIME 类型）不起作用的情况？
【发布时间】：2016-10-19 14:53:32
【问题描述】：

问题是 text/javascript 全面工作，但 application/[x-]javascript 正确。有什么理由不使用 text/javascript？

背景：

我发现了一个有趣的极端情况，Chrome 将拒绝执行作为 application/x-javascript 传递的 Javascript 或作为 utf-8 编码数据 url 传递的 application/javascript（所以 data:application/x-javascript;charset= utf-8,...)

具体来说，Chrome 允许：

data:text/javascript; charset=utf-8,....
data:application/javascript; charset=utf-8;base64,....
data:application/x-javascript; charset=utf-8;base64,.....

但是会爆炸：

data:application/x-javascript; charset=utf-8,.....
data:application/javascript; charset=utf-8,.....

根据谷歌搜索，似乎 RFC 4329 将 application/javascript 作为标准，并且在这种情况下有效，但（现已弃用的）text/javascript 也是如此。

追查 RFC2397、RFC2045、RFC2046 并没有给出明确的答案。

【问题讨论】：

相关：Difference between application/x-javascript and text/javascript content types
是的，我看到了，我知道 RFC 中记录了什么，但我也知道 text/javascript 在任何地方都可以使用，有些东西不遵守 RFC。如果没有重要的例子，那么我会做“正确的事情”，但不会崩溃 > 正确性。
我注意到在链接的答案中，评论指出 application/javascript 将导致 SVN 将您的文件视为二进制文件。（但我只关心浏览器。）

标签： javascript cross-browser data-uri-scheme

【解决方案1】：

首先，请注意，我在意识到 Chrome 因应用程序/javascript 以及 x-javascript 损坏后编辑了问题。

看起来这是 Chrome 中的一个直接错误。它不会拒绝执行 utf-8 “编码” javascript，而是折叠空格，例如导致命名函数的任何定义变得不正确，例如函数 foo(){} 变为 functionfoo(){}。这不会发生在 text/javascript 或 base64 编码的 uris 中。

所以，答案是使用 text/javascript。

顺便说一句：在保留 text/css 的同时坚持弃用 text/javascript 似乎有点珍贵。

【讨论】：