我们正在使用Eclipse构建一个（Java）Web项目。默认情况下，Eclipse在Windows机器上使用Cp1252编码（我们使用）。
由于我们在中国也有开发人员（除了欧洲），我开始怀疑这是否真的是要使用的编码。
我最初的想法是转换为UTF-8，因为“它支持所有字符集”。但是，这真的很明智吗？我们应该选择其他编码吗？我看到了几个问题：
1）默认情况下，Web浏览器如何解释文件？它取决于使用的语言版本吗？我在这里说的是，我们应该详细声明所使用的编码方案：
<?xml version='1.0' encoding='UTF-8' ?>声明详细设置编码。@CHARSET "UTF-8";设置此项。<meta http-equiv="Content-Script-Type" content="text/javascript; charset=utf-8">或<script type="text/javascript" charset="utf-8">。如果我们在没有@CHARSET "UTF-8";声明的情况下离开CSS文件怎么办？浏览器如何确定如何编码？
2）使用UTF-8是明智的，因为 非常灵活。通过将我们的代码锁定到Cp1252（或者ISO-8859-1），我可以确保外国开发人员不会在文件中引入特殊字符。这有效地阻止了他们插入中文评论，例如（我们应该使用100％英语）。此外，允许UTF-8有时会让开发人员意外地引入一些奇怪的角色，这些角色很难/不可能被人眼察觉。这种情况发生在人们，例如，复制粘贴文本或碰巧意外按下某些奇怪的键盘组合时。
似乎允许项目中的UTF-8只会带来问题......
3）对于国际化，我最初认为UTF-8是一件好事（“如果文件编码不支持所需的字符，你如何添加翻译？”）。但是，事实证明，Java资源包（.properties文件）必须使用ISO-8859-1进行编码，否则它们可能会中断。相反，国际字符将转换为\uXXXX表示法，例如\u0009，文件将使用ISO-8859-1进行编码。所以...我们甚至无法使用UTF-8。
对于二进制文件......好吧，编码方案并不重要（我想可以说它甚至不存在）。
我们应该如何处理这些问题？
答案 0 :(得分：6)
我肯定会推荐UTF-8优于所有其他编码方案。
如果您将多语言数据存储在数据库中，请确保您的DBMS完全符合UTF-8
此外，请确保所有文件（包括css，javascript，应用程序模板文件）本身都以带有BOM的UTF-8编码。如果没有，浏览器可能无法正确解释charset指令。
我们在一个支持数据库的大型CMS中拥有30多种语言，它的工作方式就像魅力一样。客户端具有所有进行数据输入的语言的人工编辑器。
您可能会遇到某些语言的排序规则问题（可怕的土耳其无点i - ı - 在不区分大小写的数据库中出现的例子）。总有一个答案，但它将是特定于数据库的。
我不熟悉Java Resource Bundles的细节。我们确实使用了一些像markdownj这样的Java库来处理数据库中的UTF-8编码文本而没有问题。
编辑回答OP的评论：
我认为将UTF-8纳入主流的主要原因是你永远不知道你的系统将在哪个方向发展。您可以假设您今天只处理一种语言，但即使在完全单语环境中也是如此，因为您可能必须存储名称或包含非US-ASCII八位字节值的引用。
此外，UTF-8编码的字符流不会改变US-ASCII八位字节值，这提供了与非UTF-8启用的文件系统或其他软件的完全兼容性。
今天的现代浏览器都会正确解释UTF-8，前提是应用程序/文本文件是使用UTF-8编码的，并且您在任何提供给浏览器的页面上都包含<meta charset="utf-8">。
检查您的中间件（php，jsp等）是否支持任何地方的UTF-8，并与您的数据库一起执行此操作。
我没有看到开发人员可能处理他们不理解的数据的问题。当我们用我们自己的母语处理数据时，情况可能也不是这样吗？至少对于一个完全unicode系统，他们将能够识别他们在浏览器或数据库中看到的字形是否与他们应该处理的语言相匹配，而不是获得???? ?????? ??? ????
我相信使用UTF-8作为你的角色编码是一个安全的选择。这应该适用于几乎所有情况，并且你已经准备好迎接老板出现的那一天并且坚持你必须多语言。
答案 1 :(得分：5)
我最初的想法是转换为UTF-8，因为“它支持所有字符集”。但是，这真的很明智吗？
去吧。你想要世界统治。
1）Web浏览器默认如何解释文件？是否取决于使用的语言版本？
它使用Content-Type响应标头（注意，真实响应标头，而不是HTML元标记）。我看到/知道你是一个Java开发人员，所以这里是JSP / Servlet的目标答案：在JSP页面顶部设置<%@page pageEncoding="UTF-8" %>将隐式地执行此操作，并在Servlet / Filter中设置response.setCharacterEncoding("UTF-8")相同。如果没有此标头，则完全由浏览器决定/确定编码。 MSIE将明确使用平台默认编码。 Firefox有点聪明，会猜测基于页面内容的编码。
2）使用UTF-8是否明智，因为它非常灵活。通过将我们的代码锁定到Cp1252（或者可能是ISO-8859-1），我可以确保外国开发人员不会在文件中引入特殊字符。
我会写一篇描述团队编码约定的文档，并在开发人员之间进行传播。每个受人尊敬的开发人员都知道，如果不加以解决，他/她可能会被解雇。
3）对于国际化，我最初认为UTF-8是一件好事（“如果文件编码不支持所需的字符，你如何添加翻译？”）。但是，事实证明，Java Resource Bundles（.properties文件）必须使用ISO-8859-1进行编码，否则它们可能会中断。
自Java 1.6采用新Properties#load()方法获取Reader和新ResourceBundle.Control类以来，您可以控制捆绑文件的加载。在JSP / Servlet术语中，通常使用ResourceBundle。只需将消息包名称设置为自定义ResourceBundle实现的完全限定类名，即可使用它。
对于二进制文件......好吧，编码方案并不重要（我想可以说它甚至不存在）。
每当想要将计算机可读二进制数据转换为人类可读字符数据时，编码确实很有趣。对于“真正的”二进制内容，它确实没有任何意义，因为二进制格式不代表任何合理的字符数据。