- 1全球智库动态 | 未来极具潜力的50项新兴技术
- 2Python 与 Blender_blender python
- 3XSS漏洞介绍及反射型XSS
- 4Python中的3D矩阵操作：从基础到高级_python读取三维矩阵
- 5WebSocket的基本使用——实现一个简易的多人聊天室_websocket多人聊天
- 6java String类常用的Apl_java apl类
- 7荣耀3OS怎么升级鸿蒙系统,华为鸿蒙OS正式发布！教你如何升级
- 8Wireshark抓取网卡协议分析（TCP,UDP,ARP,DNS,DHCP,HTTP超详细版本）_怎样可以抓取到tcp数据包
- 9解决ChatGPT消息发不出问题，GPT无法发出消息，没有响应问题（2024.03.11）_chatgpt 发消息 转圈
- 10虚拟专题：知识图谱 | 医学知识图谱构建关键技术及研究进展
关于JAVA字符编码：Unicode,ISO-8859-1,GBK,UTF-8编码及相互转换_iso8859转换成gbk
赞
踩
转载：https://www.cnblogs.com/haimishasha/p/6117968.html
目录
1.1. ISO-8859-1 通常叫做Latin-1
1.2. GB2312/GBK
1.3 unicode
1.4 UTF
2.1 Unicode与各编码之间的直接转换
2.2 Unicode与各编码之间的交叉转换
2.3 编码过程中错误诊断参考
3.1 getBytes(charset)
3.2 new String(charset)
3.3 setCharacterEncoding()
3.4. 处理过程
3.4.1. 表单输入
3.4.2. 文件编译
3.5. javaEE几处设置
3.5.1. jsp编译
3.5.2. jsp输出
3.5.3. meta设置
3.5.4. form设置
3.5.5. JSP页面获取表单的值
4.1. MySQL数据库
4.2. apache
4.3. linux默认编码
4.4. 其它
5.1. URL编码
5.2. rewrite
5.3. URLEncode.encode()
6.1. SecureCRT
6.2. 过滤器
6.3. POST和GET
6.4. 简繁体编码转换
我们最初学习计算机的时候，都学过ASCII编码。
但是为了表示各种各样的语言，在计算机技术的发展过程中，逐渐出现了很多不同标准的编码格式，
重要的有Unicode、UTF、ISO-8859-1和中国人经常使用的GB2312、BIG5、GBK等。
1.编码基础知识
最早的编码是iso8859-1，和ascii编码相似。但为了方便表示各种各样的语言，逐渐出现了很多标准编码，重要的有如下几个。
1.1. ISO-8859-1 通常叫做Latin-1
属于单字节编码，最多能表示的字符范围是0-255，应用于英文系列。比如，字母a的编码为0x61=97。
很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。
而且在很多协议上，默认使用该编码。比如，虽然"中文"两个字不存在iso8859-1编码，
以gb2312编码为例，应该是"d6d0 cec4"两个字符（java字符占2个字节），
使用iso8859-1编码的时候则将它拆开为4个字节来表示："d6 d0 ce c4"（事实上，在进行存储的时候，也是以字节为单位处理的）。
而如果是UTF编码，则是6个字节"e4 b8 ad e6 96 87"。
很明显，这种表示方法还需要以另一种编码为基础。
1.2. GB2312/GBK
这就是汉字的国标码，专门用来表示汉字，是双字节编码，而英文字母和iso8859-1一致（兼容iso8859-1编码）。
其中gbk编码能够用来同时表示繁体字和简体字，
而gb2312只能表示简体字，gbk是兼容gb2312编码的。
1.3 unicode
这是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（也有四字节的）编码，包括英文字母在内。所以可以说它是不兼容iso8859-1编码的，也不兼容任何编码。不过，相对于iso8859-1编码来说，uniocode编码只是在前面增加了一个0字节，比如字母a为"00 61"。
需要说明的是，定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而unicode又可以用来表示所有字符，所以在很多软件内部是使用unicode编码来处理的，比如java。
1.4 UTF
考虑到unicode编码不兼容iso8859-1编码，而且容易占用更多的空间：因为对于英文字母，unicode也需要两个字节来表示。所以unicode不便于传输和存储。因此而产生了utf编码，utf编码兼容iso8859-1编码，同时也可以用来表示所有语言的字符，不过，utf编码是不定长编码，每一个字符的长度从1-6个字节不等。另外，utf编码自带简单的校验功能。一般来讲，英文字母都是用一个字节表示，而汉字使用三个字节。
注意，虽然说utf是为了使用更少的空间而使用的，但那只是相对于unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，虽然utf编码对汉字使用3个字节，但即使对于汉字网页，utf编码也会比unicode编码节省，因为网页中包含了很多的英文字符。
2.Unicode、UTF-8 和 ISO8859-1区别与联系
将以"中文"两个字为例，经查表可以知道其
GB2312编码是"d6d0 cec4"，
Unicode编码为"4e2d 6587"，
UTF编码就是"e4b8ad e69687"。
注意，这两个字没有iso8859-1编码，但可以用iso8859-1编码来表示。
2.1 Unicode与各编码之间的直接转换
下面以对中文字符串＂ａ中文＂的编码转换为例，来了解各种编码之间的转换
１）Unicode和GBK
测试结果如下，每个汉字转换为两个字节，且是可逆的，即通过字节可以转换回字符串
String－GBK〉ByteArray：/u0061/u4E2D/u6587（a中文）－〉0x61 0xD6 0xD0 0xCE 0xC4 ByteArray－GBK〉String：0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u4E2D/u6587（a中文）
２）Unicode和UTF-8
测试结果如下，每个汉字转换为三个字节，且是可逆的，即通过字节可以转换回字符串
String－UTF-8〉ByteArray：/u0061/u4E2D/u6587（a中文）－〉0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87 ByteArray－UTF-8〉String：0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87－〉/u0061/u4E2D/u6587（a中文）
３）Unicode和ISO-8859-1
测试结果如下，当存在汉字时转换失败，非可逆，即通过字节不能再转换回字符串
String－ISO-8859-1〉ByteArray：/u0061/u4E2D/u6587（a中文）－〉0x61 0x3F 0x3F ByteArray－ISO-8859-1〉String：0x61 0x3F 0x3F－〉/u0061/u003F/u003F（a??）
2.2 Unicode与各编码之间的交叉转换
在上面直接转换中，由字符串（Unicode）生成的字节数组，在构造回字符串时，使用的是正确的编码集合，如果使用的不是正确的编码集合会怎样呢？会正确构造吗？如果不能正确构造能有办法恢复吗？会信息丢失吗？
下面我们就来看看这种情况，这部分可以说明在某些情况下虽然我们最终正确显示了结果，但其间仍然进行了不正确的转换。
１）能够正确显示的中间不正确转换
我们知道String－GBK〉ByteArray－GBK〉String是正确的，但如果我们采用String－GBK〉
ByteArray－ISO-8859-1〉String呢？通过测试结果如下：
String－GBK〉ByteArray－ISO-8859-1〉String：/u0061/u4E2D/u6587（a中文）－〉0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u00D6/u00D0/u00CE/u00C4（a????
这时我们得到的字符串为？乱码“a????”，但是通过继续转换我们仍然可以复原回正确的字符串“a中文”，过程如下：
String－GBK〉ByteArray－ISO-8859-1〉String－ISO-8859-1〉ByteArray－GBK〉String
对应：/u0061/u4E2D/u6587（a中文）－〉0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u00D6/u00D0/u00CE/u00C4（a????）－〉0x61 0xD6 0xD0 0xCE 0xC4－〉/u0061/u4E2D/u6587（a中文）
也就是我们在首次构造字符串时，我们用了错误的编码集合得到了错误的乱码，但是我们通过错上加错，再用错误的编码集合获取字节数组，然后再用正确的编码集合构造，就 又恢复了正确的字符串。这时就属于是“能够正确显示的中间不正确转换”。在Jsp页面提交数据处理时常常发生这种情况。
此外能够正确显示的中间不正确转换还有：
String－UTF-8〉ByteArray－ISO-8859-1〉String－ISO-8859-1〉ByteArray－UTF-8〉String
和
String－UTF-8〉ByteArray－GBK〉String－GBK〉ByteArray－UTF-8〉String
对应：/u0061/u4E2D/u6587（a中文）－〉0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87－〉/u0061/u6D93/uE15F/u6783（a涓枃）－〉0x61 0xE4 0xB8 0xAD 0xE6%0x96 0x87－〉/u0061/u4E2D/u6587（a中文）
2.3 编码过程中错误诊断参考
１）一个汉字对应一个问号
在通过ISO-8859-1从字符串获取字节数组时，由于一个Unicode转换成一个byte，当遇到不认识的Unicode时，转换为0x3F，这样无论用哪种编码构造时都会产生一个？乱码。
２）一个汉字对应两个问号
在通过GBK从字符串获取字节数组时，由于一个Unicode转换成两个byte，如果此时用ISO-8859-1或用UTF-8构造字符串就会出现两个问号。
若是通过ISO-8859-1构造可以再通过上面所说的错上加错恢复（即再通过从ISO-8859-1解析，用GBK构造）；
若是通过UTF-8构造则会产生Unicode字符＂/uFFFD＂，不能恢复，若再通过String－UTF-8〉ByteArray－GBK〉String，则会出现杂码，如a锟斤拷锟斤拷
３）一个汉字对应三个问号
在通过UTF-8从字符串获取字节数组时，由于一个
这是java字符串处理的一个标准函数，其作用是将字符串所表示的字符按照charset编码，并以字节方式表示。注意字符串在java内存中总是按unicode编码存储的。比如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"，如果charset为"gbk"，则被编码为"d6d0 cec4"，然后返回字节"d6 d0 ce c4".如果charset为"utf8"则最后是"e4 b8 ad e6 96 87".如果是"iso8859-1"，则由于无法编码，最后返回 "3f 3f"（两个问号）。
3. java对字符的处理
在java应用软件中，会有多处涉及到字符集编码，有些地方需要进行正确的设置，有些地方需要进行一定程度的处理。
3.1 getBytes(charset)
这是java字符串处理的一个标准函数，其作用是将字符串所表示的字符按照charset编码，并以字节方式表示。
注意字符串在java内存中总是按unicode编码存储的。
比如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"，
如果charset为"gbk"，则被编码为"d6d0 cec4"，然后返回字节"d6 d0 ce c4"。
如果charset为"utf8"则最后是"e4 b8 ad e6 96 87"。
如果是"iso8859-1"，则由于无法编码，最后返回 "3f 3f"（两个问号）。
3.2 new String(charset)
这是java字符串处理的另一个标准函数，和上一个函数的作用相反，将字节数组按照charset编码进行组合识别，最后转换为unicode存储。
参考上述getBytes的例子，"gbk" 和"utf8"都可以得出正确的结果"4e2d 6587"，但iso8859-1最后变成了"003f 003f"（两个问号）。
因为utf8可以用来表示/编码所有字符，所以new String( str.getBytes( "utf8" ), "utf8" ) === str，即完全可逆。
3.3 setCharacterEncoding()
该函数用来设置http请求或者相应的编码。
对于request，是指提交内容的编码，指定后可以通过getParameter()则直接获得正确的字符串，如果不指定，则默认使用iso8859-1编码，需要进一步处理。
参见下述"表单输入"。值得注意的是在执行setCharacterEncoding()之前，不能执行任何getParameter()。
java doc上说明：This method must be called prior to reading request parameters or reading input using getReader()。
该指定只对POST方法有效，对GET方法无效。分析原因:
POST方法在执行第一个getParameter()的时候，java将会按照编码分析所有的提交内容，而后续的getParameter()不再进行分析，所以setCharacterEncoding()无效。
GET方法提交表单是，提交的内容在URL中，一开始就已经按照编码分析所有的提交内容，setCharacterEncoding()自然就无效。
注意：iso-8859-1是JAVA网络传输使用的标准字符集,而gb2312是标准中文字符集,当你作出提交表单等需要网络传输的操作的时候,就需要把 iso-8859-1转换为gb2312字符集显示,否则如果按浏览器的gb2312格式来解释iso-8859-1字符集的话,由于2者不兼容,所以会 是乱码.
例子：
//１）将字符串用指定的编码集合解析成字节数组，完成Unicode－〉//charsetName转换
public byte[] getBytes(String charsetName) throws UnsupportedEncodingException
//２）将字节数组以指定的编码集合构造成字符串，完成charsetName－〉Unicode转换
public String(byte[] bytes, String charsetName) throws UnsupportedEncodingException
String s = "你好";
// 编码
byte[] utf = s.getBytes("utf-8");
byte[] gbk = s.getBytes("gbk");
System.out.println("utf-8编码：" + Arrays.toString(utf));//[-28,-67,-96,-27,-91,-67] 6个字节
System.out.println("gbk编码：" + Arrays.toString(gbk));//[-60,-29,-70,-61] 4个字节
// 解码
String s1 = new String(utf, "utf-8"); // 你好
String s2 = new String(utf, "gbk"); // gbk解码：浣犲ソ gbk用2个字节解码，所以会多一个字符
String s3 = new String(gbk, "utf-8"); // gbk用utf-8解码：??? utf-8解码需要6个字节
System.out.println("--------------------");
System.out.println("utf-8解码：" + s1);
System.out.println("gbk解码：" + s2);
System.out.println("gbk用utf-8解码：" + s3);
System.out.println("---------------------");
System.out.println("用utf-8编码回去");
s3 = new String(s3.getBytes("utf-8"), "gbk"); // 锟斤拷锟? gbk用utf-8解码后无法编回去
System.out.println(s3);
| 1 |
|
规律：
utf-8编码可以用gbk和iso8859-1解码后编回去
gbk编码后只能用iso8859-1解码后编回去
3.4. 处理过程
下面分析两个有代表性的例子，说明java对编码有关问题的处理方法。
3.4.1. 表单输入
User input *(gbk:d6d0 cec4)
browser *(gbk:d6d0 cec4)
web server iso8859-1(00d6 00d 000ce 00c4) class，
需要在class中进行处理：
getbytes("iso8859-1")为d6 d0 ce c4，
new String("gbk")为d6d0 cec4，
内存中以unicode编码则为4e2d 6587。
l 用户输入的编码方式和页面指定的编码有关，也和用户的操作系统有关，所以是不确定的，上例以gbk为例。
l 从browser到web server，可以在表单中指定提交内容时使用的字符集，否则会使用页面指定的编码。而如果在url中直接用?的方式输入参数，则其编码往往是操作系统本身的编码，因为这时和页面无关。上述仍旧以gbk编码为例。
l Web server接收到的是字节流，默认时（getParameter）会以iso8859-1编码处理之，结果是不正确的，所以需要进行处理。但如果预先设置了编码（通过request. setCharacterEncoding ()），则能够直接获取到正确的结果。
l 在页面中指定编码是个好习惯，否则可能失去控制，无法指定正确的编码。
3.4.2. 文件编译
假设文件是gbk编码保存的，而编译有两种编码选择：gbk或者iso8859-1，前者是中文windows的默认编码，后者是Linux的默认编码，当然也可以在编译时指定编码。
Jsp *(gbk:d6d0 cec4)
java file *(gbk:d6d0 cec4)
compiler read uincode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4)
compiler write utf(gbk: e4b8ad e69687; iso8859-1: *)
compiled file unicode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4) class。
所以用gbk编码保存，而用iso8859-1编译的结果是不正确的。
class unicode(4e2d 6587) system.out / jsp.out gbk(d6d0 cec4) os console / browser。
l 文件可以以多种编码方式保存，中文windows下，默认为ansi/gbk。
l 编译器读取文件时，需要得到文件的编码，如果未指定，则使用系统默认编码。一般class文件，是以系统默认编码保存的，所以编译不会出问题，但对于jsp文件，如果在中文windows下编辑保存，而部署在英文linux下运行/编译，则会出现问题。所以需要在jsp文件中用pageEncoding指定编码。
l Java编译的时候会转换成统一的unicode编码处理，最后保存的时候再转换为utf编码。
l 当系统输出字符的时候，会按指定编码输出，对于中文windows下，System.out将使用gbk编码，而对于response（浏览器），则使用jsp文件头指定的contentType，或者可以直接为response指定编码。同时，会告诉browser网页的编码。如果未指定，则会使用iso8859-1编码。对于中文，应该为browser指定输出字符串的编码。
l browser显示网页的时候，首先使用response中指定的编码（jsp文件头指定的contentType最终也反映在response上），如果未指定，则会使用网页中meta项指定中的contentType。
3.5. javaEE几处设置
对于web应用程序，和编码有关的设置或者函数如下。
3.5.1. jsp编译
指定文件的存储编码，很明显，该设置应该置于文件的开头。例如：<%@page pageEncoding="GBK"%>。另外，对于一般class文件，可以在编译的时候指定编码。
3.5.2. jsp输出
指定文件输出到browser时使用的编码，该设置也应该置于文件的开头。例如：<%@ page contentType="text/html; charset= GBK" %>。该设置和response.setCharacterEncoding("GBK")等效。
3.5.3. meta设置
指定网页使用的编码，该设置对静态网页尤其有作用。因为静态网页无法采用jsp的设置，而且也无法执行response.setCharacterEncoding()。例如： <META http-equiv="Content-Type" content="text/html; charset=GBK" />
如果同时采用了jsp输出和meta设置两种编码指定方式，则jsp指定的优先。因为jsp指定的直接体现在response中。
需要注意的是，apache有一个设置可以给无编码指定的网页指定编码，该指定等同于jsp的编码指定方式，所以会覆盖静态网页中的meta指定。所以有人建议关闭该设置。
3.5.4. form设置
当浏览器提交表单的时候，可以指定相应的编码。例如：<form accept-charset= "gb2312">。一般不必不使用该设置，浏览器会直接使用网页的编码。
3.5.5. JSP页面获取表单的值
在JSP页面获取表单的值时会出现乱码，有两种解决方法：
1.post:在调用getParameter之前通过request.setCharacterEncoding设置字符编码
2.get:调用new String(str.getBytes("iso8859-1"), "UTF-8");编码后解码
4. 系统软件
下面讨论几个相关的系统软件。
4.1. MySQL数据库
很明显，要支持多语言，应该将数据库的编码设置成utf或者unicode，而utf更适合与存储。但是，如果中文数据中包含的英文字母很少，其实unicode更为适合。
数据库的编码可以通过mysql的配置文件设置，例如default-character-set=utf8。
还可以在数据库链接URL中设置，例如： useUnicode=true&characterEncoding=UTF-8。
注意这两者应该保持一致，在新的sql版本里，在数据库链接URL里可以不进行设置，但也不能是错误的设置。
Oracle中字符集编码决定
select userenv('language') from dual;
SIMPLIFIED CHINESE_CHINA.ZHS16GBK
SIMPLIFIED CHINESE_CHINA.AL32UTF8
select lengthb('你') from dual;
4.2. apache
appache和编码有关的配置在httpd.conf中，例如AddDefaultCharset UTF-8。如前所述，该功能会将所有静态页面的编码设置为UTF-8，最好关闭该功能。
另外，apache还有单独的模块来处理网页响应头，其中也可能对编码进行设置。
4.3. linux默认编码
这里所说的linux默认编码，是指运行时的环境变量。两个重要的环境变量是LC_ALL和LANG，默认编码会影响到java URLEncode的行为，下面有描述。
建议都设置为"zh_CN.UTF-8"。
4.4. 其它
为了支持中文文件名，linux在加载磁盘时应该指定字符集，例如：mount /dev/hda5 /mnt/hda5/ -t ntfs -o iocharset=gb2312。
另外，如前所述，使用GET方法提交的信息不支持request.setCharacterEncoding()，但可以通过tomcat的配置文件指定字符集，在tomcat的server.xml文件中，形如：<Connector ... URIEncoding="GBK"/>。这种方法将统一设置所有请求，而不能针对具体页面进行设置，也不一定和browser使用的编码相同，所以有时候并不是所期望的。
5. URL地址
URL地址中含有中文字符是很麻烦的，前面描述过使用GET方法提交表单的情况，使用GET方法时，参数就是包含在URL中。
5.1. URL编码
对于URL中的一些特殊字符，浏览器会自动进行编码。这些字符除了"/?&"等外，还包括unicode字符，比如汉字。这时的编码比较特殊。
IE有一个选项"总是使用UTF-8发送URL"，
当该选项有效时，IE将会对特殊字符进行UTF-8编码，同时进行URL编码。
如果该选项无效，则使用默认编码"GBK"，并且不进行URL编码。但是，对于URL后面的参数，则总是不进行编码，相当于UTF-8选项无效。
比如"中文.html?a=中文"，
当UTF-8选项有效时，将发送链接"%e4%b8%ad%e6%96%87.html?a=/x4e/x2d/x65/x87"；
而UTF-8选项无效时，将发送链接"/x4e/x2d/x65/x87.html?a=/x4e/x2d/x65/x87"。
注意后者前面的"中文"两个字只有4个字节，而前者却有18个字节，这主要时URL编码的原因。
当web server（tomcat）接收到该链接时，将会进行URL解码，即去掉"%"，同时按照ISO8859-1编码（上面已经描述，可以使用URLEncoding来设置成其它编码）识别。
上述例子的结果分别是"/ue4/ub8/uad/ue6/u96/u87.html?a=/u4e/u2d/u65/u87"和"/u4e/u2d/u65/u87.html?a=/u4e/u2d/u65/u87"，
注意前者前面的"中文"两个字恢复成了6个字符。这里用"/u"，表示是unicode。
所以，由于客户端设置的不同，相同的链接，在服务器上得到了不同结果。这个问题不少人都遇到，却没有很好的解决办法。所以有的网站会建议用户尝试关闭UTF-8选项。不过，下面会描述一个更好的处理办法。
5.2. rewrite
熟悉的人都知道，apache有一个功能强大的rewrite模块，这里不描述其功能。需要说明的是该模块会自动将URL解码（去除%），即完成上述web server（tomcat）的部分功能。有相关文档介绍说可以使用[NE]参数来关闭该功能，但我试验并未成功，可能是因为版本（我使用的是apache 2.0.54）问题。另外，当参数中含有"?& "等符号的时候，该功能将导致系统得不到正常结果。
rewrite本身似乎完全是采用字节处理的方式，而不考虑字符串的编码，所以不会带来编码问题。
5.3. URLEncode.encode()
这是Java本身提供对的URL编码函数，完成的工作和上述UTF-8选项有效时浏览器所做的工作相似。值得说明的是，java已经不赞成不指定编码来使用该方法（deprecated）。应该在使用的时候增加编码指定。
当不指定编码的时候，该方法使用系统默认编码，这会导致软件运行结果得不确定。比如对于"中文"，当系统默认编码为"gb2312"时，结果是"%4e%2d%65%87"，而默认编码为"UTF-8"，结果却是"%e4%b8%ad%e6%96%87"，后续程序将难以处理。
另外，这儿说的系统默认编码是由运行tomcat时的环境变量LC_ALL和LANG等决定的，曾经出现过tomcat重启后就出现乱码的问题，最后才郁闷的发现是因为修改修改了这两个环境变量。
建议统一指定为"UTF-8"编码，可能需要修改相应的程序。
6. 其它
下面描述一些和编码有关的其他问题。
6.1. SecureCRT
除了浏览器和控制台与编码有关外，一些客户端也很有关系。比如在使用SecureCRT连接linux时，应该让SecureCRT的显示编码（不同的session，可以有不同的编码设置）和linux的编码环境变量保持一致。否则看到的一些帮助信息，就可能是乱码。
另外，mysql有自己的编码设置，也应该保持和SecureCRT的显示编码一致。否则通过SecureCRT执行sql语句的时候，可能无法处理中文字符，查询结果也会出现乱码。
对于Utf-8文件，很多编辑器（比如记事本）会在文件开头增加三个不可见的标志字节，如果作为mysql的输入文件，则必须要去掉这三个字符。（用linux的vi保存可以去掉这三个字符）。一个有趣的现象是，在中文windows下，创建一个新txt文件，用记事本打开，输入"连通"两个字，保存，再打开，你会发现两个字没了，只留下一个小黑点。
6.2. 过滤器
如果需要统一设置编码，则通过filter进行设置是个不错的选择。在filter class中，可以统一为需要的请求或者回应设置编码。参加上述setCharacterEncoding()。这个类apache已经给出了可以直接使用的例子SetCharacterEncodingFilter。
6.3. POST和GET
很明显，以POST提交信息时，URL有更好的可读性，而且可以方便的使用setCharacterEncoding()来处理字符集问题。
但GET方法形成的URL能够更容易表达网页的实际内容，也能够用于收藏。
从统一的角度考虑问题，建议采用GET方法，这要求在程序中获得参数是进行特殊处理，而无法使用setCharacterEncoding()的便利，如果不考虑rewrite，就不存在IE的UTF-8问题，可以考虑通过设置URIEncoding来方便获取URL中的参数。
6.4. 简繁体编码转换
GBK同时包含简体和繁体编码，也就是说同一个字，由于编码不同，在GBK编码下属于两个字。有时候，为了正确取得完整的结果，应该将繁体和简体进行统一。可以考虑将UTF、GBK中的所有繁体字，转换为相应的简体字，BIG5编码的数据，也应该转化成相应的简体字。当然，仍旧以UTF编码存储。
例如，对于"语言 語言"，
用UTF表示为"/xE8/xAF/xAD/xE8/xA8/x80 /xE8/xAA/x9E/xE8/xA8/x80"，
进行简繁体编码转换后应该是两个相同的 "/xE8/xAF/xAD/xE8/xA8/x80>"。
参考：http://blog.csdn.net/qinysong/article/details/1179513
