对于大多数情况，我对Content-Type标头有很好的理解。 我明白，对于以下四个示例，您通常会使用charset=your-charset-here的MIMEtypes。
Content-Type "text/plain; charset=utf-8" Content-Type "text/html; charset=utf-8" Content-Type "text/javascript; charset=utf-8" Content-Type "text/xml; charset=utf-8"
…和图像，没有字符集：
Content-Type "image/gif" Content-Type "image/x-icon" etc.
但是这两个呢？ 他们是否应该包括charset ？
Content-Type "application/x-javascript" Content-Type "application/xml"
我意识到如果他们不包括字符集也没问题，但是如果可能的话，我想包括它。 毕竟，它们只是基于文本的文件。
Content-Type "text/xml; charset=utf-8"
这是多余的。 对于XML， <?xml?>声明优先于Content-Type标头。 如果XML声明被省略了，那你还是有UTF-8的。
我通常会离开XML的字符集。 考虑到XML有自己完美的内联字符编码机制，Content-Type头是不需要的，只能通过意外地select文件的错误types，而没有指定在其他地方被视为UTF-8的encoding 。
有一次，你需要一个XML字符集参数，当你提供一个非ASCII兼容的字符集，通常是UTF-16，否则parsing器将不会读取<?xml 。 但是很less有人想这样做。 UTF-16不是一个伟大的文件存储/线上格式。
Content-Type "application/xml"
application/xml媒体types由RFC3023指定，并为其明确定义了charset参数。 所以你可以使用charset如果你想（虽然按照上述，我通常不想）。
Content-Type "application/x-javascript"
是一个非官方的types，所以没有说明是否存在charset参数或它可能做什么。 应该避免使用这种types的text/javascript （传统）或application/javascript （由RFC4329定义）。
实际上，在您的JavaScript资源上设置charset不够，IE完全忽略它。
给予脚本字符集机制的优先级（从最高到最低）的总结：
IE： <script charset>属性，父页面的字符集
Opera：脚本文件的字符集，父页面的字符集
Mozilla，Webkit：脚本文件的字符集， <script charset>属性，父页面的字符集