代码之家 › 专栏 › 技术社区 › Tuukka Mustonen

在Web项目中应该使用什么编码方案?

special-characters character-encoding utf-8

Tuukka Mustonen · 技术社区 · 15 年前

我们正在用Eclipse构建一个(Java)Web项目。默认情况下,Eclipse使用 Cp1252 在Windows机器上编码(我们使用)。

由于我们在中国(除了欧洲)也有开发人员,我开始怀疑这是否真的是要使用的编码。

我最初的想法是 UTF-8 ,因为 “它支持所有字符集” . 然而,这真的明智吗?我们应该选择其他编码吗?我看到几个问题:

1)默认情况下,Web浏览器如何解释文件?它是否取决于第一个版本使用的语言?接下来我要说的是,我们应该口头声明使用的编码方案:

XHTML文件可以使用 <?xml version='1.0' encoding='UTF-8' ?> 声明。
CSS文件可以通过 @CHARSET "UTF-8"; .
javascript文件没有文件内声明,但可以全局定义 <meta http-equiv="Content-Script-Type" content="text/javascript; charset=utf-8"> 或 <script type="text/javascript" charset="utf-8"> 对于特定脚本。

如果我们不使用CSS文件 @字符集“utf-8”; 宣言?浏览器如何决定编码方式?

2)使用UTF-8是否明智,因为它是如此灵活。把我们的代码锁定到 CP1252 (或者) ISO-8859-1 )我可以确保外国开发人员不会在文件中引入特殊字符。这有效地阻止了他们插入中文评论,例如(我们应该使用100%的英语)。此外,允许UTF-8有时会让开发人员意外地引入一些奇怪的字符,这些字符很难/不可能用肉眼察觉。例如,当人们复制粘贴文本或偶然按下某个奇怪的键盘组合时,就会发生这种情况。

似乎允许项目中使用UTF-8只会带来问题…

3)对于Internationalization,我最初认为UTF-8是一件好事(“如果文件编码不支持所需的字符,如何添加翻译?”)但是,事实证明,Java资源束(.Realm文件) 必须用ISO-8859-1编码,否则它们可能会损坏。相反,国际字符被转换成 \uXXXX 例如,符号 \u0009 文件是用 ISO-859-1 . 所以…我们甚至不能使用UTF-8。

对于二进制文件…好吧,编码方案并不重要(我想可以说它根本不存在)。

我们应该如何处理这些问题?

2 回复 | 直到 15 年前

Community CDub 8 年前

我最初的想法是转换成UTF-8,因为“它支持所有字符集”。然而,这真的明智吗?

去争取它。你想要统治世界。

1)默认情况下,Web浏览器如何解释文件?它是否取决于第一个版本使用的语言?

它使用 Content-Type 此的响应头(注意, 真实的 响应头,而不是HTML元标记)。我知道你是一个Java开发人员,所以下面是JSP/Servlet目标的答案:设置 <%@page pageEncoding="UTF-8" %> 在JSP页面的顶部将隐式执行此权限和设置 response.setCharacterEncoding("UTF-8") 在servlet/filter中也一样。如果没有这个头,那么完全由浏览器决定/确定编码。MSIE将使用平台默认编码。火狐有点聪明,会根据页面内容猜测编码。

2)使用UTF-8是否明智,因为它非常灵活。通过将我们的代码锁定到CP1252(或者可能是ISO-8859-1)中,我可以确保外国开发人员不会在文件中引入特殊字符。

我只需要编写一个描述团队编码约定的文档,并在开发人员之间传播它。每个自尊心强的开发人员都知道,如果不遵守这一点,他们有被解雇的风险。

3)对于Internationalization,我最初认为UTF-8是一件好事(“如果文件编码不支持所需的字符,如何添加翻译?”)但是,事实证明,Java资源包(.RealsFixes)必须用ISO-859-1编码,因为否则它们可能会被破坏。

这是因为Java 1.6的新解决方案。 Properties#load() 方法A Reader 和新的 ResourceBundle.Control 类,您可以在其中控制束文件的加载。在jsp/servlet术语中,通常是 ResourceBundle 已被使用。只需将消息束名称设置为自定义的完全限定类名 资源束 实现和它将被使用。

对于二进制文件…好吧,编码方案并不重要(我想可以说它根本不存在)。

只有当人们想把计算机可读的二进制数据转换成人类可读的字符数据时,编码才是真正有趣的。对于“真正的”二进制内容,它确实没有任何意义,因为二进制格式不代表任何合理的字符数据。

参见:

Unicode - How to get characters right? (Java WebApp发展目标)
I18n enhancements in Java 6
Another answer with ResourceBundle.Control example

Thanatos 15 年前

我绝对会推荐UTF-8,而不是所有其他的编码方案。

如果要在数据库中存储多语言数据,请确保DBMS完全符合UTF-8标准。

此外,请确保所有文件(包括CSS、javascript、应用程序模板文件)本身都使用带有BOM的UTF-8编码。如果不是, charset 浏览器可能无法正确解释指令。

我们在一个大型数据库支持的CMS中有30多种语言,它的工作方式很有魅力。客户机拥有所有执行数据输入的语言的人工编辑器。

您可能会遇到一些语言的排序问题(可怕的土耳其语无点的例子 i --在不区分大小写的数据库中。总是有一个答案,但它将是非常具体的数据库。

我不熟悉Java资源包的细节。我们确实使用了一些Java库 markdownj 这个过程在数据库中输入和输出UTF-8编码的文本时没有问题。

编辑以回答操作员的意见:

我认为将UTF-8主流化的主要原因是你永远不知道你的系统将朝什么方向发展。您可能认为您今天只处理一种语言,但即使在完全单一语言的环境中也不是这样,因为您可能需要存储名称或包含非US-ASCII八位字节值的引用。

此外,UTF-8编码字符流不会改变US-ASCII八位字节值,这提供了与非UTF-8启用文件系统或其他软件的完全兼容性。

如果应用程序/文本文件是用UTF-8编码的,并且包括 <meta charset="utf-8"> 在提供给浏览器的任何页面上。

请检查您的中间件(PHP、JSP等)是否在任何地方都支持UTF-8,并与您的数据库一起这样做。

我看不出开发人员在处理他们不理解的数据时有什么问题。当我们用自己的母语处理数据时,这是否也是潜在的情况?至少在一个完全的Unicode系统中,他们能够识别出他们在浏览器或数据库中看到的字形是否与他们应该处理的语言相匹配,而不是获取流?????????????????????????

我相信使用UTF-8作为字符编码是一个安全的选择。这应该适用于几乎所有的情况,而且你已经为你老板到来的那一天做好了准备,并且坚持你必须使用多种语言。