TA的每日心情 | 衰 2021-2-2 11:21 |
---|
签到天数: 36 天 [LV.5]常住居民I
|
var gradeName = encodeURI(encodeURI($('#paperGrade option:selected').text()));//编码
2 e& s4 x- r" x2 gvar gradeName = decodeURIComponent('<%=request.getParameter("gradeName")%>');//解码" f( w% U" \, V4 u: P& q
为什么要连续两次调用 encodeURI(String) 方法? : V/ C% M J; v; \1 S) Z$ u
是因为 java 中的 request.getParameter(String) 方法会进行一次 URI 的解码过程,调用时内置的解码过程会导致乱码出现。而 URI 编码两次后, request.getParameter(String) 函数得到的是原信息 URI 编码一次的内容。接着用 decodeURIComponent() 方法,将已经编码的 URI 转换成原文。
3 B8 ?# Q6 u" W# c p
- V& G, l* s; c! G8 \8 ?- SURL编码, G9 X- i3 }+ y0 u" y$ A( p
一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址 "http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。
2 C& g7 Y, y( B2 L! W- v9 y这是因为网络标准RFC 1738做了硬性规定:; K+ x8 Y# Q/ R/ j8 ~1 D z
[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL: P/ w" }% f0 r' p3 e% D! i
这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。
( k3 M! Q2 z1 F3 L) B& _- B
: f% i! C7 w" |下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法3 D5 I4 E; \1 z5 X
/ C% {% g d# T6 o% d0 E
二、情况1:网址路径中包含汉字
$ V' \; T+ W. q1 I打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。
# j- k. _; L9 m6 k+ l; y查看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中测试,也得到了同样的结果。/ I3 i# M, w6 K, k; n
所以,结论1就是网址路径的编码,用的是utf-8编码。
/ Q9 ~* c$ |" d, ? K- a+ B4 j; e( y- n8 L( R* g' n- u! y2 q
三、情况2:查询字符串包含汉字7 X" s2 l- Z1 t
在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。
# l% B" C9 p$ {- `查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。
: @5 i7 {6 I3 ?/ f- P$ i切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。
! U4 N/ X8 W; P5 w3 @" W( z; F) Q
! H( s, ]& Y0 `& F; w0 C WFirefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。
1 j6 _1 P& k/ [所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。
( `$ C. z [* Q r c
& c3 D; j% `+ Y l+ a四、情况3:Get方法生成的URL包含汉字
, c! G9 u, z4 i$ r; N( n: |前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。9 c0 _& K2 d+ ?
4 W8 t# r& v6 \0 t! a+ H" V根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。1 T4 |2 r |1 f9 b5 \
* v2 [3 X* M7 }9 u <meta http-equiv="Content-Type" content="text/html;charset=xxxx">7 y8 Y& a. T3 m! u
0 C2 l; Q% n: Y1 B M" k9 L2 l1 H
如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。$ d: f# _6 R( k" q
! H/ x' f. |6 l- u. B }8 F- e举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。
4 M7 ^1 T6 [$ Z& @
/ r/ P: ^7 j5 n* q4 u* y百度生成的是%B4%BA%BD%DA,这是GB2312编码。
% V, e/ `+ S) `: O! V) T; JGoogle生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。7 z* V, T' {. s. H: L
结论3就是,GET和POST方法的编码,用的是网页的编码# @$ c) \4 C# x
! n* U! i% `2 s
五、情况4:Ajax调用的URL包含汉字2 Q9 E4 R4 A8 g: P# p
前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。/ r w) c. K6 Z. a) \
/ d/ R7 n- g, C; J+ h; N# O* |& x6 I
举例来说,有这样两行代码:% ~4 f, @$ ~# w0 b' i
url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字' Y! o, J+ ?0 Y* c' n8 J. h* x
http_request.open('GET', url, true); \1 s9 n1 q( T' A, P1 I# W; C
那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。) n% d- |, ~8 H7 F( ~
1 I5 L4 S3 h* U1 q: p7 L$ U
六、Javascript函数:escape()( M- i; ^, @" H: R4 R4 \; \' q+ U) r$ M
好了,到此为止,四种情况都说完了。
M6 G4 Y8 Z8 U0 [假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?
' ]" @5 F3 W" E, A6 w5 A% @6 y- z2 u3 K8 v6 B* @% V
回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。8 [- A( w2 M7 B; l) u+ [: S5 \; |0 g
* C. S* }8 U3 ~. l& A1 `* h
Javascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。
0 r w( h8 x( U' Z
' y/ n+ c: v/ B实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。5 b2 A$ n* _- |' u' M2 I
它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。) w& j; a1 f1 z2 s* K3 T
6 Y8 l' q1 O% B( t5 u
所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。
9 T% `3 y7 T0 i+ S还有两个地方需要注意。! y+ E5 L# Z$ \: l
3 p& v5 r+ p. w0 j1 F$ [. p首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。
6 C8 P" e; T' q' g# r: Q! r4 i其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。0 q7 b1 R( Q; w, y5 l! {5 t0 H
0 Y0 ?- R4 R) o1 z3 h1 ]/ E
七、Javascript函数:encodeURI()/ @, \0 g5 T* t& C# L5 M* b
encodeURI()是Javascript中真正用来对URL编码的函数。
; t% s. d! K" v4 K( r0 i
! I5 W4 [% h8 C1 B% |* M" v它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。2 Q& ^6 E% V0 ~: t9 m6 u
它对应的解码函数是decodeURI()。 ) b% ?. t. d5 P& d
需要注意的是,它不对单引号'编码。! _9 Q8 r/ g$ ^& J2 u
. {7 S8 B/ \$ J# R$ d4 |! E# W八、Javascript函数:encodeURIComponent()
, [. v" k& _+ {/ G; s" X5 | g- i, Y! b9 [
最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。
% {" g4 v7 n. u# r/ g7 v) t# v
J/ H8 \$ [2 f因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。
P* i, _+ Z( L+ ^0 \$ D9 c6 s. D它对应的解码函数是decodeURIComponent()。& s g* C) g# G8 {) K; ]
. f+ P' Z5 P# [/ e, o) ^7 V% W
encodeURI为什么要用两次2 V+ B( u% l# T( y9 C3 |
一般情况下, 发送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
; i3 D8 j8 D8 p% X" P接收时, 直接 String paramValue = request.getParameter(paramName); // 容器自动解码.
' v, C6 l, d7 f; D$ e9 d$ N% d& `; n/ U' j$ W. E
我们知道 encodeURIComponent 使用的是 UTF-8 编码规则来编的.: d$ d( V& ?# p2 V' m# o; }, S
如果 request.getParameter(paramName) 时,容器也按 UTF-8 解的话,是正确的. 根本无须在客户端进行二次的 encodeURIComponent(...)- T9 C1 d$ }) e, A
0 _3 |8 l- w) S4 i; Z5 G$ h
f/ Q$ L. N2 A$ E
如果 request.getParameter(paramName),容器没有按 UTF-8 解的话, 结果只有一个,就是乱码!9 x* B* B0 b5 r3 c- S' C
容器按什么编码来解码,决定于 request.setCharacterEncoding(***) 或者 服务器程序配置., @/ ^% N8 ~( ]# z7 s& N! |
' p* a. Z ^5 B5 g4 V2 R4 f$ a( U如果你在 jsp 程序中,能够 request.setCharacterEncoding("UTF-8"), 并且 修改服务器配置,让容器在解 GET 提交的参数时,使用 UTF-8.2 T+ t) `, m6 N6 z
8 s/ c# [- i) q. u$ e- G客户端提交前不用二次编码, 接收时,也只要直接 request.getParameter(paramName) 即可 z. X( R( M6 L; P% p) K
3 n, E; F9 Q3 O$ n为什么网上会有人提出在客户端对字符串重复编码两次呢.
* K9 I7 f, o* w X如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数, 比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东东搞得晕头转向,不懂得如何正确的去做好这接收参数的工作)
' b( U! V% f+ [) R8 V1 n# ^/ I这个时候,在客户端对参数进行二次编码,可以有效的避开"提交多字节字符"的这个棘手问题。
3 D' N5 \& ?' g, l- l( _因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)6 v/ V- r( V; ` A$ c( n4 W' l
再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])
, Y* D) A+ V/ c然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。( e$ p/ B0 P; X" m8 Y5 \
) ?2 F8 B+ t( a) w, @% O# a
|
|