关于字符编码的概念及技巧
在基于 Java 语言的编程中，我们经常碰到汉字的处理及显示的问题。
Java 语言默认的编码方式是UNICODE ，它给JAVA带来了活力，及更广的适应性，但是问题也随之而来
我们通常使用的文件和数据库一般都是基于 GB2312
或者 BIG5 等方式编码的，怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢？
英文字符一般是以一个字节来表示的，最常用的编码方法是 ASCII 。但一个字节最多只能区分
256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，
每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。我们经常碰到的编码方式有
GB2312、BIG5、UNICODE 等。关于具体编码方式的详细资料，有兴趣的读者可以查阅相关资料。
GB2312是国标码。两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）
的值为位号值加32（20H），用这两个值来表示一个汉字的编码。
UNICODE 码是微软提出的解决多国字符问题的多字节等长编码，它对英文字符采取前面加“0”字节的策略
实现等长兼容。如 “A” 的 ASCII 码为0x41，UNICODE 就为0x00，0x41,利用特殊的工具各种编码之间可以
互相转换。
我们经常碰到这样的情况：浏览基于 JSP 技术的网站看到的是乱码，文件打开后看到的也是乱码，
这是因为 外部文件-> Java 字节码-> ;虚拟机->操作系统->显示设备” 这个转变过程有了问题。
首先看一个JSP中的解决中文问题的例子，我想这段代码大家都很熟悉吧，
但他的具体含义是什么呢？为什么要这样做呢？
String s1 = request.getParameter(“keyword”);
//从request中取参数 s1
byte[] bytes=s1.getBytes(“ISO-8859-1”);
//把s1(按Unicode->ISO-8859-1) 转回原来的byte[]。
String s2 = new String(bytes,”GBK”);
//因为原来的参数（或字符，字串）是GBK编码方式，所以把bytes
//按照GBK->Unicode的方式转码
为什么要这样做呢？因为接收的参数本来是GBK编码方式的，但是缺省的用了
iso-8859-1->Unicode 的转码方式把参数转成了String
所以肯定是乱码（中文时）
只要了解了这个基本道理，中文字符问题应该都能解决！
转自http://www.programbbs.com/doc/3788.htm
Java与Unicode：
Java的class文件采用utf8的编码方式，JVM运行时采用utf16。
Java的字符串是unicode编码的。
总之，Java采用了unicode字符集，使之易于国际化。
Java支持哪些字符集：
即Java能识别哪些字符集并对它进行正确地处理？
查看Charset 类，最新的JDK支持160种字符集。可以通过static方法availableCharsets拿到所有Java支持的字符集。
- assertEquals(160, Charset.availableCharsets().size());
- Set<String> charsetNames = Charset.availableCharsets().keySet();
- assertTrue(charsetNames.contains("utf-8"));
- assertTrue(charsetNames.contains("utf-16"));
- assertTrue(charsetNames.contains("gb2312"));
- assertTrue(Charset.isSupported("utf-8"));
需要在哪些时候注意编码问题？
1. 从外部资源读取数据：
这跟外部资源采取的编码方式有关，我们需要使用外部资源采用的字符集来读取外部数据：
- InputStream is = new FileInputStream("res/input2.data");
- InputStreamReader streamReader = new InputStreamReader(is, "GB18030");
这里可以看到，我们采用了GB18030编码读取外部数据，通过查看streamReader的encoding可以印证：
- assertEquals("GB18030", streamReader.getEncoding());
assertEquals("GB18030", streamReader.getEncoding());正是由于上面我们为外部资源指定了正确的编码，当它转成char数组时才能正确地进行解码（GB18030 -> unicode）：
- char[] chars = new char[is.available()];
- streamReader.read(chars, 0, is.available());
但我们经常写的代码就像下面这样：
- InputStream is = new FileInputStream("res/input2.data");
- InputStreamReader streamReader = new InputStreamReader(is);
这时候InputStreamReader采用什么编码方式读取外部资源呢？Unicode？不是，这时候采用的编码方式是JVM的默认字符集，这个默认字符集在虚拟机启动时决定，通常根据语言环境和底层操作系统的 charset 来确定。可以通过以下方式得到JVM的默认字符集：
- Charset.defaultCharset();
为什么要这样？因为我们从外部资源读取数据，而外部资源的编码方式通常跟操作系统所使用的字符集一样，所以采用这种默认方式是可以理解的。
好吧，那么我通过我的IDE Ideas创建了一个文件，并以JVM默认的编码方式从这个文件读取数据，但读出来的数据竟然是乱码。为何？呵呵，其实是因为通过Ideas创建的文件是以utf-8编码的。要得到一个JVM默认编码的文件，通过手工创建一个txt文件试试吧。
2. 字符串和字节数组的相互转换
我们通常通过以下代码把字符串转换成字节数组：
- "string".getBytes();
但你是否注意过这个转换采用的编码呢？其实上面这句代码跟下面这句是等价的：
- "string".getBytes(Charset.defaultCharset());
也就是说它根据JVM的默认编码（而不是你可能以为的unicode）把字符串转换成一个字节数组。
反之，如何从字节数组创建一个字符串呢？
- new String("string".getBytes());
同样，这个方法使用平台的默认字符集解码字节的指定数组（这里的解码指从一种字符集到unicode）。
字符串编码迷思：
- new String(input.getBytes("ISO-8859-1"), "GB18030")
上面这段代码代表什么？有人会说： “把input字符串从ISO-8859-1编码方式转换成GB18030编码方式”。如果这种说法正确，那么又如何解释我们刚提到的java字符串都采用unicode编码呢？
这种说法不仅是欠妥的，而且是大错特错的，让我们一一来分析，其实事实是这样的：我们本应该用GB18030的编码来读取数据并解码成字符串，但结果却采用了ISO-8859-1的编码，导致生成一个错误的字符串。要恢复，就要先把字符串恢复成原始字节数组，然后通过正确的编码GB18030再次解码成字符串（即把以GB18030编码的数据转成unicode的字符串）。注意，字符串永远都是unicode编码的。
但编码转换并不是负负得正那么简单，这里我们之所以可以正确地转换回来，是因为 ISO8859-1 是单字节编码，所以每个字节被按照原样 转换为 String ，也就是说，虽然这是一个错误的转换，但编码没有改变，所以我们仍然有机会把编码转换回来！
总结：
所以，我们在处理java的编码问题时，要分清楚三个概念：Java采用的编码：unicode，JVM平台默认字符集和外部资源的编码。
转自：http://www.360doc.com/showWeb/0/0/48526159.aspx
1、Java文件编译后形成class
这里Java文件的编码可能有多种多样，但Java编译器会自动将这些编码按照Java文件的编码格式正确读取后产生class文件，这里的class文件编码是Unicode编码(具体说是UTF-16编码)。
因此，在Java代码中定义一个字符串：
String s="汉字";
不管在编译前java文件使用何种编码，在编译后成class后，他们都是一样的----Unicode编码表示。
2、JVM中的编码
JVM加载class文件读取时候使用Unicode编码方式正确读取class文件，那么原来定义的String s="汉字";在内存中的表现形式是Unicode编码。
当调用String.getBytes()的时候，其实已经为乱码买下了祸根。因为此方法使用平台默认的字符集来获取字符串对应的字节数组。在WindowsXP中文版中，使用的默认编码是GBK，不信运行下：
public class Test { public static void main(String[] args) { System.out.println("当前JRE：" + System.getProperty("java.version")); System.out.println("当前JVM的默认字符集：" + Charset.defaultCharset()); } } |
当前JRE：1.6.0_16
当前JVM的默认字符集：GBK
当不同的系统、数据库经过多次编码后，如果对其中的原理不理解，就容易导致乱码。因此，在一个系统中，有必要对字符串的编码做一个统一，这个统一模糊点说，就是对外统一。比如方法字符串参数，IO流，在中文系统中，可以统一使用GBK、GB13080、UTF-8、UTF-16等等都可以，只是要选择有些更大字符集，以保证任何可能用到的字符都可以正常显示，避免乱码的问题。(假设对所有的文件都用ASCII码)那么就无法实现双向转换了。
要特别注意的是，UTF-8并非能容纳了所有的中文字符集编码，因此，在特殊情况下，UTF-8转GB18030可能会出现乱码，然而一群傻B常常在做中文系统喜欢用UTF-8编码而不说不出个所以然出来!最傻B的是，一个系统多个人做，源代码文件有的人用GBK编码，有人用UTF-8，还有人用GB18030。FK，都是中国人，也不是外包项目，用什么UTF-8啊，神经!源代码统统都用GBK18030就OK了，免得ANT脚本编译时候提示不可认的字符编码。
因此，对于中文系统来说，最好选择GBK或GB18030编码(其实GBK是GB18030的子集)，以便最大限度的避免乱码现象。
3、内存中字符串的编码
内存中的字符串不仅仅局限于从class代码中直接加载而来的字符串，还有一些字符串是从文本文件中读取的，还有的是通过数据库读取的，还有可能是从字节数组构建的，然而他们基本上都不是Unicode编码的，原因很简单，存储优化。
因此就需要处理各种各样的编码问题，在处理之前，必须明确“源”的编码，然后用指定的编码方式正确读取到内存中。如果是一个方法的参数，实际上必须明确该字符串参数的编码，因为这个参数可能是另外一个日文系统传递过来的。当明确了字符串编码时候，就可以按照要求正确处理字符串，以避免乱码。
在对字符串进行解码编码的时候，应该调用下面的方法：
getBytes(String charsetName) String(byte[] bytes, String charsetName) |
而不要使用那些不带字符集名称的方法签名，通过上面两个方法，可以对内存中的字符进行重新编码。
本文出自 “熔 岩” 博客，请务必保留此出处http://lavasoft.blog.51cto.com/62575/273608
解决办法是：应该使用-encoding参数指明编码方式：javac -encoding UTF-8 XX.java
获取系统默认编码：
System.getProperty("file.encoding");
转自：http://hank4ever.javaeye.com/blog/581463
总结:
1、Java 源文件在编译时采用unicode编码，class文件为unicode（utf-16）编码，源文件中的字符串也为unicode编码；
2、JVM加载class文件时使用unicode编码，源文件中的字符串在内存中也为unicode编码；
3、Java源文件中读写外部资源时默认使用系统默认字符集编解码，即unicode<->default charset；
4、若外部资源不是系统默认编码而为其他编码，可采用两种方式处理：
（1）在InputStreamReader()和OutputStreamWriter()中指定字符集；
（2）对已读取的字符串进行处理：
byte[] bytes=String.getBytes(DefaultcharSet); (由于误将原字符串按Defaultcharset->unicode转码，故把string按Unicode->Defaultcharset转回原来的byte[])
new String(bytes,charSetName); （把原字符串按照charsetname->Unicode的方式转码生成正确的string）
2501
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
