TA的每日心情 | 衰 2021-2-2 11:21 |
---|
签到天数: 36 天 [LV.5]常住居民I
|
var gradeName = encodeURI(encodeURI($('#paperGrade option:selected').text()));//编码
; P3 h" p2 }5 E* R* |var gradeName = decodeURIComponent('<%=request.getParameter("gradeName")%>');//解码4 }2 o) L- C) P) \( |
为什么要连续两次调用 encodeURI(String) 方法? * H( Z* W& l, m! U& Q1 I C
是因为 java 中的 request.getParameter(String) 方法会进行一次 URI 的解码过程,调用时内置的解码过程会导致乱码出现。而 URI 编码两次后, request.getParameter(String) 函数得到的是原信息 URI 编码一次的内容。接着用 decodeURIComponent() 方法,将已经编码的 URI 转换成原文。
1 g. ?" v7 }- ]" b7 E8 }2 d2 u$ o1 ?7 e& `; F4 p1 g& t
URL编码% O7 r2 c, F$ @# w/ N4 V
一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址 "http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。
6 U& ]2 W! c' d1 W6 z这是因为网络标准RFC 1738做了硬性规定:; [& Q- F7 ?8 ?7 B/ x+ B3 \# `
[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL
/ l* S6 F0 R- V' ] u这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。! q6 v! @8 L; |) J
1 c4 C( r& {- N7 L0 l下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法
0 ?! r( |/ C+ b7 ?" W) {" X$ ^8 n
1 _# r# z1 }- A二、情况1:网址路径中包含汉字
) K( U1 ^0 \# g% {# w9 `打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。
, T' v5 d- Y8 J5 G查看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中测试,也得到了同样的结果。
* c- x0 U i, F" J2 r: B) L2 r) ?) h. v所以,结论1就是网址路径的编码,用的是utf-8编码。
n& _. ^' J9 a& h5 b% s
& T* E! }3 R! U% L三、情况2:查询字符串包含汉字
+ k2 }! v2 j4 k$ V" b/ I在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。; h: ~1 b, C) J
查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。8 }7 r- s4 m0 Y: m6 ^8 R& y4 C# V
切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。1 {6 v8 j- S% v6 u
s1 W/ y) Y8 S" y' `, g W
Firefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。
8 e! N/ Q" o4 E! Z所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。 T& {# I( T( P% ~- X7 F' ~
/ m+ Z0 j d2 _5 R v2 c
四、情况3:Get方法生成的URL包含汉字6 E! N* [: w2 t3 Z
前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。+ o5 s& M# Y0 ?0 S, J% K
+ C9 @8 ?* Y# [5 F" f0 S, b根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。
" L1 [& L) m7 {1 C6 F2 W7 z( s) M
<meta http-equiv="Content-Type" content="text/html;charset=xxxx">$ D+ ?9 a% I7 \4 p; n1 z
- O5 B! e& c5 j) X" F% q如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。
8 M" Y' N: z/ `- U0 s4 N- v
1 d$ o( R2 K. F8 @* @* F举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。
( G8 q& ?' b5 D5 o' Y* w# X
# S3 N# }- o+ C8 `& \0 A" F2 }百度生成的是%B4%BA%BD%DA,这是GB2312编码。2 e# Q1 b" T" O+ ?8 ]6 N
Google生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。! t( q8 Z& H# i* ]- W
结论3就是,GET和POST方法的编码,用的是网页的编码
1 }) p! P4 k, p j V$ M+ e# u5 [9 `1 f) s1 e
五、情况4:Ajax调用的URL包含汉字
4 K. }+ v) y0 J前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。
3 X( W+ b) t" |, M* g' F; t6 X
4 ^ u7 e; q/ m举例来说,有这样两行代码:
+ K5 A# S1 }2 g4 u, s, H4 D& Q% z3 _ url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字- R! b5 V0 W. V% V* y# U) P9 H0 u
http_request.open('GET', url, true);- S1 v2 S' h& z# w* A X% Q0 r
那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。* }: V( h( J: u2 `
8 a& K) T4 X% n8 \$ b
六、Javascript函数:escape()
, W& M6 w. m' v$ p; Z0 Y好了,到此为止,四种情况都说完了。
% x. o- u2 ^* T2 @# |: Y假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?7 L) l: D8 g( x& h
7 i% r3 K" H" \: F, \- `+ y! X回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。" E: I2 {0 X, x# a7 x7 n0 I* A
5 I9 b8 h2 r2 n7 a8 n. p# m
Javascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。% ?! R" c# `7 b: T1 x) v
- G5 }+ ~6 E4 G4 @( |' f- Y实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。
4 [8 Q& e% q3 N* d8 \. V" ?6 {2 @它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。
/ O+ v2 c; ]: y- D; @( `- Q2 I
/ t# e5 t, _# X3 Q+ G所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。: Y7 Q: D: _0 ]3 r: Y' b
还有两个地方需要注意。
( l# q& N3 t3 @" x
4 ^( x! X5 V- `4 `; U9 K% B首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。- H2 e0 i' j* I; {2 a; O
其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。
2 b0 k8 G7 }9 V `, {; ]; p
1 {% I' L) @) n& G- g七、Javascript函数:encodeURI()
1 j* ], v1 u* W. h6 F, S# {encodeURI()是Javascript中真正用来对URL编码的函数。: E- T3 E; t# I0 ]4 O9 ?, h
- U# H/ d( L: F0 V r6 S
它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。 z% `8 ~* p$ `+ R& J/ D5 n6 O
它对应的解码函数是decodeURI()。
5 h% A. O0 o$ o; Z8 {需要注意的是,它不对单引号'编码。7 y8 }1 B1 K# L5 R5 Q. h7 g
; K& _" w3 A; [! U- J5 V& O4 C# u八、Javascript函数:encodeURIComponent(). H' Y7 ?! z; T4 r' l2 c
+ z8 q8 z9 ~3 Q* o' E8 Y" l
最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。
8 q+ D, b) O1 z2 T E3 z" b' ^7 I- ^* Y0 p# N. `
因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。
# Z" T: U1 W4 c8 E2 {它对应的解码函数是decodeURIComponent()。$ y# e3 z% ] }& S7 A
; w& Y5 B+ i* q( [; k
encodeURI为什么要用两次
9 e/ u( I" H& ?& y4 T/ g" C一般情况下, 发送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);! I. i# \# X' E' N/ B
接收时, 直接 String paramValue = request.getParameter(paramName); // 容器自动解码.
( t! \% F Z5 F- u# h" u( F" R7 Z `1 M; u; {) z& B+ j# @# h
我们知道 encodeURIComponent 使用的是 UTF-8 编码规则来编的.
, p& C+ K* |7 t5 D$ b6 S如果 request.getParameter(paramName) 时,容器也按 UTF-8 解的话,是正确的. 根本无须在客户端进行二次的 encodeURIComponent(...)
% z$ S3 ~; E+ Q7 Y: v2 \$ x9 ^3 h; y
& B) ]8 k2 i5 h1 B
如果 request.getParameter(paramName),容器没有按 UTF-8 解的话, 结果只有一个,就是乱码!
[1 y8 B2 t1 y+ C4 Y" {容器按什么编码来解码,决定于 request.setCharacterEncoding(***) 或者 服务器程序配置.% M4 \' z& J* g7 |& ?( O% T
: h9 \# t7 q& B% N如果你在 jsp 程序中,能够 request.setCharacterEncoding("UTF-8"), 并且 修改服务器配置,让容器在解 GET 提交的参数时,使用 UTF-8.
& | w0 J$ Y, i8 |+ P3 q9 f; w" g' E! Y) [* o8 N3 S
客户端提交前不用二次编码, 接收时,也只要直接 request.getParameter(paramName) 即可# p$ n( [6 @$ Z7 n
7 e6 M% m8 }! S3 Q! ^" T3 b为什么网上会有人提出在客户端对字符串重复编码两次呢.) i$ ~% y2 I% N! j7 M$ s
如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数, 比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东东搞得晕头转向,不懂得如何正确的去做好这接收参数的工作); u: z2 P# K3 m
这个时候,在客户端对参数进行二次编码,可以有效的避开"提交多字节字符"的这个棘手问题。7 f" F0 n5 ~) ]
因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)( n" ?) e: E" ~( _
再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])# B8 f6 U) k' a& K5 r1 X
然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。
, \7 q& M9 l3 g$ S6 S8 L
" g' R4 l* V9 V& B, A( D2 \: {; x |
|