[分享及讨论]JE22项目的乱码问题及预防

paullbm 2010-09-09 06:42:47
1.统一项目编码是关键,尤其是集成了一些开发框架(如extjs)后的项目,更要注重统一字符集编码。根据较为惨痛的经验表明:即使有时候选用GBK编码的项目,在不同WEB容器部署下也可能产生差异性问题:即在某WEB容器中仍然会出现乱码问题。
由于UFT-8的通用性,使得其在解决乱码问题上要比其它编码的效果要好的多。因此,在一个J2EE项目中,应该尽量使用UTF-8作为项目的统一编码。
下面就在Eclipse v3.5中如何设置统一编码进行步骤说明:
1).工具栏->Window/Preferences/General/Workspace
Text file encoding = other -> UTF-8
2).工具栏->Window/Preferences/General/Content Types
设置项目中可能使用的文本类型的编码
3).工具栏->Window/Preferences/Web
CSS Files、HTML Files、JS Files、JSP Files 都设为UTF-8
4).右击项目点选Properties/Resource
Text file encoding = other -> UTF-8 (此设置对项目移植时的作用比较大)
5).如果有使用ANT脚本进行打包,并在脚本中使用了javac命令时,需在此命令中加入属性 encoding="UTF-8"

以上操作建议新建项目后就进行设置。


2.在现在项目中(如开发并不久)时更改编码集时,可能会引起一些文件内容的乱码问题。所以在修改之前可查看该文件的Properties中的Text file encoding,如果默认情况下与容器的不一致,需要借助第三方软件(如EncodingConverter)进行文件的编码转换。但转换后如果在Eclipse中该文件有BOM(Byte Order Mark)标记,则需要将些标记去除,以避免在跨平台时有些运行环境由于不能识别此标记而出现错误的情况。


3.如果项目开发了挺长时间,出现了什么乱码问题。就自个慢慢解决吧。预防为主!


============^$#%=======$#@==========我是潇洒的分割线============&^%$^$#===================

PS1:关于BOM
[什么是BOM]
  BOM(byte-order mark),即字节顺序标记,它是插入到以UTF-8、UTF16或UTF-32编码Unicode文件开头的特殊标记,用来识别Unicode文件的编码类型。对于UTF-8来说,BOM并不是必须的,因为BOM用来标记多字节编码文件的编码类型和字节顺序(big-endian或little-endian)。
  在绝大多数编辑器中都看不到BOM字符,因为它们能理解Unicode,去掉了读取器看不到的题头信息。若要查看某个Unicode文件是否以BOM开头,可以使用十六进制编辑器。下面列出了不同编码所对应的BOM。
   BOM Encoding
  EF BB BF UTF-8
  FE FF UTF-16 (big-endian)
  FF FE UTF-16 (little-endian)
  00 00 FE FF UTF-32 (big-endian)
  FF FE 00 00 UTF-32 (little-endian)
  [BOM的来历]
   为了识别 Unicode 文件,Microsoft 建议所有的 Unicode 文件应该以 ZERO WIDTH NOBREAK SPACE(U+FEFF)字符开头。这作为一个"特征符"或"字节顺序标记(Byte-Order Mark,BOM)"来识别文件中使用的编码和字节顺序。
  [不同的系统对BOM的支持]
   因为一些系统或程序不支持BOM,因此带有BOM的Unicode文件有时会带来一些问题。
   1.JDK1.5以及之前的Reader都不能处理带有BOM的UTF-8编码的文件,解析这种格式的xml文件时,会抛出异常:Content is not allowed in prolog.
   2.Linux/UNIX 并没有使用 BOM,因为它会破坏现有的 ASCII 文件的语法约定。
  不同的编辑工具对BOM的处理也各不相同。使用Windows自带的记事本将文件保存为UTF-8编码的时候,记事本会自动在文件开头插入BOM(虽然BOM对UTF-8来说并不是必须的),但是EditPlus就不会这样做。
PS2: NOTEPAD++可以去除文件的BOM标记,但更好的方法是找到一个能够一步到位的文件编码转换工具(或自己写一个小工具)

...全文
192 3 打赏 收藏 转发到动态 举报
写回复
用AI写文章
3 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
乱码问题会出现在 Java SE/EE 开发的各各角落之中,经常会出现乱码的地方有:

* 带有汉字的 Content 发送 HTTP/POST 请求,在服务端收到乱码
* 发送 HTTP/GET 请求 URL 查询参数中含有汉字,在服务端收到乱码
* HTTP 文件下载,汉字文件名乱码
* Tomcat 请求带有汉字文件名的资源
* 汉字持久化到数据库中,数据库存成了乱码
* 从数据库中取出数据,取出来的汉字是乱码
* 网络通信数据传输在客户端或者服务端收到乱码
* 从文件中读取汉字,读到乱码
* 将汉字写入文件中,文件中存储的是乱码
* JavaMail 的主题、附件名、邮件正文等都会出现乱码,JavaMail 是个乱码的高发地带
* 利用第三方组件对 PDF、Excel、Word 格式写入汉字出现乱码

…………

总而言之,言而总之,Java 开发就是一个与乱码斗争到底的过程,乱码问题涉及所有的 Java 开发领域!

幸运的是 Java 基于 Unicode 设计的,因此,所有的汉字乱码问题都是有解决方案的。
  • 打赏
  • 举报
回复
下面这些是在一个邮件 Subject MIME 编码乱码帖子中我的一些总结:

http://topic.csdn.net/u/20100608/16/ddb9cbe6-3320-4270-bf93-72d9c0885524.html
(这个帖子中还有关于一些 MIME 编码的东西)

对于简体汉字来说,由于 GB2312, GBK, GB18030 基本上是兼容的可以认为是一种编码,因此乱码无非是以下四种情况之一,后面会教各位如何进行识别(需要知道原文是什么字符的基础之上)

1:GBK 被编码成 ISO 8859-1 了
2:UTF-8 被编码成 ISO 8859-1 了

3:GBK 被编码成 UTF-8 了
4:UTF-8 被编码成 GBK 了

前两种显示的乱码中,我们基本上一个字符都看不懂,不知道是什么,所有的字符都是低于 0xFF 的
后两种显示的乱码中,我们可以看到少量的汉字字符(可能是繁体汉字),至少有一个字符值是大于 0xFF 的

以上方法可以区分 1、2 还是 3、4。

接下来看如何区分 1 和 2:

GBK 汉字是采用两个字节编码,而 UTF-8 的汉字是至少是采用三个字节进行编码,因此通过乱码的个数可以断定是 1 还是 2。如果原文是 5 个汉字,数乱码个数如果是 10 个的话那说明是 1,如果是 15 的话那说明是 2。当然了,乱码字符有些是不可显的,数的时候可能会少掉几个,多测试几组字符就可以了。

再来看一下如何区分 3 和 4:

上面也说到了,UTF-8 汉字采用三个字节,GBK 汉字采用两个字节。UTF-8 汉字的编码长度是 GBK 汉字的 1.5 倍。如果原文是 5 个汉字,乱码的个数如果是 7 个或者 8 个的话,那说明 UTF-8 的编码被错误地编码成 GBK 了,也就是前面的第四种形式。如果原文是 5 个汉字,乱码的个数少于 5 个的话,那说明 GBK 的编码被错误地编码成 UTF-8 了,也就是前面的第三种形式。

上面的判断是在原文已知的情况下做的,如果原文未知的话,也能进行判断,但需要对编码有更深层次地了解,掌握编码的结构特性,以及在某些编码中不可能会出现的字节等等。

上面这些是我个人的经验,仅供参考。
sainer 2010-09-09
  • 打赏
  • 举报
回复
我接触到的项目中用UTF8的多数

62,616

社区成员

发帖
与我相关
我的任务
社区描述
Java 2 Standard Edition
社区管理员
  • Java SE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧