我的日常

登录/注册
您现在的位置:论坛 盖世程序员(我猜到了开头 却没有猜到结局) 盖世程序员 > java项目前台向后台传递中文乱码
总共48087条微博

动态微博

查看: 1846|回复: 0

java项目前台向后台传递中文乱码

[复制链接]
admin    

1244

主题

544

听众

1万

金钱

管理员

  • TA的每日心情

    2021-2-2 11:21
  • 签到天数: 36 天

    [LV.5]常住居民I

    管理员

    跳转到指定楼层
    楼主
    发表于 2015-10-20 17:45:52 |只看该作者 |倒序浏览
    var gradeName = encodeURI(encodeURI($('#paperGrade  option:selected').text()));//编码
    . j: H9 G+ g3 y& K# Pvar gradeName = decodeURIComponent('<%=request.getParameter("gradeName")%>');//解码% N3 b7 p9 A$ T) L* X  V$ M
    为什么要连续两次调用 encodeURI(String) 方法? ' w8 v: P! W- M" D) U" @; W
    是因为 java 中的 request.getParameter(String) 方法会进行一次 URI 的解码过程,调用时内置的解码过程会导致乱码出现。而 URI 编码两次后, request.getParameter(String) 函数得到的是原信息 URI 编码一次的内容。接着用  decodeURIComponent() 方法,将已经编码的 URI 转换成原文。
    + r5 d7 S5 O4 v0 c$ \' M6 E- i2 ^' k9 ~; N" C  O+ C
    URL编码" {: D; H* b2 A/ @
    一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址 "http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。
    3 ^7 y4 w5 @6 z* p这是因为网络标准RFC 1738做了硬性规定:
    ; i! m1 S3 \3 `& N[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL  }& L( t* d. b. k0 A
    这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。& ~8 _% z. @: T! Y1 X' _

    ( G( M( f+ N4 o. }5 M下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法  c$ y# x( y$ Y# ^* o) T
    : E& @8 \' y; j, z! j2 ^& t
    二、情况1:网址路径中包含汉字
    2 U; o- T6 T( M% Z9 Z; J打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。9 D6 N2 R0 O  f' U, 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中测试,也得到了同样的结果。, d7 p0 z2 M& C2 z0 |
    所以,结论1就是网址路径的编码,用的是utf-8编码。
    4 c0 q4 p9 n3 J3 w  w
    9 h9 @% G; w! W1 [三、情况2:查询字符串包含汉字
    , i+ P" W. e. H# ]在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。. k: K7 ?2 R* m- z% p
    查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。
    * }  M  e; F. i- H- H8 z; V切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。
    8 Y1 I# v% q7 B5 o7 i' o0 C( V, H3 F
    Firefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。$ Z+ T# y) a4 V+ o' E1 ~6 f
    所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。1 R6 ^% p- g+ h; Q: ?) S, M( z
    ; N+ l4 w/ m% \
    四、情况3:Get方法生成的URL包含汉字/ o( E( @% D. T" j: R; N
    前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。
    8 g1 U) f" J6 A1 E4 x9 [4 ^+ a
    根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。. Z# l+ L8 e+ m; c" B& g
    8 I  \1 n) Q) L8 I0 x1 a8 \
      <meta http-equiv="Content-Type" content="text/html;charset=xxxx">7 E, d4 B, p$ f8 J( D
    2 T- ?  ~( N1 v' a) }
    如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。
    8 o4 l$ a& `2 i( |# ]0 z% O8 Z, {- B7 r
    举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。
    3 V- S  T3 w9 {- Z$ V& Y. A7 ^  u
    百度生成的是%B4%BA%BD%DA,这是GB2312编码。$ j& _; u4 v+ ]: E$ X  a
    Google生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。  a4 r/ \% `5 o8 H
    结论3就是,GET和POST方法的编码,用的是网页的编码
    - i9 x! J9 U+ A$ Z  Z+ }/ b! J& A! }+ z/ q
    五、情况4:Ajax调用的URL包含汉字/ d8 A* t' r5 D8 t2 s9 r9 V
    前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。" z4 z4 H0 z. N9 f% a9 F

    $ l" b& P$ w2 l: l举例来说,有这样两行代码:
    4 c$ H- O" ?7 L: U- D" U1 }5 P3 e  url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字
    * W2 i% A3 q. n) M% H3 u6 F  http_request.open('GET', url, true);& d" F$ b! S4 s+ y. l
    那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。
    4 _# l. A  _. Q# e9 H& e, f0 v  s; D3 U
    六、Javascript函数:escape()
    ) T' D- D  I* A4 T' X好了,到此为止,四种情况都说完了。
    # p4 j( p6 n& z1 e假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?9 B& k' x1 c: x) W0 i- u1 \
    0 P0 K& T" A) B5 O" ?6 Y' T5 R
    回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。
    ) X( T& K) p8 g, X' _, A0 f& X' f! r8 B' Z& U# v, Y5 }* {
    Javascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。- ^. l- W; s* k8 y; v

    7 w7 |. L# j# f0 k  O' a实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。
    . ]/ q- O2 Y0 H$ ~/ q2 v/ Z它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。
    ' Z$ t: \# v6 s2 q- c! B# ~( V6 y8 V
    所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。
    % {- ]* [4 ^: R还有两个地方需要注意。
    3 b+ t; ~; O2 I7 d3 z! \* B- b/ E7 L, u% x" D" C' H+ @( {
    首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。
    ' e% M& ^( `$ j其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。" D: L4 _; l" c, C
    1 [5 D& z6 a! G. ~# b- ]
    七、Javascript函数:encodeURI()5 B1 U7 I# ~3 N7 ~1 U8 A' D
    encodeURI()是Javascript中真正用来对URL编码的函数。+ i* B( B# L* N1 ^2 V- ?. J

    % w1 \8 X* ?: B它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。
    : J0 ?. i" R' C' c. U4 K它对应的解码函数是decodeURI()。 1 [7 L. L' v  z* I, O
    需要注意的是,它不对单引号'编码。
    + U! ~# O; b/ r8 j
      d, N0 A; B8 e! I2 X, }/ F' s6 @八、Javascript函数:encodeURIComponent()* t/ V- v4 Y! Q; @# c
    9 C& r; O, l- O4 F; i
    最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。5 f" _4 m: B$ J. C
    ( n' R) W6 z3 D' ~% {7 V% H
    因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。
    9 t: z9 |- A$ h2 Y8 I' @. Z它对应的解码函数是decodeURIComponent()。
    7 ]: J5 \4 n1 o6 c% X& T
    7 c' a9 R5 S0 E+ S. {, x: XencodeURI为什么要用两次
    " Y% T* F8 o/ k" ?" ^一般情况下, 发送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
    2 X1 ]) R$ ]' O/ D; q0 z接收时, 直接 String paramValue = request.getParameter(paramName); // 容器自动解码.; E0 \) y+ J1 @; y) G% f2 p
    - C& _& ^: J: y, f. N
    我们知道 encodeURIComponent 使用的是 UTF-8 编码规则来编的.8 m% }6 j) J0 s; C  I
    如果 request.getParameter(paramName) 时,容器也按 UTF-8 解的话,是正确的. 根本无须在客户端进行二次的 encodeURIComponent(...)
    3 O" e7 ^+ i  B; Y# K: C8 j; O' B
    & [. I3 c; m# P, r  t5 n6 ]. X
    如果 request.getParameter(paramName),容器没有按 UTF-8 解的话, 结果只有一个,就是乱码!. b$ I2 `8 `3 U( {+ B5 @
    容器按什么编码来解码,决定于 request.setCharacterEncoding(***) 或者 服务器程序配置.$ }  E2 q: \9 {+ A7 q

    * b& g+ Z( B" [, h; @9 v. J: \% ^如果你在 jsp 程序中,能够 request.setCharacterEncoding("UTF-8"), 并且 修改服务器配置,让容器在解 GET 提交的参数时,使用 UTF-8.. g) i/ Z1 Z1 `/ e  u0 z6 O

    6 m& }0 ~$ \  g客户端提交前不用二次编码, 接收时,也只要直接 request.getParameter(paramName) 即可; Y  J+ R9 O* g+ t
    % R! x. |" C3 n; _
    为什么网上会有人提出在客户端对字符串重复编码两次呢.
    . \& a% J& Q2 G2 D+ i如果因为项目需要,不能指定容器使用何种编码规则来解码提交的参数, 比如:需要接收来自不同页面,不地编码的参数内容时。 (又或者是开发人员被这有点复杂的东东搞得晕头转向,不懂得如何正确的去做好这接收参数的工作)
    ' I- r: }, t  R/ ^这个时候,在客户端对参数进行二次编码,可以有效的避开"提交多字节字符"的这个棘手问题。) d3 J; C" g. x/ q4 j& I" Y) ]- x
    因为第一次编码,你的参数内容便不带有多字节字符了,成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)1 ^9 ~3 q7 I- u. b) `7 B, W
    再编一次后,提交,接收时容器自动解一次(容器自动解的这一次,不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好,都能够正确的得到 [STR_ENC1])
      a: s# S! h& Y( M. |3 T! c) D, m然后,再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。
    ) Q' P3 k7 |+ [* L3 k0 n/ v$ ~7 l, ^8 ^9 Y/ }% q% J, ]2 _

    科帮网 1、本主题所有言论和图片纯属会员个人意见,与本社区立场无关
    2、本站所有主题由该帖子作者发表,该帖子作者与科帮网享有帖子相关版权
    3、其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和科帮网的同意
    4、帖子作者须承担一切因本文发表而直接或间接导致的民事或刑事法律责任
    5、本帖部分内容转载自其它媒体,但并不代表本站赞同其观点和对其真实性负责
    6、如本帖侵犯到任何版权问题,请立即告知本站,本站将及时予与删除并致以最深的歉意
    7、科帮网管理员和版主有权不事先通知发贴者而删除本文


    JAVA爱好者①群:JAVA爱好者① JAVA爱好者②群:JAVA爱好者② JAVA爱好者③ : JAVA爱好者③

    快速回复
    您需要登录后才可以回帖 登录 | 立即注册

       

    关闭

    站长推荐上一条 /1 下一条

    发布主题 快速回复 返回列表 联系我们 官方QQ群 科帮网手机客户端
    快速回复 返回顶部 返回列表