Java web 乱码

Java web 乱码 http://www.jb51.net/web/12714.html (一) get提交 1.首先说下客户端 (浏览器) 的form表单用get方法是如何将数据编码后提交给服务器端的吧。 对于get方法来说,都是把数据串联在请求的url后面作为参数,如: http://localhost:8080/servlet?msg=abc (很常见的一个乱码问题就要出现了,如果url中出现中文或其它特殊字符的话,如: http://localhost:8080 /servlet?msg=杭州,服务器端容易得到乱码) ,url拼接完成后,浏览器会对url进行URL encode,然后发送给服务器,URL encode的过程就是把部分url做为字符,按照某种编码方式 (如: utf-8,gbk等) 编码成二进制的字节码,然后每个字节用一个包含3个字符的字符串 “%xy” 表示,其中xy为该字节的两位十六进制表示形式。我这里说的可能不清楚,具体介绍可以看下java.net.URLEncoder。了解了 URL encode的过程,我们能看到2个很重要的问题,第一: 需要URL encode的字符一般都是非ASCII的字符 (笼统的讲) ,再通俗的讲就是除了英文字母以外的文字 (如: 中文,日文等) 都要进行URL encode,所以对于我们来说,都是英文字母的url不会出现服务器得到乱码问题,出现乱码都是url里面带了中文或特殊字符造成的;第二: URL encode到底按照那种编码方式对字符编码?这里就是浏览器的事情了,而且不同的浏览器有不同的做法,中文版的浏览器一般会默认的使用GBK,通过设置浏览器也可以使用UTF-8,可能不同的用户就有不同的浏览器设置,也就造成不同的编码方式,所以很多网站的做法都是先把url里面的中文或特殊字符用 javascript做URL encode,然后再拼接url提交数据,也就是替浏览器做了URL encode,好处就是网站可以统一get方法提交数据的编码方式。 完成了URL encode,那么现在的url就成了ASCII范围内的字符了,然后以iso-8859-1的编码方式转换成二进制随着请求头一起发送出去。这里想多说几句的是,对于get方法来说,没有请求实体,含有数据的url都在请求头里面,之所以用URL encode,我个人觉的原因是: 对于请求头来说最终都是要用iso-8859-1编码方式编码成二进制的101010…..的纯数据在互联网上传送,如果直接将含有中文等特殊字符做iso-8859-1编码会丢失信息,所以先做URL encode是有必要的。 2。服务器端 (tomcat) 是如何将数据获取到进行解码的。 第一步是先把数据用iso-8859-1进行解码,对于get方法来说,tomcat获取数据的是ASCII范围内的请求头字符,其中的请求url里面带有参数数据,如果参数中有中文等特殊字符,那么目前还是URL encode后的%XY状态,先停下,我们先说下开发人员一般获取数据的过程。通常大家都是request.getParameter(“name”)获取参数数据,我们在request对象获得的数据都是经过解码过的,而解码过程中程序里是无法指定,这里要说下,有很多新手说用 request.setCharacterEncoding(“字符集”)可以指定解码方式,其实是不可以的,看servlet的官方API说明有对此方法的解释: Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader().可以看出对于get方法他是无能为力的。那么到底用什么编码方式解码数据的呢,这是tomcat的事情了,默认缺省用的是 iso-8859-1,这样我们就能找到为什么get请求带中文参数为什么在服务器端得到乱码了,原因是在客户端一般都是用UTF-8或GBK对数据 URL encode,这里用iso-8859-1方式URL decoder显然不行,在程序里我们可以直接 ...

Created 3036-06-03 · Updated 9096-10-09 · 1 min · 151 words · -

ISO 8859-1

ISO 8859-1 ISO/IEC 8859-1,又称Latin-1或"西欧语言",是国际标准化组织内ISO/IEC 8859的第一个8位字符集。它以ASCII为基础,在空置的0xA0-0xFF的范围内,加入192个字母及符号,藉以供使用变音符号的拉丁字母语言使用。 此字符集支援部分于欧洲使用的语言,包括阿尔巴尼亚语、巴斯克语、布列塔尼语、加泰罗尼亚语、丹麦语、荷兰语、法罗语、弗里西语、加利西亚语、德语、格陵兰语、冰岛语、爱尔兰盖尔语、意大利语、拉丁语、卢森堡语、挪威语、葡萄牙语、里托罗曼斯语、苏格兰盖尔语、西班牙语及瑞典语。 英语虽然没有重音字母,但仍会标明为ISO 8859-1编码。除此之外,欧洲以外的部分语言,如南非荷兰语、斯瓦希里语、印尼语及马来语、菲律宾他加洛语等也可使用ISO 8859-1编码。 法语及芬兰语本来也使用ISO 8859-1来表示。但因它没有法语使用的 œ、Œ、 Ÿ 三个字母及芬兰语使用的 Š、š、Ž、ž ,故于1998年被ISO/IEC 8859-15所取代。 (ISO 8859-15同时加入了欧元符号) ISO/IEC 8859-2 Latin-2或"中欧语言",是国际标准化组织内ISO/IEC 8859的其中一个8位字符集 ISO/IEC 8859-3 南欧语言字符集 ISO/IEC 8859-4 北欧语言字符集 ISO/IEC 8859-5 是国际标准化组织内ISO/IEC 8859的其中一个8位字符集。此字集收录西里尔字母,供俄语、白俄罗斯语、保加利亚语、马其顿语、塞尔维亚语、乌克兰语使用。(哈萨克语及蒙古语尽管不是斯拉夫文字,但也使用西里尔字母书写) ISO/IEC 8859-6 供现代阿拉伯语使用 ISO/IEC 8859-7 供现代希腊语使用 ISO/IEC 8859-8 供希伯来语使用 ISO/IEC 8859-9是国际标准化组织内ISO/IEC 8859的其中一个8位字符集。它主要用以表示土耳其语及库尔德语文字。 这个字符集由ISO/IEC 8859-1演化而来,它把原属冰岛语的 Ð、ð、Ý、ý、Þ、þ 字母移走,换上 Ğ、ğ、İ、ı、Ş、ş 六个土耳其语字母。 ISO/IEC 8859-10 北欧语言 ISO/IEC 8859-11 泰语 ISO/IEC 8859-12 取消 ISO/IEC 8859-13 波罗的语 ISO/IEC 8859-14 爱尔兰,马恩岛,苏格兰盖尔语,威尔士语,康沃尔,和布列塔尼 ISO/IEC 8859-15 西欧语 ISO/IEC 8859-16 阿尔巴尼亚,克罗地亚,匈牙利,波兰,罗马尼亚,塞尔维亚,斯洛文尼亚,但也有法国,德国,意大利和爱尔兰的盖尔 (新正字法) 。 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告:代码/配置放入代码块,正文中的尖括号占位符改为行内代码;categories 改为 CS 正文中的 HTML/XML 片段被当作原始 HTML 丢弃;文件名/URL/标题按规范调整

Created 3036-06-03 · Updated 9096-10-09 · 1 min · 92 words · -

XML 编码

xml 编码 前同天和同事在讨论xml里的encoding属性和文件格式的关系,终于彻底的弄清楚了。 以前理解的是,xml里的encoding里定义必须与文件格式相匹配。即有这样的xml Introduction <?xml encoding="utf-8" .. ?>,那么,文件格式必须是一个utf-8文件,即文件的前两个字节要是一个utf-8头FF FE。 (后来才弄清楚,FF FE不是utf-8的BOM。。就是说我的错误理解持续了相当长一段时间。。) 下面把讨论的几个阶段大概说一下。 刚开始讨论时,我很肯定的告诉他,encoding的值必须和文件格式 (即BOM,BOM就是 byte order mark的缩写) 相匹配,不然在解析XML时,可能会出现 (比如文档含有某个UNICODE字符,而encoding或BOM指定的格式不匹配,就会出错,当时我是这样的意思) ,然后他又告诉我,好像不是这样,我用DELPHI创建的XML文件,没有BOM,XML里面有中文内容,encoding里指定的是UTF-8,用IE可以正常打开啊。 他在发现他所创建的XML文件没有BOM时,有个有趣的地方,就是用UE打开这类含有UNICODE字符的文件时,UE会自动在文件前面加上FF FE,使得文件可以正常显示,所以原本没有BOM的文件,在UE下的十六进制下浏览,会看到多了个BOM,这个功能可以在UE的OPTIONS里去掉的,想知道的可以自己去找找。 然后我有点大头了,怎么会这样呢,然后想啊想,突然他发了一条信息过来,内容如下: W3C定义了三条XML解析器如何正确读取XML文件的编码的规则: 1,如果文挡有BOM(字节顺序标记,一般来说,如果保存为unicode格式,则包含BOM,ANSI则无),就定义了文件编码 2,如果没有BOM,就查看XML声明的编码属性 3,如果上述两个都没有,就假定XML文挡采用UTF-8编码 有了这三条规则,那这个规则就清楚多了。 首先,XML解析器根据文件的BOM来解析文件;如果没找到BOM,由用XML里的encoding属性指定的编码;如果xml里encoding没指定的话,就默认用utf-8来解析文档。然后又可以推出,BOM和ENCODING都有的话,则以BOM指定的为准。 啊!突然觉得有标准文档多好!虽然是那么的理所当然。 至此,终于把xml里的encoding和文件格式的关系弄懂了。虽然这篇记录只有那几百个字内容,但是我们当时在讨论的时候,总时间差不多花了2个小时。 http://blog.csdn.net/fzy112001/article/details/4183139 http://www.cnblogs.com/azol/articles/1137035.html 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告:代码/配置放入代码块,正文中的尖括号占位符改为行内代码;文件重命名为 xml-encoding.md;title 改为「XML 编码」;url 改为 xml-encoding;旧 url 加入 aliases 正文中的 HTML/XML 片段被当作原始 HTML 丢弃;文件名/URL/标题按规范调整

Created 10106-06-10 · Updated 9096-10-09 · 1 min · 58 words · -

ASCII、Unicode、UTF-8 编码的区别

ASCII、Unicode,UTF-8编码的区别 Unicode unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符,最多可以容纳1114112个字符,或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。 UCS 通用字符集 (Universal Character Set,UCS) 是由ISO制定的ISO 10646 (或称ISO/IEC 10646) 标准所定义的标准字符集。UCS-2用两个字节编码,UCS-4用4个字节编码。 UNICODE与UCS实际上是两个不同组织的产物,为了编码一体化而进行协商,可以把unicode看做UCS-2的父集,UCS-4的子集,以为UNICODE只支持U+0FFFF-U+10FFFF的编码,而UCS-4支持31个平面。 https://www.jianshu.com/p/1a39be00f5b8 Unicode ASCII UTF-8 GBK关系 首先必须知道一个概念 - 字符集 计算机中的所有字符, 说到底都是用二进制的 0/1 排列组合来表示的, 因此就需要有一个规范来规定每个字符对应 0/1 排列组合, 这样的规范就是字符集. Unicode, ASCII, GB2312, GBK 都是字符集. UTF-8不是! ASCII 最早的计算机在设计时采用 8 个 bit 作为一个字节 - byte, 所以, 一个字节能表示的范围就是 00000000 到 11111111, 也就是 0 到 255, 一共 256 种状态, 每一个状态对应一个符号, 可以表示 256 个符号. 美国有关的标准化组织就出台了 ASCII 编码, 对英语字符, 数字以及部分符号与二进制位之间的关系, 做了统一规定, 一共规定了 128 个字符的编码. 只占用了一个字节的后面 7 位, 最前面一位统一规定为 0, 一直沿用至今. ...

Created 24246-10-24 · Updated 9096-10-09 · 3 min · 584 words · -