JSP乱码的原因及处理（一）

以下内容为转载：

Java 开发中遇到的乱码问题
若想明白jsp开发过程中为什么会产生中文乱码，我们先来看看unicode编码。
Unicode （统一码）顾名思义是一个将世界上各种文字统一在一起的东东。由美国各大电脑厂商组成的Unicode策进会来推动。目的，推广一个世界通用的编码体制，惊世界上所有常用的文字都涵盖进去，从而减少个电脑商开发国外市场遇到的问题。
为了将成千上万的文字统统收集到一个共同的编码机制下，在兼顾经济的原则下，不管是东方还是西方文字，每个字在Unicode中一律以两个Bytes来表示，这样至少有2的16次方65536种不同的组合，足以应付目前绝大多数场合的需要。
基本上，计算机只是处理数字。它们指定一个数字，来储存字母或其他字符。在创造Unicode之前，有数百种指定这些数字的编码系统。没有一个编码可以包含足够的字符：例如，单单欧州共同体就需要好几种不同的编码来包括所有的语言。即使是单一种语言，例如英语，也没有哪一个编码可以适用于所有的字母，标点符号，和常用的技术符号。
这些编码系统也会互相冲突。也就是说，两种编码可能使用相同的数字代表两个不同的字符，或使用不同的数字代表相同的字符。任何一台特定的计算机(特别是服务器)都需要支持许多不同的编码，但是，不论什么时候数据通过不同的编码或平台之间，那些数据总会有损坏的危险。
Unicode给每个字符提供了一个唯一的数字，不论是什么平台，不论是什么程序，不论什么语言。Unicode标准已经被这些工业界的领导们所采用，例如：Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys和其它许多公司。最新的标准都需要Unicode，例如XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML等等，并且，Unicode是实现ISO/IEC 10646的正规方式。许多操作系统，所有最新的浏览器和许多其他产品都支持它。Unicode标准的出现和支持它工具的存在，是近来全球软件技术最重要的发展趋势。
将Unicode与客户服务器或多层应用程序和网站结合，比使用传统字符集节省费用。Unicode使单一软件产品或单一网站能够贯穿多个平台，语言和国家，而不需要重建。它可将数据传输到许多不同的系统，而无损坏。
在与Unicode相关的各技术文件中，经常会看到ISO 10646和UCS这两个名词。
ISO是位于瑞士的国际标准局的缩写。
UCS为ISO颁布的第10646号标准 Universal Character Set,就是世界通用字符集。
UCS通用字符集采用4个Bytes来编码,将世界上所有的官用和商用编码大小通吃，一网打尽。Unicode自1991年便和ISO的UCS小组密切配合，让Unicode和ISO 10646保持一致。因此Unicode 自2.0版开始，便和 ISO 10646-1使用相同的编码。
康熙字典中的汉字有4万7千，如果再加上里面没有的简体字，和不同写法的日文字，那么 Unicode6万多的分配空间，光用来分配汉字就显得捉禁见昼，更别说什么泰文，阿拉伯等其他文字了。针对这个问题Unicode和UCS采用了[中日韩文整合]（CJK Unification）的解决方案，把中日韩笔画详尽的汉字用同一个单码表示。
经过[中日韩文整合]的Unicode称为统汉字Unihan。
完整的Unicode4.0版可由http://www.unicode.org/Public/UNIDATA/Unihan.txt 下载。

UTF (Unicode/UCS Transformation Format),Unicode推荐使用UTF-8和UTF-16两种格式其中8和16指的是Bits数而不是Bytes数。
UTF-16基本就是Unicode双字节的实现，加上一个应付未来需要的扩充编码机制（很少用）
UTF-8 是一种不等幅的编码方式，英数字（Ascii字码）保持原状，完全不受影响（因此不需要做转换），而其他汉字资料须透过程序来转换，会[变胖]，因为每个字需要额外一个或两个Bytes来编码。
UCS字符集中，有UCS-2和UCS-4等编码方式其中的2和4指的是bytes数，对应UTF-8和UTF-16.
UCS-2基本和Unicode双byte 编码差不多
UCS-4四 byte编码表示一个字，在每个 UCS-2前面加上两个空白的Byte，便可得到对应的 UCS-4。

Unicode的空间分配：
以下Unicode区位码均以16进制表示
Unicode的前256个字符和ISO-8859-1(西欧字母)完全相同，其中前半段就是Ascii(u+0000到u+00FF)。每个ISO-8859-1码前面补上一个空byte(0x00)后才是相应的Unicode码。
和我们切身相关的Unihan主要分布在u+3400到u+F9FFF之间，GB2312和BIG5主要分布在u+4E00到U+9FFF之间。

UTF-8的编码原理和特性：
知道了西欧字符和汉字在Unicode中的位置后，来看看UTF-8

U+0000~U+007E 1 _ _ _ _ _ _ _ (7bits)
U+0080~U+07FF 1 1 0_ _ _ _ _ 1 0_ _ _ _ _ _ (11bits)
U+0800~U+FFFF 1 1 1 0 _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _ (16bits)
看一看Unicode三种格式提出自由的bits（下划线空位）是否足以用来代表区位中各Unicode码，刚好够用。
那么当程序处理UTF-8编码文件时，如何得知一个字符的疆界落在哪里？还有到底他是以三种形式那一中出现呢？
每个以UTF-8编码的字符，不管是以一、二、三个bytes出现，第一个byte前端都清楚地标示了该字符的byte总数。如110种有两个1，代表这种字符是以第二种方式出现，由两个bytes组成。而1110有三个1，表示这种字符一点种方式出现，由三个字节组成。
每个多重byte的UTF-8编码有一个共同的通性，即其中的第二个第三个byte, 一律以10两个bits开头。由于其中的最高位总设成1，可以很容易和那些在UTF-8中只用一个Byte的ASCII字元区分开来，方便侦错。
因为上述设计特点，UTF-8和Unicode之间，可以很容易做双向自由转换，而不会丢失任何资料

解决办法：乱码问题在 NT操作系统我没怎么碰到过，但是在UNIX 或LINUX系统上出现的比较多
由于操作系统和使用环境不一样，产生乱码的方式也不一样，但是如果掌握了上面的Unicode 编码原理，自己仔细分析一下，很多问题便可迎刃而解。
下面看看几个常见的例子。
1． 如果一些网站服务器例如Tomcat 如果遇到中文乱码问题，可以修改conf目录下的server.xml
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100" debug="0"connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="GBK"/>
URIENcoding 设成GBK或GB2312
2． 表单中或传递字符串：本来输入的汉字是正常的，但是提交后再显示出来是乱码，因为提交的一般是 ISO8859编码，所以显示的时候要转成GB2312编码：
String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
//rs.getString("news")为待转换的字符串
然后使用S字符串的值就可以了
3． 有的服务器端的语言环境如果设成简体中文的也可以解决此类问题
4． 插入数据库中的字符是乱码
看看数据库中支持的是何种编码方式，用类似2中的方式作一下转换即可。
5． 总之，用jsp开发，碰到乱码，你得分析是读的时候发生乱码，还是写的时候发生乱码，用2中的转换，基本就能解决问题，有些时候写的时候做一次转换，例如：
String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
//读的时候在转换回来
String S=new String(rs.getString("news").getBytes("ISO8859_1"),"GB2312");
或者把ISO8859-1和GB2312 的位置换一下，自己多试试，就能找到解决问题的办法。