标签:class code java ext width http
2.1 JSP页面本身的编码形式
<%@ page language=”java” import=”java.util.*”
pageEncoding=”utf-8″%>
pageEncoding
指的是jsp文件本身在本地保存时的编码方式。注意:在eclipse环境下会根据pageEncoding保存的。
2.2 服务器端发送字节流的编码
<%@ page contentType=”text/html;charset=UTF-8″ %>
是服务器端java程序运行时的输出字节流的编码方式,即服务器端向客户端输出HTML代码时采用的编码。
2.3 服务器端JSP编译过程中的编码
第一阶段是将jsp编译成.java,它会根据pageEncoding的设定读取jsp,然后编译成utf-8格式的java源码(.java文件)。如果pageEncoding设定错了或没有设定,编译出的java源文件就会出现不正确的字符。
第二阶段是由javac用utf-8的编码方式读取java源码,然后编译成二进制码(.class文件)这个二进制文件也是uft-8格式的。
第三阶段是Tomcat(或其的服务器容器)载入和执行第二阶段编译的二进制文件,输出的字节流是根据<%@ page
contentType=”text/html;charset=UTF-8″ %> 编码方式制定的。
2.4 浏览器端解析字节流的编码
<meta http-equiv=”Content-Type” content=”text/html;
charset=utf-8″>
是指客户端浏览器以什么样的编码来显示网页。网页本质是从服务器端输出的字节流。同时它还有一个重要的作用,规定了使用post方式提交表单的时候使用什么编码传入参数。虽然服务器端request获取post请求参数的代码和获取get请求参数的代码完全一样。
2.5 GET方式的编码(浏览器端编码)
get方式提交参数的编码比较复杂,有以下几种情况:
(1)
对于中文IE,如果在高级选项中选中总以utf-8发送(默认方式),则PathInfo是按照utf-8编码,QueryString是按照GBK编码。
http://localhost:8080/example/中国?name=中国
实际上提交是:
GET /example/%E4%B8%AD%E5%9B%BD?name=%D6%D0%B9%FA
(2) 对于中文IE,如果在高级选项中取消总以utf-8发送,则PathInfo和QueryString是按照GBK编码。
实际上提交是:GET
/example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
(3)
对于中文firefox,则pathInfo和queryString都是按照GBK编码。
实际上提交是:GET
/example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
很显然,不同的浏览器以及同一浏览器的不同设置,会影响最终URL中PathInfo的编码。对于中文的IE和firefox都是采用GBK编码QueryString。
2.6 GET方式的编码(服务器端的解码)
http://localhost:8080/example/record.html?name=张三
在服务器端获取参数的形式为:request.getParameter(“name”); name的值是经过Servlet服务器URL
Decode(解码)过的。需要注意的是解码的方式是在应用服务器的配置文件中的。
而在Resin容器的内部,所有的字符都是按照iso-8859-1来处理的。
URL中的PathInfo和QueryString字符串的编码和解码是由浏览器和应用服务器的配置决定的,我们的程序不能设置,不要期望用request.setCharacterEncoding()方法能设置URL中参数值解码时的字符集。这一点是与post方式是有区别的。
2.7 POST方式的编码
对于post方式,表单中的参数值对是通过请求体发送给服务器,此时浏览器会根据网页的content=”text/html; charset=utf-8″中指定的编码进行对表单中的数据进行编码,然后发给服务器。在服务器端的程序中我们可以通过Request.setCharacterEncoding()设置编码,然后通过request.getParameter获得正确的数据。
2.8 URL编码(百分号编码)
对于URL来说,之所以要进行编码,是因为URL中有些字符会引起歧义。例如URL参数字符串使用key=value键值对这样的形式来传参,键值对之间以&符号分隔,如/s?q=abc&
ie=utf-8。如果你的value字符串中包含了=或者&,那么势必会造成接收URL的服务器解析错误,因此必须将引起歧义的&和=符号进行转义,也就是对其进行编码。
又如,URL的编码格式采用的是ASCII码,而不是Unicode,这也就是说你不能在URL中包含任何非ASCII字符,例如中文,否则如果客户端浏览器和服务端浏览器支持的字符集不同的情况下,中文可能会造成问题。URL编码的原则就是使用安全的字符(没有特殊用途或者特殊意义的可打印字符)去表示那些不安全的字符。
不需要编码的字符包括:
URL中只允许包含英文字母(a-zA-Z)、数字(0-9)、-_.~4个特殊字符以及所有保留字符。
需要编码的情况:
(1)普通数据中包括保留数据:
URL可以划分成若干个组件,协议、主机、路径等。有一些字符(:/?#[]@)是用作分隔不同组件的。例如:冒号用于分隔协议和主机,/用于分隔主机和路径,?用于分隔路径和查询参数等。还有一些字符(!$&’()*+,;=)用于在每个组件中起到分隔作用的,如=用于表示查询参数中的键值对,&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时,需要对其进行编码。RFC3986中指定了以下字符为保留字符:
! |
* |
‘ |
( |
) |
; |
: |
@ |
& |
= |
+ |
$ |
, |
/ |
? |
# |
[ |
] |
(2)不安全字符
还有一些字符,当他们直接放在URL中的时候,可能会引起解析程序的歧义。这些字符被视为不安全字符,原因有很多。
空格 |
URL在传输的过程,或者用户在排版的过程,或者文本处理程序在处理URL的过程,都有可能引入无关紧要的空格,或者将那些有意义的空格给去掉 |
引号以及<> |
引号和尖括号通常用于在普通文本中起到分隔URL的作用 |
# |
通常用于表示书签或者锚点 |
% |
百分号本身用作对不安全字符进行编码时使用的特殊字符,因此本身需要编码 |
{}|\^[]`~ |
某一些网关或者传输代理会篡改这些字符 |
需要注意的是,对于URL中的合法字符,编码和不编码是等价的,但是对于上面提到的
这些字符,如果不经过编码,那么它们有可能会造成URL语义的不同。因此对于URL而言,只有普通英文字符和数字,特殊字符$-_.+!*’()还有保留符,才能出现在未经编码的URL之中。其他字符均需要经过编码之后才能出现在URL中。
如何对URL中的非法字符进行编码
URL编码通常也被称为百分号编码(URL Encoding,also known as percent-encoding),是因为它的编码方式非常简单,使用%百分号加上两位的字符【0123456789ABCDEF】代表一个字节的十六进制形式。URL编码默认使用的字符集是US-ASCII。例如a在US-ASCII码中对应的字节是0×61,那么URL编码之后得到的就是%61,我们在地址栏上输入http://g.cn/search?q=%61%62%63,实际上就等同于在google上搜索abc了。又如@符号在ASCII字符集中对应的字节为0×40,经过URL编码之后得到的是%40。
常见字符的URL编码列表:
保留字符的URL编码 | |||||||||
! |
* |
“ |
‘ |
( |
) |
; |
: |
@ |
& |
%21 |
%2A |
%22 |
%27 |
%28 |
%29 |
%3B |
%3A |
%40 |
%26 |
= |
+ |
$ |
, |
/ |
? |
% |
# |
[ |
] |
%3D |
%2B |
%24 |
%2C |
%2F |
%3F |
%25 |
%23 |
%5B |
%5D |
对于非ASCII字符,需要使用ASCII字符集的超集进行编码得到相应的字节,然后对每个字节执行百分号编码。对于Unicode字符,RFC文档建议使用utf-8对其进行编码得到相应的字节,然后对每个字节执行百分号编码。如“中文”使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0×96 0×87,经过URL编码之后得到“%E4%B8%AD%E6%96%87”。
如果某个字节对应着ASCII字符集中的某个非保留字符,则此字节无需使用百分号表示。 例如“URL编码”,使用UTF-8编码得到的字节是0×55 0×72 0x6C 0xE7 0xBC 0×96 0xE7 0xA0 0×81,由于前三个字节对应着ASCII中的非保留字符“URL”,因此这三个字节可以用非保留字符“URL”表示。最终的URL编码可以简化成 “URL%E7%BC%96%E7%A0%81” ,当然,如果你用”%55%72%6C%E7%BC%96%E7%A0%81”也是可以的。
转载自:Struts教程网(网易旗下) ? 编码详解(下)
标签:class code java ext width http
原文地址:http://www.cnblogs.com/live365wang/p/3709581.html