IntelliJ IDEA的文件编码处理

IntelliJ IDEA的文件编码处理 收藏
因为要写这篇文章，所以查询了一下些关于编码的知识，不对之处希望能指出来 :)。编码主要经历三个阶段：ASCII、ANSI和Unicode。
    ASCII大家都知道，就是以一个字节的低7位表示字符，这样可以表达128个字符，通常就是我们所说的英文字母和符号；
    ANSI标准利用两个扩展ASCII字符来表达非英文字符，这样可以表达的扩展字符数就到达了14位，即16384个字符。针对ANSI，每个国家（地区）有自己的编码规范，对中文来说就是GB2312，GBK和GB18030，台湾的BIG5，日文的Shift-JIS等，这些都是对ANSI的具体扩展。如果你编写一个文本文件，指定为GBK，那么你打开该文件的时候必须指明其正确的编码方式，否则会出现乱码。不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码的文本中，也就是GBK编码的文件中不可能出现日文，否则打开该文件时就会出乱码。
   UNICODE 使用两个字节对世界上几乎所有的语言进行编码（0x0000－0xFFFF），它可以表达的字符数量为16位，即65536个字符，每种语言的代码段不同，两个字节所表达的字符是唯一的，所以不同语种可以共存于文本中。UNICODE只是指定了编码，没有指定传输方式（ big endian）问题，所以派生了UTF（UNICODE Transformation Format），所以UTF-8和UTF-16都是UNICODE的一种编码方式。对于UNICODE文件来说，通常文件内容的头两个字节来表明其是UNICODE，如FF FE 表示为UTF-8编码，其情况均表示为ANSI，这也是为何有IDEA的“Autodetect UTF-encoded files“功能的原因。由于UTF-8不需要处理big endian问题，因此UTF-8是最常用的UNICODE编码方式。
   乱码问题：由于UNICODE和ANSI所处理的字符的代码不一样，而且各个国家对ANSI码的解释也不一样，所以UNICODE和ANSI之间、不同国家的ANSI之间的不正确使用就导致了乱码，如打开一个字节流，如果设置的解析编码不正确，乱码就出现啦，所以要搞清楚你使用的编码方式，这样就不会出现乱码。
   扯了这么多，我们看一下IDEA提供哪些处理编码的功能。IDEA中lossy encoding（中文不知道如何翻译：易损的编码？）究竟发挥怎么样的作用咧？lossy encoding可以把不应该出现在该文件中的字符指出来，提示你进行修正。如在us-ascii编码的文件中，出现中文或日文可不可以的；同样在GBK编码的文件中出现ANSI日文或UTF字符也是不可以的。
   但是在实际的开中，有一些文件是能描述自身编码的，如xml和html。xml可以通过encoding来指定编码方式，而html通过content-type方式来指定，如果打开这些文件，就会调用相应的编码方式来处理。在开发中，我们通常会从一种编码方式转换到另一种编码，在IDEA中 ，如果你将这些自身带有编码信息的文件的编码声明改变的话，对应的文件编码也会改变。如将一个utf-8的xml文件的encoding更改为GBK，那么文件的编码也会自动进行转换并进行保存，同样修改html的content-type或jsp的content-type都会引发文件的编码自动转换，这样的处理对编码转换非常有好处，在google上你可以搜索到很多编码转换的工具，但这一切IDEA都在自动帮你搞定。如果你想快速查看一个文件的编码，最好安装File Info插件，按下Ctrl+F10马上就可以了解文件的编码方式。
    最后稍微聊一下项目的编码，如果你的项目是国际化的话，最好选择utf-8，因为可以融合多个语言，这也是为何很多论坛都采用utf-8编码（不同语言的人都会发帖），而Rails将utf-8设为默认。其他情况请选择适当的ANSI编码，同时也要考虑和utf-8直接的转换，如Ajax等。在最新的IDEA 8.0 EAP中，项目级别的编码可以被指定，而且各个文件可以指定相关的编码，文件编码处理的功能更强。希望这些介绍能对文件编码了解和实际开发有一定的帮助。

新建工程时----在General中，把File   Encoding和Properties   Files都设置成utf-8编码。

页面加上 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

IDEA会自动转换成相应的编码

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ago52030/archive/2009/03/11/3978813.aspx