处理中文乱码_URL传值乱码问题分析

前言

距离上一次发表文章已经快一周时间了,期间加了四天班,有两天是过了后半夜12点那种。我认为这是对我下决心坚持输出内容的一种考验,好在通过周末时间将这篇文章整理出来了,没有在一开始就打自己的脸。有一些内容可能我的理解也不全对,如果发现有不对的地方请指正,大家互相交流学习。

本篇主要以我的实际业务问题为背景,介绍URL当中参数传中文值时,目标地址接收到参数值为乱码情况下解决问题的思路及个人经验小结。

本文主要由“问题背景描述”,“分析思路”,“最终解决方案”,“小结”,“关于字符编码知识的小结”模块构成。

问题背景描述

我负责运维系统当中有这么一种需求。点击系统链接带参数地址,返回画面时参数当中中文部分显示为乱码。/*业务流程可参考下图*/由于当前使用系统较为古老,技术选择上没有其他方案,所以该业务只能以这种URL带参数方式实现。/*最初版本诞生时间为2003年..比较古董级系统了,不过好在最近公司终于着手投入开始重构这个古董了*/

e78fc7e1219b575e2b68f8abc5fe9156.png

链接地址参考:http://链接地址/静态路径?参数=%20此处为中文内容&

显示乱码画面参考:

a07ddac9f1f567fde525c604cff28e90.png

分析思路

最开始客户提这个问题时候,我没有多想,第一反应就是在本地环境里进行问题重现。奇怪的是本地环境无论我怎么试,都无法重现这个问题。后来想到有可能是环境的问题。于是在测试服务器上又尝试了一遍,/*测试服务器与生产服务器环境相同*/马上问题就重现出来了。

由此陷入了思考,问题点在环境上,而出现乱码问题的本质,其实在于字符编码、解码上。本地是Window环境,而服务器为Linux发行版系统。临时改服务器编码集不大现实,保不准又会出现其他BUG。而且由于公司制度还需要申请一大堆文书,解决问题周期比较长。最后决定在业务系统层面解决问题。/*这里问一句题外话,大家有见过英文乱码吗?对这个问题感兴趣的朋友可以自己搜索关于字符编码的知识内容,或者后台留言与我交流。*/

解决方案

将问题点定位之后就比较好处理了。我的方案就是将整个传参流程上关于字符进行统一方式的编码、解码,这样就会保证不会再出现乱码问题。

具体操作过程是在系统给用户B发送邮件时,生成邮件内容的链接地址当中的中文参数,进行编码。由于当前系统发送邮件的功能是在DB上进行发送的,所以我新生成了一个编码加密的 DB Funtion,适用在该参数上了。当用户B点击链接地址并访问画面时,在JAVA端对该参数进行解码。

如下图红圈表示逻辑上以UTF-8方式进行了编码、解码操作,问题得到了解决。

17fc1498255b3ec34d6d9b294ac70347.png

创建Oracle DB Function代码示例(左右滑动查看代码)

CREATE OR REPLACE FUNCTION URL_ENCODE(urlEncode IN VARCHAR2,encodeType IN VARCHAR2)RETURN VARCHAR2 ASBEGIN  RETURN UTL_URL.ESCAPE(urlEncode, TRUE , encodeType);END;

调用 DB Function示例

SELECT URL_ENCODE(中文参数,'UTF-8') /*第一个参数为所要编码的对象值,第二个参数为字符编码方式*/FROM DUAL;

JAVA端使用字符解码示例(左右滑动查看内容)

java.net.URLDecoder.decode(经过字符编码的中文参数,'UTF-8');/*第一个参数为所要解码的对象值,这里需要注意的是该值必须为经过编码之后的值第二个参数为字符解码方式,这里要与编码方式一致,不一致情况依然会有乱码问题出现*/

经过处理之后链接地址参考(加粗部分为编码之后内容)

http://链接地址/静态路径?参数=%20 

%e6%ad%a4%e5%a4%84%e4%b8%ba%e4%b8%ad%e6%96%87%e5%86%85%e5%ae%b9

&

小结

该问题通过上述方式已经解决。但在这里首先想到的经验总结是,测试很重要。编写测试案例非常重要。像此类问题如果在最初开发阶段通过测试出问题并得到解决,就不会出现客户使用产品时候出这类问题。

其次,遇到问题时候能找到问题关键点并能以此为入口找寻解决方法会高效的多。而不是盲目的为了解决问题而去忙碌。这样浪费时间不说,最后搞得自己疲惫不说还要面临客户投诉的压力。

最后,如果有关于乱码的问题,可以第一时间去确认是否使用了统一的字符编码或者使用了错误的字符编码去解码。

关于字符编码知识的小结

在我们编程过程当中字符编码通常在IO流处理上常见。而造成乱码的根本原因是因为解码时候的字符编码不一致。

下面是对几个基本概念的解释。

字符:是各种文字和符号的总称,包括各个国家的文字,标点符号,图形符号,数字等。字符集:字符集是多个符号的集合,每个字符集包含的字符个数不同。字符编码:字符集只是规定了有哪些字符,而最终决定采用哪些字符,每一个字符用多少字节表示等问题,则是由编码来决定的。计算机要准确的处理各种字符集文字,需要进行字符编码,以便计算机能够识别和存储各种文字。

常见的字符编码有 GBK、 GB2312、 US-ASCII、 ISO-8859-1、 UTF-8、 UTF-16BE、 UTF-16LE、 UTF-16 。而UTF-8 就是在互联网上使用最广的一种Unicode 的实现方式。这里需要注意的是Uncidoe 字符集≠UTF-8 编码方式 。Uncidoe是一种规定,而UTF-8是一种方案。通俗的理解就是理论和实操的区别。

由于篇幅关系关于字符编码内容就不再过多讲述,以上有不对的地方请后台留言指正。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值