TA的每日心情 | 衰 2021-2-2 11:21 |
---|
签到天数: 36 天 [LV.5]常住居民I
|
var gradeName = encodeURI(encodeURI($('#paperGrade option:selected').text()));//编码
$ c$ S8 e+ w( [0 o$ Yvar gradeName = decodeURIComponent('<%=request.getParameter("gradeName")%>');//解码
1 o6 ^: p7 e! |为什么要连续两次调用 encodeURI(String) 方法?
7 G& y8 F7 S, O# O是因为 java 中的 request.getParameter(String) 方法会进行一次 URI 的解码过程,调用时内置的解码过程会导致乱码出现。而 URI 编码两次后, request.getParameter(String) 函数得到的是原信息 URI 编码一次的内容。接着用 decodeURIComponent() 方法,将已经编码的 URI 转换成原文。! F" Y, g, Q- [- p
3 a4 _# c8 T+ [3 u" B
URL编码& `: I! |! X& F6 m( p* f
一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址 "http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。7 T# y5 w" i2 d5 n+ `
这是因为网络标准RFC 1738做了硬性规定:
5 ~3 V+ C" k( ~) `8 ][0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL
1 Y- P8 h1 O. F$ O# c7 Z这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。
]* I$ j. r; Q% e: G4 _" Q! `
% [$ V1 x7 N# c* e* b C下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法
* q" {! t" T4 \, \
& ]1 _. W5 @4 _! ?, h8 y二、情况1:网址路径中包含汉字. H4 v r) y5 x
打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。
1 A) s4 A) V7 F/ F" e+ {查看HTTP请求的头信息,会发现IE实际查询的网址是"http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82"。也就是说,IE自动将"春节"编码成了"%E6%98%A5%E8%8A%82"。我们知道,"春"和"节"的utf-8编码分别是"E6 98 A5"和"E8 8A 82",因此,"%E6%98%A5%E8%8A%82"就是按照顺序,在每个字节前加上%而得到的。在Firefox中测试,也得到了同样的结果。7 J" w4 h9 ~! o& W
所以,结论1就是网址路径的编码,用的是utf-8编码。
& [& `) `* m ~ M/ I4 c
/ {/ t' S n7 G7 M$ e三、情况2:查询字符串包含汉字# o7 e! T8 f6 k' C" w1 H7 n
在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。
0 P( T: S! k! H, ~: G6 z查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。
5 d8 Y7 W( c" Q# R切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。
* m+ M0 n; F* I6 b- W1 h* X; f+ d$ O
Firefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。' Q1 P1 Z! r' e
所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。" f2 a/ L/ _- y5 H9 O! B
: Y9 G% T! B- N8 O
四、情况3:Get方法生成的URL包含汉字
8 ~& O* p9 M+ {. J0 R( i前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。% I6 U1 F. V" H* w
3 r6 L5 I5 ~) P: S3 e% D
根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。
5 B/ k: {! f7 b6 E" O6 J; e" u ] M! q+ d7 E5 Q5 v
<meta http-equiv="Content-Type" content="text/html;charset=xxxx">
3 b% t! R K# y/ k; ^0 A- z) M+ ~/ P& }2 T9 ]& X3 ]5 b
如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。( b" _: y6 L" r& Z3 X8 B+ D
4 Y8 F( c }- V) P: E2 a+ u
举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。. g, V* ^: Q! B0 b4 @: S7 p
0 d1 I# `' s) Y4 G3 C百度生成的是%B4%BA%BD%DA,这是GB2312编码。
/ z2 e2 w; z T! aGoogle生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。
9 Q0 |* D, O6 X3 i结论3就是,GET和POST方法的编码,用的是网页的编码+ q% A2 }0 }) p D' W2 {* P) I. a# i
6 X6 Q( O+ D& d9 s五、情况4:Ajax调用的URL包含汉字9 A4 x# k! m2 p0 I5 t
前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。! R( B2 |7 |1 K$ A9 \
$ {, m% S+ }" u/ v# ~举例来说,有这样两行代码: ^( |2 M7 i, Z1 ?& N6 x
url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字7 ~. i6 L! w2 y3 ^! }
http_request.open('GET', url, true);
( L o: O- m' r5 m/ V那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。
* B; o9 R; A* O, n
* [. E4 {* n, f' E+ n. C( L六、Javascript函数:escape()
& z, c% |( Z$ b. h4 V/ A6 Q好了,到此为止,四种情况都说完了。( \* { \* f6 U" l" u" u
假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?
% L" r( \$ w" t2 M: `* n3 Y! R
" k, a9 V5 h/ R4 \% X回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。
8 }6 S6 {' ?( m ]7 M7 K+ a5 O4 [: ^0 n' j
Javascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。
. F& Z) @' X% L( b H
$ w+ ]& [6 [3 L( S3 l8 u实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。
# H' y4 n* F- t8 z) `; w( a; C它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。
. w& M2 g, A" D! P3 T* w* r/ ^
! Q6 l% p2 k! R' Y所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。
/ \: f7 @! V" N还有两个地方需要注意。
K* i3 Q) K8 U$ w9 M% e
1 B' C- g1 d4 c3 X1 z+ T, k首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。
/ |& w& A8 G. F# \7 J) E% d. G其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。2 x9 U1 T. D% O1 D3 }
. s8 P# Q) ~4 u1 Y4 A七、Javascript函数:encodeURI()
: h. Q, j" C/ i, i! J" jencodeURI()是Javascript中真正用来对URL编码的函数。
3 O/ J: B2 r" b- d! p# Z4 z% Z2 s! X$ L5 m! e
它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。
! a* w& r# a- I, R1 G它对应的解码函数是decodeURI()。
: t! C3 y) K7 g" q需要注意的是,它不对单引号'编码。- Z( D" w( M1 k- Z: G4 m8 M
( T! T' J( W( @4 D
八、Javascript函数:encodeURIComponent()
6 o5 j0 R, C) T: I0 L' v0 Y
$ R0 ?2 h. W4 m* D7 W6 p$ d最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。
[+ g" m; z$ m2 }( _( A* c R$ }1 y# \% V. m( Y1 `5 H+ I/ o% O8 B
因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。+ b4 B) i% S0 m5 A) @1 S* q2 U
它对应的解码函数是decodeURIComponent()。" [5 _& j4 [ C, k8 P3 i) A" k7 B1 J
+ |& {! p& C5 Q, O1 v" pencodeURI为什么要用两次' e! R# V7 g1 f6 z( J9 Y# L
一般情况下, 发送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
6 W- I. ~" y9 U" [) S% w接收时, 直接 String paramValue = request.getParameter(paramName); // 容器自动解码.
; b6 @2 w6 h3 j, W
: |/ \. J" q! {! e. i我们知道 encodeURIComponent 使用的是 UTF-8 编码规则来编的.2 ^5 n8 E5 s I& k+ F
如果 request.getParameter(paramName) 时,容器也按 UTF-8 解的话,是正确的. 根本无须在客户端进行二次的 encodeURIComponent(...)/ N$ y/ F: X$ W$ x X
" a2 B; W$ P c( D
0 ~! q9 p9 H# @5 L0 {如果 request.getParameter(paramName),容器没有按 UTF-8 解的话, 结果只有一个,就是乱码!0 O0 I, e. A6 b4 G1 k
容器按什么编码来解码,决定于 request.setCharacterEncoding(***) 或者 服务器程序配置./ m1 e9 V5 K/ M$ S1 a7 E
: N2 c, n' s2 {1 a3 U G. K9 h6 g如果你在 jsp 程序中,能够 request.setCharacterEncoding("UTF-8"), 并且 修改服务器配置,让容器在解 GET 提交的参数时,使用 UTF-8.1 w y5 q$ ?" Z7 t
" [7 \' k G' Y# I2 I
客户端提交前不用二次编码, 接收时,也只要直接 request.getParameter(paramName) 即可
* f8 T" `/ R( X7 t3 U p) S5 Q1 E A3 B/ J" v( W2 G
为什么网上会有人提出在客户端对字符串重复编码两次呢.
" Z3 A* R& e$ v* f6 f1 S$ N- H! t如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数, 比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东东搞得晕头转向,不懂得如何正确的去做好这接收参数的工作)- f% u1 C! l: y8 G0 m/ `
这个时候,在客户端对参数进行二次编码,可以有效的避开"提交多字节字符"的这个棘手问题。% V- r9 @0 H4 ^4 U/ b. O. _& Z
因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)0 G/ `& g# e, s( R! Y# j
再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])
4 `+ E, l; h8 O% W6 Y然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。; [3 o( n* A1 y% d6 V/ w
5 f$ i2 J- Y5 y7 L3 ]8 x0 j
|
|