2

我一直在开发一个解析器，它将JavaScript作为输入并创建该 JavaScript 的压缩版本作为输出。

我最初发现解析器在尝试读取输入 JavaScript 时失败。我相信这与Visual Studio 2008默认将其文件保存为UTF-8的事实有关。这样做时，VS在 UTF-8 文件的开头包含几个隐藏字符。

作为一种解决方法，我使用 Visual Studio 将文件保存为代码页 1252。这样做之后，我的解析器能够读取输入的 JavaScript。

请注意，我需要使用包含重音符号的特殊欧洲字符。

所以，这是我的问题：

  1. 我应该使用代码页 1252 还是 UTF-8？
  2. 为什么 Visual Studio 默认将文件保存为 UTF-8？
  3. 如果我选择将文件保存为 1252 会导致问题吗？
  4. 在我看来，Eclipse 默认将文件保存为代码页 1252。听起来对吗？
4

5 回答 5

9

UTF-8 是一个更好的选择，因为它确实支持所有已知字符，而使用 1252，您最终可能会得到需要的字符（即使是欧洲语言）。

显然，VS2008 使用字节顺序标记保存 UTF-8 - 应该可以将其关闭，或者让解析器识别它，或者在两者之间的某处剥离 BOM。

于 2009-06-14T09:44:35.570 回答
3

utf-8 在文件开头有字节顺序标记 (BOM) 签名，一些编辑者和显然库不理解... http://en.wikipedia.org/wiki/Byte-order_mark

如果您可以绕过它，那么今天无论如何都首选 UTF-8。在将 JS 代码提供给该解析器之前尝试剥离 BOM 的第一个字节，或者如果它无法写入，则在 IDE 中找到一个选项

1252不会导致这个问题，你不会有问题，但你会以过时的格式输出你的网络，我今天不会这样做，过去网络上有很多编码混乱使用不同语言的 iso 与 win 代码页...

于 2009-06-14T09:46:02.773 回答
1

使用 UTF-8。1252 并不涵盖整个欧洲，因此在某些国家（中欧），您应该使用 1250，或更准确地说 - iso 8859-2。所以唯一真正的选择是 UTF-8。

于 2009-06-14T09:56:56.773 回答
1

使用 1252 会导致问题吗？

取决于您的应用需要在哪些国家/地区工作

从我的脑海中，1252（或 ISO 8859-1）将适用于

  • 英国
  • 德国
  • 瑞士
  • 奥地利
  • 意大利
  • 法国
  • 荷兰
  • 冰岛
  • 西班牙

哦，维基百科有更全面的列表： http ://en.wikipedia.org/wiki/ISO/IEC_8859-1

因此，如果您的应用仅在上述国家/语言中使用，您可以使用 CP 1252。

于 2009-06-14T10:19:05.893 回答
0

BOM位于文件的开头。恕我直言，您应该使用 utf8，它现在非常流行。

于 2009-06-14T09:46:38.857 回答