TA的每日心情 | 衰 2021-2-2 11:21 |
---|
签到天数: 36 天 [LV.5]常住居民I
|
var gradeName = encodeURI(encodeURI($('#paperGrade option:selected').text()));//编码 - F5 O i! k! T9 \- V& O
var gradeName = decodeURIComponent('<%=request.getParameter("gradeName")%>');//解码6 o$ g3 x3 @5 A& _8 c0 _' C( Z
为什么要连续两次调用 encodeURI(String) 方法? # f( {& \8 v5 X" Q
是因为 java 中的 request.getParameter(String) 方法会进行一次 URI 的解码过程,调用时内置的解码过程会导致乱码出现。而 URI 编码两次后, request.getParameter(String) 函数得到的是原信息 URI 编码一次的内容。接着用 decodeURIComponent() 方法,将已经编码的 URI 转换成原文。
. ^8 o1 q j/ Y/ T3 O3 d2 u3 U+ q& O: H
URL编码
8 n" h' M) B/ {, i k( h* E( U) l/ s0 h一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址 "http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。
6 T* q+ m2 C/ O7 ?2 j这是因为网络标准RFC 1738做了硬性规定:
0 y8 E; s" Z9 p0 i[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL
, ]9 Y* h0 G: \$ o5 {# q( o这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。$ ?$ F& H: A. G) n9 I
5 A1 z& L+ n6 s/ W4 q
下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法
, A0 _* x1 `8 v" b: [+ [. h9 R
- }9 V# V! m/ ~6 ]二、情况1:网址路径中包含汉字
. k- @; L# |3 F打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。
7 Y4 A2 L" Q. I9 U8 h查看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中测试,也得到了同样的结果。! h$ B6 K' c7 _0 ?- r2 c. p
所以,结论1就是网址路径的编码,用的是utf-8编码。
: r1 J- S9 v3 @) ^. ]' Z
( Z5 h8 R1 m9 {2 z三、情况2:查询字符串包含汉字5 e+ L' E8 q! R2 F) U
在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。
& z1 @5 X' G2 r查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。! E% V/ M2 a; H, m+ N3 r
切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。
) |6 B; J( K4 O3 k, b& K& S
2 v2 O1 c q6 [/ J8 P& PFirefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。8 Y t+ y5 j" H% E' E5 `, ~
所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。% X' k0 i' ]1 s! j; g- F
3 \ c% v+ w* ^3 I, b* w
四、情况3:Get方法生成的URL包含汉字
2 M( |/ r0 V- ?/ [6 ?5 f前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。, @. {1 N4 q5 t$ u4 d: a
0 B8 _$ Q) c$ I$ l, ?/ P0 d
根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。5 H _1 ?$ Z! G V, J4 A7 Q
- [5 o, W& y0 b. F- e+ o1 g9 ^- Z3 j <meta http-equiv="Content-Type" content="text/html;charset=xxxx">" k, p; A6 u2 h2 L( N
. P5 O( F! N! I如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。
* W/ a. X9 g Y: }4 k* K3 j$ J! D0 b0 N
举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。
: ~ q4 \' T H$ I- W4 ~0 l7 s' y& D+ z) s
百度生成的是%B4%BA%BD%DA,这是GB2312编码。
, d% B+ j0 t' B- v; DGoogle生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。
4 M* Y8 d" y; g4 q# E结论3就是,GET和POST方法的编码,用的是网页的编码1 R0 @9 T& b1 ~$ o {+ ^/ a) w
( }- W' t9 }4 r: r' `8 J* v5 Q五、情况4:Ajax调用的URL包含汉字! M$ h( y& }! h' D# {+ f2 W6 o: {$ F9 p
前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。" D! C2 d5 J. c& H5 u- u
0 ~9 A# h0 n9 ] l9 p, |
举例来说,有这样两行代码:- M, V( a1 l& t, j
url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字: V$ e& P2 t+ V- ]
http_request.open('GET', url, true);
7 R2 |+ K8 d. z那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。
) _% Z- e* X& S+ C v+ w3 h( g: x; d G( w6 Z; ?2 L
六、Javascript函数:escape()( Q/ |# j. _7 o3 E4 d7 b% a
好了,到此为止,四种情况都说完了。
* [( O$ _0 q) r+ ]- |假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?( F6 F. N) I" f2 V' R( ]! M- U
$ y) C& E: N) @. m; ?6 r( A
回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。0 K, g* |8 P G# ]
7 B$ U9 ~ m& Z: @1 D! k
Javascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。/ q- n6 w5 x4 G, M8 T8 V
/ T6 S' r* ?0 B6 y; R: Y) b
实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。
W: z% v# J, ]" p8 y8 K它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。# L/ S" [8 j% h5 c l& c, v$ B8 I
8 V. U; ^9 z" B4 C( f; @
所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。
6 M2 a; ?; {4 r8 Z' ?. H还有两个地方需要注意。
7 U' t8 S3 `7 Z8 {: `) G$ I( k! d! o- m4 B
首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。
- ^3 }- Y& f% L# I6 \" S其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。' s1 B1 U. |4 `3 R+ c
0 G4 V$ T5 [3 o* _七、Javascript函数:encodeURI()
9 ^" u7 j! J' U# E/ t6 PencodeURI()是Javascript中真正用来对URL编码的函数。/ p: p, E9 B& M" b0 ]) p5 S- f
- i0 o0 j6 K) @6 h3 y它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。
, v# Q4 R* E9 ]6 \" P$ a( a它对应的解码函数是decodeURI()。
! o& j( O* g. z% e) B0 ]需要注意的是,它不对单引号'编码。
8 D0 w0 V7 q7 z; g# f4 `6 W5 k# Z; {" \* d; b
八、Javascript函数:encodeURIComponent()
- h* l6 B, I! w
: p: J2 f" Z8 L: P最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。
0 g# i: f) O2 h3 Q- P2 O2 `% m; z
% r6 D5 d. @7 S' Z, i0 ~1 e7 N4 y1 q因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。 B( b# r3 e6 n6 K- f9 p1 E1 ]
它对应的解码函数是decodeURIComponent()。1 |9 z% `8 f2 k2 l" ?" p0 a5 u" `
: w- d& m- M# H+ R: j( {% m: d9 pencodeURI为什么要用两次
8 e- ], `2 _$ O$ M9 |6 c7 n# C0 f6 A一般情况下, 发送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);, `: v r$ W: u
接收时, 直接 String paramValue = request.getParameter(paramName); // 容器自动解码.
2 W+ r9 j" A8 K' ~" k9 q
! p8 M$ \1 w+ E我们知道 encodeURIComponent 使用的是 UTF-8 编码规则来编的.; r5 O8 h R* g
如果 request.getParameter(paramName) 时,容器也按 UTF-8 解的话,是正确的. 根本无须在客户端进行二次的 encodeURIComponent(...)+ E; o' G9 }' a, ^5 P1 F
; X: j( _4 I1 t$ B
! j. X. ?% K3 L0 D+ u
如果 request.getParameter(paramName),容器没有按 UTF-8 解的话, 结果只有一个,就是乱码!
$ ~3 E4 X8 I. x& T- @容器按什么编码来解码,决定于 request.setCharacterEncoding(***) 或者 服务器程序配置. s1 [2 f2 d- X* ]6 }( W5 ]
# m" K7 k7 P5 @ a2 n( ?如果你在 jsp 程序中,能够 request.setCharacterEncoding("UTF-8"), 并且 修改服务器配置,让容器在解 GET 提交的参数时,使用 UTF-8.& Z2 p( ]8 ~. S' Q
3 T( j7 ?, k% \* y. K' k( s7 }
客户端提交前不用二次编码, 接收时,也只要直接 request.getParameter(paramName) 即可- e' L0 I9 G- _$ _1 _
. Y+ i4 v }1 ~) @' z为什么网上会有人提出在客户端对字符串重复编码两次呢.
7 K6 v7 [3 N5 z5 i如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数, 比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东东搞得晕头转向,不懂得如何正确的去做好这接收参数的工作)/ G# q# q1 l2 h9 U! m6 D- a5 ]/ C
这个时候,在客户端对参数进行二次编码,可以有效的避开"提交多字节字符"的这个棘手问题。
9 R- @6 A/ n5 S3 r, O因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)+ u# [! y {6 E! {: x, |
再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])9 y0 U$ z5 x! E# U
然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。, o/ w( z0 U4 }, K0 A
) q1 h* |( O3 `: b |
|