字符集及Java中的字符知识整理

　　　一.字符相关的定义
　　　（一）字符：各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。
　　　（二）字符集：是一个系统支持的所有抽象字符的集合，也就是多个字符的集合，字符集种类较多，每个字符集包含的字符个数不同。（常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。）
　　　（三）字符编码：是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其他东西的一个集合（如号码或电脉冲）进行配对。即在符号集合与数字系统之间建立对应关系，它是信息处理的一项基本技术。通常人们用符号集合（一般情况下就是文字）来表达信息。而以计算机为基础的信息处理系统则是利用元件（硬件）不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字，因此字符编码就是将符号转换为计算机可以接受的数字系统的数，称为数字代码。
　　　二.常见字符集的介绍
　　　（一）ASCII码
　　　（1）定义：ASCII是基于拉丁字母的一套电脑编码系统。它主要用于显示现代英语和其他西欧语言。它是现今最通用的单字节编码系统，并等同于国际标准ISO/IEC 646。
　　　（2）简介：ASCII 码使用指定的 7 位或 8 位二进制数组合来表示128 或256 种可能的字符。标准ASCII 码也叫基础ASCII码，使用7 位二进制数来表示所有的大写和小写字母，数字0 到9、标点符号， 以及在美式英语中使用的特殊控制字符。
    （3）特点：ASCII是美国标准，所以它不能良好满足其它讲英语国家的需要。基础码有128个码，扩展后也只有256个，无法满足某些国家文字中字符较多的问题，或者某些国家的特殊符号也不包含在ASCII码内，造成交流问题。例如英国的英镑符号（￡），拉丁语字母表重音符号，使用斯拉夫字母表的希腊语、希伯来语、阿拉伯语和俄语，汉字系统的中国象形汉字，日本和朝鲜的文字等等，这些在ASCII码中都没有对应码值。
　　　（二）GB2312/GBK
    （1）定义：信息交换用汉字编码字符集。《信息交换用汉字编码字符集》是由中国国家标准总局1980年发布，1981年5月1日开始实施的一套国家标准，标准号是GB 2312—1980。
    （2）简介：GB2312编码适用于汉字处理、汉字通信等系统之间的信息交换，通行于中国大陆；新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB 2312。
    基本集共收入汉字6763个和非汉字图形字符682个。整个字符集分成94个区，每区有94个位。每个区位上只有一个字符，因此可用所在的区和位来对汉字进行编码，称为区位码。
　　　把换算成十六进制的区位码加上2020H，就得到国标码。国标码加上8080H，就得到常用的计算机机内码。1995年又颁布了《汉字编码扩展规范》（GBK）。GBK与GB 2312—1980国家标准所对应的内码标准兼容，同时在字汇一级支持ISO/IEC10646—1和GB 13000—1的全部中、日、韩（CJK）汉字，共计20902字。
　　　特点：GB 2312中对所收汉字进行了“分区”处理，每区含有94个汉字/符号。这种表示方式也称为区位码。
01-09区为特殊符号。
16-55区为一级汉字，按拼音排序。
56-87区为二级汉字，按部首/笔画排序。
10-15区及88-94区则未有编码。
　　　每个汉字及符号以两个字节来表示。第一个字节称为“高位字节”（也称“区字节）”，第二个字节称为“低位字节”（也称“位字节”）。
　　　这就是汉子的国标码，专门用来表示汉字，是双字节编码，而英文字母和ISO-8859-1一致（兼容ISO-8859-1编码）。其中GBK编码能够用来同时表示繁体字和简体字，而gb2312只能表示简体字，GBK是兼容gb2312编码的。GBK 向下与 GB 2312 编码兼容，向上支持 ISO 10646.1 国际标准，是前者向后者过渡过程中的一个承上启下的标准。 
　　　（三）BIG5
　　　（1）定义：BIG-5码是通行于台湾、香港地区的一个繁体字编码方案，俗称“大五码”。地区标准号为：CNS11643，这就是人们讲的BIG-5码。
　　　（2）简介：大五码（Big5），又称为五大码，是使用繁体中文社群中最常用的电脑汉字字符集标准，共收录13,060个中文字，其中有二字为重覆编码，Big5属中文内码（中文码分为中文内码及中文交换码两类）。Big5虽普及于中国的台湾、香港与澳门等繁体中文通行区，但长期以来并非当地的国家标准，而只是业界标准（de facto standard）。倚天中文系统、Windows等主要系统的字符集都是以Big5为基准，但厂商又各自增删，衍生成多种不同版本。2003年，Big5被收录到台湾官方标准的附录当中，取得了较正式的地位。这个最新版本被称为Big5-2003。
　　　（3）特点：Big5码是一套双字节字符集，使用了双八码储存方法，以两个字节来安放一个字。第一个字节称为“高位字节”，第二个字节称为“低位字节”。“高位字节”使用了0x81-0xFE，“低位字节”使用了0x40-0x7E，及0xA1-0xFE。
　　　（四）GB18030
　　　（1）定义：国家标准GB18030-2000《信息交换用汉字编码字符集基本集的补充》是我国继GB2312-1980和GB13000-1993之后最重要的汉字编码标准，是我国计算机系统必须遵循的基础性标准之一。
　　　（2）简介：GB18030-2000编码标准是由信息产业部和国家质量技术监督局在2000年 3月17日联合发布的，并且将作为一项国家标准在2001年的1月正式强制执行。GB18030-2005《信息技术中文编码字符集》是我国自主研制的以汉字为主并包含多种我国少数民族文字（如藏、蒙古、傣、彝、朝鲜、维吾尔文等）的超大型中文编码字符集强制性标准，其中收入汉字70000余个。
　　　（3）特点：GB18030可用于一切处理中文（包括汉字和少数民族文）信息，特别是汉字信息的信息处理产品。GB18030-2005标准可应用于中文处理的软件类产品，如操作系统、数据库、中间件、办公软件、财务软件、CAD软件、表处理软件、教育软件、字型字库等。GB18030-2005标准还可应用于具有处理汉字功能的硬件产品，如打印机、移动电话、PDA产品等。
　　　（五）Unicode
　　　（1）定义：Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。Unicode 是为了解决传统的字符编码方案的局限而产生的，它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。1990年开始研发，1994年正式公布。
    （2）起源：Unicode 是为了解决传统的字符编码方案的局限而产生的，例如ISO 8859所定义的字符虽然在不同的国家中广泛地使用，可是在不同国家间却经常出现不兼容的情况。很多传统的编码方式都有一个共同的问题，即容许电脑处理双语环境（通常使用拉丁字母以及其本地语言），但却无法同时支持多语言环境（指可同时处理多种语言混合的情况）。
    Unicode 编码包含了不同写法的字，如“ɑ/a”、“户/户/戸”。然而在汉字方面引起了一字多形的认定争议（详见中日韩统一表意文字主题）。
    在文字处理方面，统一码为每一个字符而非字形定义唯一的代码（即一个整数）。换句话说，统一码以一种抽象的方式（即数字）来处理字符，并将视觉上的演绎工作（例如字体大小、外观形状、字体形态、文体等）留给其他软件来处理，例如网页浏览器或是文字处理器。
    几乎所有电脑系统都支持基本拉丁字母，并各自支持不同的其他编码方式。Unicode为了和它们相互兼容，其首 256字符保留给ISO 8859-1所定义的字符，使既有的西欧语系文字的转换不需特别考量；并且把大量相同的字符重复编到不同的字符码中去，使得旧有纷杂的编码方式得以和 Unicode编码间互相直接转换，而不会丢失任何信息。举例来说，全角格式区段包含了主要的拉丁字母的全角格式，在中文、日文、以及韩文字形当中，这些字符以全角的方式来呈现，而不以常见的半角形式显示，这对竖排文字和等宽排列文字有重要作用。
　　　在表示一个Unicode的字符时，通常会用“U+”然后紧接着一组十六进制的数字来表示这一个字符。在基本多文种平面（英 文为 Basic Multilingual Plane，简写 BMP。它又简称为“零号平面”, plane 0）里的所有字符，要用四位十六进制数（例如U+4AE0，共支持六万多个字符）；在零号平面以外的字符则需要使用五位或六位十六进制数了。旧版的 Unicode标准使用相近的标记方法，但却有些微的差异：在Unicode 3.0里使用“U-”然后紧接着八位数，而“U+”则必须随后紧接着四位数。
　　　作用及层次：能够使计算机实现跨语言、跨平台的文本转换及处理。Unicode 编码系统，可分为编码方式和实现方式两个层次。
　　　（4）方式：Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。
　　　Unicode的实现方式不同于编码方式。一个字符的Unicode编码是确定的。但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对Unicode编码的实现方式有所不同。Unicode的实现方式称为Unicode转换格式（Unicode Transformation Format，简称为UTF）。
    通用字符集（Universal Character Set, UCS）是由ISO制定的ISO 10646（或称ISO/IEC 10646）标准所定义的标准字符集。UCS-2用两个字节编码，UCS-4用4个字节编码。
　　　历史上存在两个独立的尝试创立单一字符集的组织，即国际标准化组织（ISO）和多语言软件制造商组成的统一码联盟。前者开发的 ISO/IEC 10646 项目，后者开发的统一码项目。因此最初制定了不同的标准。
　　　UTF-8：以字节为单位对Unicode进行编码。UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。
　　　UTF-16：编码以16位无符号整数为单位。UTF-16就是UCS-2加上附加字符的支持，也就是符合unicode4.0规范的UCS-2。所以UTF-16是UCS-2的严格超集。UTF-16中的字符，要么是2个字节，要么是4个字节表示的。UTF-16主要在windows2000以上版本使用。
　　　UTF-32：编码以32位无符号整数为单位。Unicode的UTF-32编码就是其对应的32位无符号整数。
　　　特点：
　　　（六）ISO-8859-1
　　　属于单字节编码，最多能表示的字符范围是0-255，应用于英文系列。比如，字母'a'的编码为0x61=97。
　　　三.常见字符集相关问题
　　　（一）汉字有ASCII码吗？
   答：ANSII是标准国际编码，只有256个字符，没有汉字，所以表示不了汉字。收录有汉字的字符集有GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。
　　　UTF-16与UTF-8相比，有什么优点？
答：（1）对于亚洲字符的存储空间需求比UTF-8少，因为每个字符都是2个字节。（2）处理字符的速度比UTF-8更快，因为是固定长度编码的。（3）对于windows和Java的支持更好。
GBK，GB2312和UTF-8的区别
　　答：首先，我们要明白，GB2312、GBK和UTF-8都是一种字符编码，除此之外，还有好多字符编码。只是对于我们中国人的网站来说，用这三种编码 比较多。简单的说一下，为什么要用编码，在计算机内，储存文本信息用ASC II码，每一个字符对应着唯一的ASCII码。最初计算机是由美国发明的，他们也用的是键盘和上面的字母，所以他们的字符ASCII好解决。但是我们中国 的就不同了，每个汉字要对应唯一的ASCII码。这样，就出来了国家制定的字符编码标准：GB2312、GBK等。其他国家，其他语言也有他们对应的编码 标准。 GB 就是国标的意思，GB2312和GBK主要用于汉字的编码，而UTF-8是全世界通用的。意思就是说，如果你的网页主要面对使用汉语的中国人的话，使用 GB2312和GBK非常好，文字储存体积要小，有一些优点。如果你的网页要面向世界的话，你再用GB2312和GBK作为网页编码的话，有些电脑上的浏 览器没有这种编码，你的网页汉字内容就会变成无法识别的乱码。 
它们通常用在网页的meta标签内，例如：<meta http-equiv=”Content-Type” content=”text/html; charset=gb2312″ />，表示这个页面使用的是GB2312编码。这个信息是给浏览器看的，浏览器会优先考虑使用从网页头部提取出来的编码信息对网页进行解码。当然， 我们也可以强制浏览器使用某种编码解释网页，这样我们就看到了传说中的乱码。
　
　　　Java与字符集
　　　（一）Java中的字符集问题
    1、JVM中单个字符占用的字节长度跟编码方式有关，而默认编码方式又跟平台是一一对应的或说平台决定了默认字符编码方式；
    2、对于单个字符：ISO-8859-1单字节编码，GBK双字节编码，UTF-8三字节编码；因此中文平台(中文平台默认字符集编码GBK)下一个中文字符占2个字节，而英文平台(英文平台默认字符集编码Cp1252(类似于ISO-8859-1))。
    3、getBytes()、getBytes(encoding)函数的作用是使用系统默认或者指定的字符集编码方式，将字符串编码成字节数组。
    编码方式决定字节长度；在中文平台下，默认的字符集编码是GBK，此时如果使用getBytes()或getBytes("GBK")，则按照GBK的编码规则将每个中文字符用2个byte表示。所以我们看到"中文"最终GBK编码结果就是： -42 -48 -50 -60 。-42和-48代表了"中"字，而"-50"和"-60"则代表了"文"字。
    在中文平台下，如果指定的字符集编码是UTF-8，那么按照UTF-8对中文的编码规则：每个中文用3个字节表示，那么"中文"这两个字符最终被编码成：-28 -72 -83、-26 -106 -121两组。每3个字节代表一个中文字符。
    在中文平台下，如果指定的字符集编码是ISO-8859-1，由于此字符集是单字节编码，所以使用getBytes("ISO-8859-1")时，每个 字符只取一个字节，每个汉字只取到了一半的字符。另外一半的字节丢失了。由于这一半的字符在字符集中找不到对应的字符，所以默认使用编码63代替，也就 是?。
   在英文平台下，默认的字符集编码是Cp1252(类似于ISO-8859-1)，如果使用GBK、UTF-8进行编码，得到的字节数组依然是正确的(GBK4个字节，UTF-8是6个字节)。因为在JVM内部是以Unicode存储字符串的，使用getBytes(encoding)会让JVM进行一次Unicode到指定编码之间的转换。对于GBK，JVM依然会转换成4个字节，对于UTF-8，JVM依然会转换成6个字节。但是对于ISO-8859-1，则由于无法转换(2个字节--->1个字节，截取了一半的字节)，所以转换后的结果是错误的。
在中文平台下，默认的字符集编码是GBK，于是content.getBytes()得到的是什么呢？就是下面这4个字节：
byte[0]  = -42 hex string = ffffffd6
byte[1] = -48 hex string = ffffffd0
byte[2] = -50 hex string = ffffffce
byte[3] = -60 hex string = ffffffc4
    如果新的encoding是GBK，那么经过解码后，由于一个字符用2个字节表示。于是最终的结果就是：
char[0]='中' --- byte[0] + byte[1]
char[1]='文' --- byte[2] + byte[3]
    如果新的encoding是ISO-8859-1，那么经过解码后，由于一个字符用1个字节表示，于是原来本应该2个字节一起解析的变成单个字节解析，每 个字节都代表了一个汉字字符的一半。这一半的字节在ISO-8859-1中找不到对应的字符，就变成了"?"了，最终的结果：
char[0]='?' ---- byte[0]
char[1]='?' ---- byte[1]
char[2]='?' ---- byte[2]
char[3]='?' ---- byte[3]
     如果新的encoding是UTF-8，那么经过解码后，由于一个字符用3个字节表示，于是原来4个字节的数据无法正常的解析成UTF-8的数据，最终的结果也是每一个都变成"?"。
char[0]='?' ---- byte[0]
char[1]='?' ---- byte[1]
char[2]='?' ---- byte[2]
char[3]='?' ---- byte[3]
    如果是在英文平台下，由于默认的编码方式是Cp1252，于是content.getBytes()得到的字节都是被截去一半的残留字符，所以我们看到在英文平台下，不论指定的encoding是GBK、UTF-8，其结果和ISO-8859-1都是一样的。
   记 住：这个方法再次证明了String的getBytes()方法的危险性，如果我们使用new String(str.getBytes(), encoding)对字符串进行重新编码解码时，我们一定要清楚str.getBytes()方法返回的字节数组的长度、内容到底是什么，因为在接下来使 用新的encoding进行编码解码时，Java并不会自动地对字节数组进行扩展以适应新的encoding。而是按照新的编码方法直接对该字节数组进行 解析。于是结果就像上面的例子一样，同样是4个原始字节，有些每2个一组进行解析，有些每个一组进行解析，有些每3个一组进行解析。其结果就只能看那种编码方式合适了。
   结论：相同的平台下，同一个中文字符，在不同的编码方式下，得到的是完全不同的字节数组。这些字节数组有可能是正确的(只要该字符集支持中文)，也可能是完全错误的(该字符集不支持中文)。
   记住：不要轻易地使用或滥用String类的getBytes(encoding)方法，更要尽量避免使用getBytes()方法。因为这个方法是平台依赖的，在平台不可预知的情况下完全可能得到不同的结果。如果一定要进行字节编码，则用户要确保encoding的方法就是当初字符串输入时的encoding。
    和getBytes(encoding)不同，toCharArray()返回的是"自然字符"。但是这个"自然字符"的数目和内容却是由原始的编码方式决定的。
     FileWriter是字符流输出流，而OutputStreamWriter是字节流输出流在中文平台下，如 果使用FileWriter，不论你如何设置字符集都不会起作用。因为它采用的是默认的系统字符集。即便你设置了 System.setProperty("file.encoding", "ISO-8859-1")，或者在运行时给予参数-Dfile.encoding=UTF-8都不会起作用。你会发现它最终还是都已"GB2312"或 者"GBK"的方式保存。
    在中文平台下，如果使用OutputStreamWriter，则在后台写入时会把字符流转换成字节流，此时指定的编码字符集就起作用了。可以看到在指定 GBK、UTF-8的情况下中文可以正常的保存和读取，同时文件按照我们给定的方式保存了。而对于ISO-8859-1则变成了?，这再次证明了采用ISO-8859-1是不能保存中文的，而且会因为中文编码在ISO-8859-1的编码中找不到对应的字符而默认转换成?。
     在英文平台下，如果使用FileWriter，不论你如何设置字符集同样都不会起作用。所有的文件都将按照ISO-8859-1的编码方式保存，毫无疑 问地变成了?。在英文平台下，如果使用OutputStreamWriter，则只有当我们把字符和文件的编码方式正确设置为GBK、UTF-8的情况 下，中文才能正确的保存并显示。
     通过上述的实验证明，为了确保在不同的平台下，客户端输入的中文可以被正确地解析、保存、读取。最好的办法就是使用OutputStreamWriter配合UTF-8编码。如果不想使用UTF-8编码，那么可以考虑使用GB2312，不建议使用GBK、GB18030。因为对于某些老式的文本编辑器，甚至不支持GBK、GB18030的编码，但是对于GB2312则是一定支持的。因为前两者都不是国标但后者是。
    关于String的getBytes()，getBytes(encoding)和new String(bytes, encoding)这三个方法，非常值得注意：A.getBytes()：使用平台默认的编码方式(通过file.encoding属性获取)方式来将字 符串转换成byte[]。得到的是字符串最原始的字节编码值。
B.getBytes(NAME_OF_CHARSET)：使用指定的编码方式将字符串转换成byte[]，如果想要得到正确的字节数组，程序员必须给出正确的NAME_OF_CHARSET。否则得到的就不会得到正确的结果。
C.new String(bytes, encoding)：如 果我们在客户端使用UTF-8编码的JSP页面发出请求，浏览器编码后的UTF-8字节会以ISO-8859-1的形式传递到服务器端。所以要得到经 HTTP协议传输的原始字节，我们需要先调用getBytes("ISO-8859-1")得到原始的字节，但由于我们客户端的原始编码是UTF-8，如 果继续按照ISO-8859-1解码，那么得到的将不是一个中文字符，而是3个乱码的字符。所以我们需要再次调用new String(bytes,"UTF-8")，将字节数组按照UTF-8的格式，每3个一组进行解码，才能还原为客户端的原始字符。
D.String的getBytes()、 getBytes(NAME_OF_CHARSET)方法都是比较微妙的方法，原则上：传输时采用的是什么编码，我们就需要按照这种编码得到字节。new String(bytes, NAME_OF_CHARSET)则更加需要小心，原则上：客户端采用的是什么编码，那么这里的NAME_OF_CHARSET就必须和客户端保持一致。例如JSP页面是GBK，那么我们接收页面传递而来的参数时就必须使用new String(parameter.getBytes("ISO-8859-1"), "GBK");如果使用了错误 的解码方式，如使用了UTF-8，那么得到的很有可能就是乱码了。也就是说：GBK--->ISO-8859-1--->GBK、UTF- 8--->ISO-8859-1--->UTF-8的转换过程是没有问题的。但是GBK--->ISO- 8859-1--->UTF-8、UTF-8--->ISO-8859-1--->GBK的字节直接转码则可能导致乱码，需要另外的转 换过程。
记住：谨 慎地使用getBytes(NAME_OF_CHARSET)和new String(bytes, NAME_OF_CHARSET)，除非你很清楚的知道原始的字符编码和传输协议使用的编码。推荐使用基于服务器的配置、过滤器设置 request/response的characterEncoding、content type属性。还有就是JSP页面的pageEncoding属性、HTML meta元素的content type属性。尽量避免频繁的在代码中进行字符串转码，即降低了效率又增加了风险。
　　　（二）Java中的字符乱码问题及解决方式
　　（1）针对直接在console上运行的类
　　对于这种情况，我们建议在程序编写时，如果需要从用户端接收用户的可能含有中文的输入或含有中文的输出，程序中应该采用字符流来处理输入和输出
如：BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in,"UTF-8"));

　　（2）针对Servlet，我们建议用以下方法：
　　在编译Servlet类的源程序时，用-encoding指定编码为UTF-8，且在向用户输出时的编码部分用response对象的setContentType("text/html;charset=UTF-8")来设置输出编码格式；同样在接收用户输入时，我们用request.setCharacterEncoding("UTF-8")；为了避免每个servlet都需要写这些相同的代码可在filter中设置。
　　
　　（3） JAVA程序和数据库之间
为避免JAVA程序和数据库之间数据传递出现乱码现象，我们建议采用以下最优方法来处理： 1、对于JAVA程序的处理方法按我们指定的方法处理。
2、把数据库默认支持的编码格式改为UTF-8的。

（4）针对JSP代码
由于JSP是在运行时，由WEB容器进行动态编译的，他在移植时最容易出问题，那是因为容器在编译JSP文件时获取的操作系统的编码不同造成的，解决办法如下：
1、我们要保证JSP向客户端输出时是采用中文编码方式输出的，即无论如何我们首先在我们的JSP源代编中加入以下一行：
<%@page contentType="text/html; charset=UTF-8"%>
2为了让JSP能正确获得传入的参数，我们在JSP源文件头加入下面一句： <%request.setCharacterEncoding("UTF-8");%>
3、为了让JSP编译器能正确地解码我们的含有中文字符的JSP文件，我们需要在JSP源文件中指定我们的JSP源文件的编码格式，具体来说，我们在JSP源文件头上加入下面的一句即可： <%@page pageEncoding=" UTF-8"%>
　　（5） GET请求乱码
如果在本项目中采用了get方式提交请求并附加参数，结果导致编码乱码，原因是Tomcat默认请求编码是ISO8859，需要在Tomcat的配置文件 server.xml添加一个参数，URIEncoding=”UTF-8”,这样请求中附件的参数就会以UTF-8来进行编码。
     （6）Ajax请求乱码
使用Ajax，JS也是默认使用ISO8859编码，所以在进行请求时遇到中文参数需要进行编码，如：var url = "GetSelectListAction.do?queryData=subTrade" + "&queryId=" + encodeURI(obj.value) + "&r=" + Math.random();   
       有两个地方需要注意：第一个地方是encodeURI()，方法，可以将参数进行转码，默认是转化为UTF-8，如果需要转为其他码制，需要在方法中添加第二个参数。
        第二个地方是Math.random()，由于Ajax有缓存机制，在接受请求的时候第一时间先判断该请求的地址是否被访问过，如果被访问过则 直接使用缓存中的内容返回，这个东西很讨厌，客户在访问过一次出错后以后每次出现的都是这个错误，所以在请求中给其增加一个时间戳，只要可以随机生成一个 不同的字串就可以，保证Ajax每次都去访问服务器。
     （7） GET方法的另一个乱码问题
        在项目即将交工的时候突然又出现乱码问题，发现对于超长的汉字作为参数传递仍然会出现乱码问题，解决方法是采用java.net.URLEncoder的 Encode方法强制转码，写法如：<a href="TestAction.do?name=<%= java.net.URLEncoder.encode("你好","UTF-8")%>
     （8） HTML网页
在HTML网页的<head></head>中存在多个<meta/>标签，其中可以设置Content-Type。例如：
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
　　　（三）避免乱码的一些注意点：
    1.尽量使用统一的编码，如果你是重头开发一个系统，特别是Java开发的，推荐从页面到数据库再到配置文件都使用UTF-8进行编码，安全第一。
    2.SetCharacterEncodingFilter的使用，这个东西不是万能的，但是没有它就会很麻烦，，这个Filter只是对POST请求有效，GET一律忽略。
    3.就如上面所说，GET请求有问题，尽量使用POST请求 。
    4.JavaScript和Ajax乱码的避免，注意JavaScript默认是ISO8859的编码，避免JS/AJAX乱码和GET一样，不要在URL里面使用中文，实在避免不了，就只能在生成链接的时候转码。
    5.尽早统一开发环境，早点模拟真实环境测试。