是否存在应用程序/javascript（作为javascript的MIME类型）获胜的情况'；不行？

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

背景：

我发现了一个有趣的例子，Chrome将拒绝执行作为application/x-Javascript传递的Javascript或作为utf-8编码数据url传递的application/Javascript（so 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,.....

基于谷歌搜索，似乎规定application/javascript为标准，在这种情况下它可以工作，但（现在已弃用）text/javascript也是如此

---

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

首先，请注意，我在意识到Chrome在应用程序/javascript和x-javascript中被破坏后编辑了这个问题

它看起来像是Chrome中的一个直截了当的bug。它并不拒绝执行utf-8“编码”javascript，而是压缩空格，例如，导致命名函数的任何定义变得不正确，例如，函数foo（）{}变成函数foo（）{}。这不会发生在text/javascript或base64编码的URI上

因此，答案是使用text/javascript。

---

旁白：在保留text/css的同时，坚持不使用text/javascript似乎有点珍贵。

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