首页 > 编程笔记 > Web笔记 阅读:245

URL编码是怎么回事?

我们每天都在浏览器的地址栏里面很多次输入URL,应该对它非常熟悉。浏览器地址栏包容性很强,英文、中文、日文、韩文统统都能输入,而浏览器也能给出比较正确的反馈。

但是,这只是表象,真正的网络世界对输入语言的要求是非常苛刻的,可以说是专属于英文字符的。

虽然在 URL 中使用一些中文字符从技术上讲不存在识别和传输的问题,但是网络标准协议中却规定了 URL 中只能包含英文字符。

那么,我们在地址栏里看到和使用的中文又是怎么回事呢?

事实上,那只是浏览器的障眼法。虽然我们在浏览器的输入框里使用了中文,可一旦浏览器发出网络请求,请求中的中文将不复存在,会变成我们经常看到却不明所以的东西,比如“%e5%82%bb%e5%91%80”,这就是 URL 中的中文被编码后的结果。

可能大家会觉得这种编码结果有些奇特,跟平时看到的编码比,它多了很多的这个“%”,其实只是分隔符,如果把“%”替换成空格,就可以看到我们熟悉的编码结果了,比如上面的“e5 82 bb e5 91 80”,眼尖的读者可能会看出这就是中文的 UTF-8 的编码。

按照标准进行编码是合理的,但是标准没有规定用什么编码,于是开发人员开始各自为战,有用 UTF-8 编码的,也有用 GB2312 编码的,这两种编码是什么不重要,重要的是两种编码的结果不一样,很多时候后台、前端、终端之间的矛盾就是因它而起的。

更让开发者觉得麻烦的是标准没有提供编码守则,于是程序员开始自由发挥。例如,在 URL 的实际使用过程中,经常会对 URL 的参数进行拼装,拼装的 URL 参数来源往往是没法确定的。

不过,不管参数的内容是什么,为了避免出现中文字符,开发者一般会在 URL 拼装完毕后统一做一次编码。

问题是,参数源可能已经将 URL 编码过一次了,而编码后的字符串是能够再次被编码的,就像俄罗斯套娃一样,所以看到一个编码结果时,开发者甚至没法确定它要被解码多少次才能得到真正的结果。

大家再看到这种包含很多“%”的字符串时,别认为是加密数据,随便找个 URL 解码工具就能还原它。

所有教程

优秀文章