web应用中浏览器与服务端的编码和解码

基本概念

有信息交换就会产生编码、传输、解码三个过程。编码是信息从一种形式转变成另一种形式的过程,正如人类的语言通过声带编码,转换成声波。解码是编码的逆函数,耳膜接收声波,通过脑神经解码成人类文化所能理解的信息。

字符集是一种文化上下文下的所有文字符号集合,它的作用是规定了某个文化下的所有字符,以及该字符在信息交换系统下的表示方式,在计算机信息系统下是字节或01序列。本文会在某些时刻将字符集和编码方案互用,以方便理解。

对于javaweb应用,狭隘的编码解码的过程可以简单的理解为:编码的过程是文本字符串信息编码成01序列,解码是将01序列恢复为文本字符串信息,具体编码成什么样的01序列是由编码采用的字符集来决定的,也就是编码方案。

乱码是对信息采用的编码方案无法理解,使用了错误的编码方案对信息进行解码造成的。如果要理解一段信息的真实意图,就得知道信息采用的编码方案,这是信息交换的密钥,这就是为什么战争年代破解对方电报加密方式,实际上就是在破译对方的编码方案。

http协议层的编码解码

http协议层的字符集关系到http发送者和接送者采用什么字符集方案解析对方发送的内容。

浏览器端的编码

请求端常规请求方式主要为form、url、ajax、http组件如HttpClientAPI。

浏览器存在文档编码方案charset的概念,文档的编码方案等同于文档解码方案,它对文档中发生的请求编码会产生影响。

影响form提交数据的编码的因素包括:form的accept-charset属性、html文档的编码方案即document.charset。其中,form的accept-charset是否能够有效,依赖具体浏览器的实现,有些浏览器并不支持,如IE。文档编码方案可以通过document.charset来修改。

文档内的url编码,如iframe的src指定的url,以文档编码方案为准,地址栏的url的编码方案完全取决于具体的浏览器实现,通过HttpClient组件发送请求时,url是能任意指定编码方案的。

ajax发送http请求的url编码方式完全取决于浏览器实现,一般支持以文档编码方案来决定,但是数据体统一采用utf-8,另外,虽然ajax可以指定header在contenttype说明编码方案,但这种做法不会对url、数据体的编码方案产生任何影响,甚至在有些浏览器中,最终contenttype中的编码描述都无法真正影响。

另外,header的编码方案是iso-8859-1,这个是http规范。

服务端的解码

服务端的httpserver需要解码的对象包括:header、url、数据体。

header解码方案是iso-8859-1。

url解码方案通常称为URIEncoding,一般HttpServer会提供相应设置,标准servlet并不提供该接口。jetty默认utf-8字符集来解码,但其他httpserver如tomcat会默认iso-8859-1。

数据体解码在servlet中可以通过request.setCharacterEncoding来设置。一般的,有些httpserver会以characterEncoding>request请求头字符集>utf-8的优先顺序来决定数据体的解码方案。

服务端的编码

服务端httpserver需要编码的对象是:header、数据体。

header的编码方案同样是iso-8859-1。

通常情况下,服务端必须要指定返回数据体的编码方案且要在header中标注编码方案,否则httpserver一般默认iso-8859-1对输出进行编码,而浏览器也无法得知返回数据体的编码方案,只能自行猜测,完全依赖浏览器自己的实现。

response.setCharacterEncoding的职能是告诉httpserver数据体的编码方案,并不会也不应该影响到header中的编码方案的标注。response.setContentType会影响到header的编码方案的标注,浏览器根据该标识决定解码方案。对于一个健全的httpserver来说,在同时通过两个方法指定了数据体编码方案和header编码方案标注的情况下,数据体编码方案应该由后者决定,这样使浏览器端得到的编码信息和服务端真正编码信息一致。另外,一定要注意的是这两个指定编码方案的方法必须在response创建输出流之前调用,输出流一旦创建,编码方案无法后期指定。

浏览器端的解码

浏览器端对返回进行解码的对象包括:header、数据体。

header的解码方案是iso-8859-1。

浏览器的数据体解码方案依赖返回信息,浏览器首先从返回头header中查找编码方案标注,如果没有标注,在得知返回内容为html内容的话,将从head的meta标签中读取,如果还没找到,浏览器就不知道如何解码,会消极的选择一种解码方案。

在理论上,推荐html文档在meta中声明编码,且编码的声明一定要在文件开始的1024字节内完成,所以最好在head标签开始时立即声明。

文档中通常都会有一些通过url下载的资源文件,如css和js文件,如果资源文件输出时没有在返回头中指定明确的编码方案,浏览器无法得知编码方案,只能以上面介绍到的文档编码方案来进行解码,这也是浏览器容错的最佳策略。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,463评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,868评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,213评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,666评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,759评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,725评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,716评论 3 415
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,484评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,928评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,233评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,393评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,073评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,718评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,308评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,538评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,338评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,260评论 2 352

推荐阅读更多精彩内容