如何在 INDIVIDUAL JS 文件中声明字符编码？

Question

我们可以通过以下代码在 INDIVIDUAL CSS 文件中声明字符编码：

@charset "UTF-8";

我的问题是：

如何在 INDIVIDUAL JS 文件中声明字符编码？

如果我把一个JS文件发给我的朋友，希望他（她）在开始浏览或编辑这个JS文件时，能从代码本身理解这个JS文件的字符编码。

谢谢！

Answer 1

如果您有兴趣以人类可读的方式指示文件的编码，T.J. Crowder's 想法（在文件中添加注释，如// Encoding: UTF-8）就是这样。正如Jukka K. Korpela 指出的那样，您也可以使用BOM。

但是，如果您想要一种机器可读的方式来指示文档中声明的字符集，还有其他几种方式：

例如，在 Apache httpd 服务器上，您可以使用以下任何声明：

1. AddDefaultCharset UTF-8
2. AddCharset UTF-8 .js
3. AddType 'application/javascript; charset=UTF-8' js*

* 我对使用"application/javascript" 而不是"text/javascript" 不感兴趣。但是，如果您有兴趣了解为什么其中一个可能更可取，请参阅。 https://stackoverflow.com/a/4101763/1070047。不过，考虑到这个主题，application/javascript 似乎非常合适（特别是如果您打算使用 BOM，因为它表明代码应该被视为二进制文件）。

如果代码将在服务器端进行解释/处理/编译（例如 PHP），您可以在文档中设置标题，例如...

header("Content-Type: application/javascript; charset=utf-8");

至少在 PHP 中，确保在任何输出发生之前添加该标题语句。

最后，在确定使用哪个声明时，请考虑（当理解/尊重时，即不在 IE 中）BOM 比文档标题具有更大的权限。并且两者都优先于链接/来源的字符集声明（如<script type="application/javascript" src="script.js" charset="utf-8"></script>）。

Answer 2

没有用于在文件本身中声明编码的 JavaScript 构造，就像您在 CSS 中所做的那样。传送数据时应将编码传达给接收者。将文件作为电子邮件附件发送时，您的电子邮件程序可能会或可能不会将它们包含在指示编码的 Content-Type 标头中（但可能很难弄清楚编码可能是什么）。

您也可以在 UTF-8 编码文件的开头添加字节顺序标记 (BOM)。尽管 UTF-8 中不存在字节顺序问题，但 BOM 充当了一个有用的指示符——以构成 UTF-8 编码的 BOM 的字节开头的文件很可能是 UTF-8 编码的。这就是为什么在没有其他指示的情况下程序可以很好地推断编码的原因。这当然不是 100% 可靠，但很有用。

许多文本编辑器都可以选择将您的文件保存为“使用 BOM 编码的 UTF-8”。

（在网页上，BOM 曾经被视为一种风险，因为观察到浏览器将其视为字符数据。如今，即使是 UTF-8 格式的 BOM 也很有用，而不是一种风险。）

Answer 3

你不能。但是，您可以使用charset attribute 在将文件带入页面的script tag 中定义它。这必须与您提供文件的Content-Type 中的charset（如果有）相匹配。引用：

charset 属性给出了外部脚本资源的字符编码。如果src 属性不存在，则不得指定该属性。如果设置了该属性，则其值必须是有效的字符编码名称，对于该编码必须是 ASCII case-insensitive match，对于 preferred MIME name，并且必须匹配在 Content-Type metadata 的 charset 参数中给出的编码。外部文件，如果有的话。 [IANACHARSET]

重新编辑：

如果我给朋友发一个JS文件，希望他（她）在开始浏览或编辑这个JS文件时，能从代码本身理解这个JS文件的字符编码。

为此，您几乎只需要告诉他/她。如果文件是 UTF-8 或 Windows-1252 或 ISO 8859-1，不幸的是没有可用编码的文件内指示符，所以我会在开头添加一条注释：

// Encoding: UTF-8

但是，如果您使用的是 UTF-16 或 UTF-32，您应该能够告诉您的编辑器使用 BOM，其他编辑器应该看到和理解（如果他们是 Unicode 识别编辑器） .这通常只适用于您使用需要大量多字节字符的文本（语言）编写 cmets，并且如果您的 cmets 与代码的比例很高（因为代码是用西方文本编写的），当然欢迎您使用您喜欢的任何编码。只是如果 cmets 与代码的比率很低，即使 cmets 在需要大量四字节字符的文本中，您可能最好还是坚持使用 UTF-8，因为代码每个字符只需要一个字节. （而在 UTF-16 中，您的 cmets 中可能有更多的两字节而不是四字节字符，但代码总是需要每个字符两个字节；而在 UTF-32 中，每个字符四个字节。所以总的来说即使 cmets 占用的空间更少，文件也可能会更大。但在这里我可能会告诉你一些你已经知道的事情，如果我猜对了你提出问题的原因的话。）