TA的每日心情 | 衰 2021-2-2 11:21 |
---|
签到天数: 36 天 [LV.5]常住居民I
|
var gradeName = encodeURI(encodeURI($('#paperGrade option:selected').text()));//编码 " d6 i+ C9 m) S6 }5 X
var gradeName = decodeURIComponent('<%=request.getParameter("gradeName")%>');//解码
# L2 `% X" l' W i, Y为什么要连续两次调用 encodeURI(String) 方法? 8 B$ C! |0 L- H7 k
是因为 java 中的 request.getParameter(String) 方法会进行一次 URI 的解码过程,调用时内置的解码过程会导致乱码出现。而 URI 编码两次后, request.getParameter(String) 函数得到的是原信息 URI 编码一次的内容。接着用 decodeURIComponent() 方法,将已经编码的 URI 转换成原文。
$ ]8 V8 _8 x1 H& U8 T" k1 J
: N( z' {# }8 S# o1 v- p/ W fURL编码
9 W( c1 n4 L' Q6 X* X. a0 ^7 b0 N一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址 "http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。
( K6 r! B- V' i这是因为网络标准RFC 1738做了硬性规定:* K; ^$ }8 n! G/ ^) t
[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL% Y6 ~9 X- w \3 s: k/ B
这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。$ b2 {9 L$ D- s! r- F0 u- |
& F! Y4 q: H9 G2 e$ c
下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法; I+ G6 F7 i/ A* k
1 \: D& Q( d/ B0 L0 [0 J# f5 u二、情况1:网址路径中包含汉字, r/ t p. k. K* f6 K j
打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。
1 a6 D# ~4 ], x$ v) t! m7 T查看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中测试,也得到了同样的结果。, v% E/ n' R, p& v8 x/ I* u
所以,结论1就是网址路径的编码,用的是utf-8编码。! Y. P& e; r% \2 n" a8 r
" c! M# y j6 \* {6 Y" {; J" T
三、情况2:查询字符串包含汉字0 C4 N9 g/ |* e5 H3 x# q
在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。
2 S8 q) `% v( ], q( Q2 V) G查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。- N) C. t8 ?5 M) ^# x+ ~; m
切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。) ]+ U5 P, h/ K; g9 W- i
/ I: z) V1 d+ f2 BFirefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。
) j5 E. k' U# X* n% ^+ p) m0 v) q$ z+ B所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。! I4 q# a0 A% ]3 T
4 H+ O6 U& [2 x1 m# u J
四、情况3:Get方法生成的URL包含汉字; A/ J2 ^0 u) C! G. O9 P. U" L
前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。8 n+ _! i3 q' `/ V# x2 _
) l8 E& ?8 H9 h0 n+ D根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。
" @! a) Z9 C- u5 c$ A% F) D8 B- M. D$ b6 H: A
<meta http-equiv="Content-Type" content="text/html;charset=xxxx">% t% z. B- i( h3 k
. U s* S: M7 F1 N. s如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。5 d" ~+ Q! v# C/ }3 y/ I& I
0 \. n, V2 f; f0 t$ n$ E* a5 m6 q
举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。
, e1 {- V" E8 J3 f( Y+ T
% [! e2 W% w4 s4 d- y百度生成的是%B4%BA%BD%DA,这是GB2312编码。
/ s! r- w, i- w) R2 _2 qGoogle生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。! ^9 m5 X- a$ j9 Q) \8 B7 Z( {0 ]
结论3就是,GET和POST方法的编码,用的是网页的编码
& [4 B6 f1 W& H: u) i
1 K" j) H, c$ G1 i& o. h五、情况4:Ajax调用的URL包含汉字
# r, `$ U, _6 Q. v2 i前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。
) E5 J8 \6 l! ?0 F* H/ N8 M' |9 q' f6 j5 w# X( C
举例来说,有这样两行代码:
4 w! q1 s! v7 h url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字
2 t; Y0 ~& z8 m% E. Y" h http_request.open('GET', url, true);& s$ C- x) w P: c9 N# G) h( E% |
那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。: @6 [* U" D* s- D' s5 l, T Q4 t/ s
- {, `4 c1 S- @9 ]! t六、Javascript函数:escape()
* X4 B9 E; N9 l1 I! K3 }好了,到此为止,四种情况都说完了。* b b4 v; P+ g2 _( d( K* w
假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?% I1 b5 K# t$ F9 Y1 O- u% q( R5 X
) N8 |. ?: {$ y1 t+ O+ o' M回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。( S4 |3 D4 B( H, ^
0 v1 @2 F( [- m* B; Z- gJavascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。& z- |$ ^* ^2 ^: @; {% T5 m* R" Z0 J
# ?9 Y) S# j4 l8 m4 C ]# F V实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。
. Q& G. _1 V5 T. [8 e- i它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。 S7 z0 I. F: ?& a) m$ b
4 M8 C/ Y- ?" {9 t
所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。4 [/ o, }- l$ L2 ~! Y# N# H
还有两个地方需要注意。' ^, Q' [3 H. G( Z! m
6 s5 x1 b$ g0 o0 \; u4 c+ A+ l
首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。
# w0 P* I5 |4 [$ Q2 D' G" _# q其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。1 v* I$ I n% l! }
3 C' V( f. L3 V8 L$ ]( ~七、Javascript函数:encodeURI()
+ O" _9 o- i4 h; A3 t vencodeURI()是Javascript中真正用来对URL编码的函数。8 B7 C+ A1 c" K; O
6 m- h/ ^- n* H( y: Q) r( ~
它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。$ e a8 n' ?5 ` V3 U1 ]
它对应的解码函数是decodeURI()。
8 u$ o% Y" d% }需要注意的是,它不对单引号'编码。+ G( f4 w3 x9 w
( U4 G$ h5 S, B' H4 c+ b八、Javascript函数:encodeURIComponent()9 {* O1 C5 ?( Z8 e, ~/ P8 W
0 T2 l/ l4 [9 O% k
最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。2 f$ `; V9 z' z1 I+ j
. Z( ~" u6 f# ?/ [因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。
5 W8 J; E, A1 Z; d/ i( `" O它对应的解码函数是decodeURIComponent()。
5 R- O- U N* b7 k0 E
4 K1 h7 P o# g$ Q' _encodeURI为什么要用两次" e) m6 V- ?1 T, X [
一般情况下, 发送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
( \: g* ~3 y; |3 z: D接收时, 直接 String paramValue = request.getParameter(paramName); // 容器自动解码.
0 x1 ~" s" g& m' G5 d u u
+ C, D* S- m7 q我们知道 encodeURIComponent 使用的是 UTF-8 编码规则来编的.
3 ~5 S/ J% ` t/ B如果 request.getParameter(paramName) 时,容器也按 UTF-8 解的话,是正确的. 根本无须在客户端进行二次的 encodeURIComponent(...)
! u" j7 v( F. r1 i8 d# D( i$ C
K! M. \! \" H/ J
. x: Z9 P$ o, H8 e; x. L/ \9 v如果 request.getParameter(paramName),容器没有按 UTF-8 解的话, 结果只有一个,就是乱码!
2 U4 [9 F6 f5 V8 b容器按什么编码来解码,决定于 request.setCharacterEncoding(***) 或者 服务器程序配置.' ^, p, @- S A6 Z
0 q3 L6 E$ X. a
如果你在 jsp 程序中,能够 request.setCharacterEncoding("UTF-8"), 并且 修改服务器配置,让容器在解 GET 提交的参数时,使用 UTF-8.
- j. ]8 S* o+ {) U2 ^0 A& w
; z9 Y6 |0 [* Y! @& H客户端提交前不用二次编码, 接收时,也只要直接 request.getParameter(paramName) 即可
. s1 ~0 z, `- V+ j- {! ^9 E% L* ?8 @7 k/ T( k* O% S
为什么网上会有人提出在客户端对字符串重复编码两次呢.9 k3 W, R& |) ?
如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数, 比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东东搞得晕头转向,不懂得如何正确的去做好这接收参数的工作)
: A2 B- Z$ |1 ?. G/ S这个时候,在客户端对参数进行二次编码,可以有效的避开"提交多字节字符"的这个棘手问题。. ?' t* k+ @- \' F% M T7 [0 `$ c. T! ~
因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)0 b, Y" W* c8 F4 L9 s
再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])
7 g' \) r' K2 X/ K) t, q. o$ T7 N然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。
O' i5 Q/ w6 ^' s6 b& {9 V, o# ?1 s+ g D0 q7 W; s
|
|