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

简介: Web应用中浏览器与服务端的编码和解码

【1】基本概念

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


字符集是一种文化上下文下的所有文字符号集合,它的作用是规定了某个文化下的所有字符,以及该字符在信息交换系统下的表示方式,在计算机信息系统下是字节或01序列。


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


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

【2】浏览器端的编码

① http协议层的编码解码

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

② 浏览器端的编码

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


浏览器存在文档编码方案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在content-type说明编码方案,但这种做法不会对url、数据体的编码方案产生任何影响,甚至在有些浏览器中,最终content-type中的编码描述都无法真正影响。


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

【3】服务端的解码

服务端的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的优先顺序来决定数据体的解码方案。


web服务器接收到客户端的请求后,会将其内容转给web容器来处理;因为接到的请求path(url)是编码过的二进制流,所以在处理前会将其转换成ASCII码 。但是请求中可能还有部分参数和消息体的数据是经过编码的(例如中文字符被编码),这里就涉及到对请求内容和参数进行解码的问题。


Servlet服务器实现的Servlet遇到URL和POST提交的数据中含有%的字符串,它会按照指定的字符集解码。


下面两个Servlet方法返回的结果都是经过解码的:

request.getParameter("name");
request.getPathInfo();

这里所说的"指定的字符集"是在应用服务器的配置文件中配置。默认为ISO-8859-1。

【4】服务端的编码

服务端解码是针对请求而言,服务端编码是针对响应而言。服务端httpserver需要编码的对象是:header、数据体。


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


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


response.setCharacterEncoding的职能是告诉httpserver数据体的编码方案,并不会也不应该影响到header中的编码方案的标注。

response.setContentType会影响到header的编码方案的标注,浏览器根据该标识决定解码方案。


对于一个健全的httpserver来说,在同时通过两个方法指定了数据体编码方案和header编码方案标注的情况下,数据体编码方案应该由后者决定,这样使浏览器端得到的编码信息和服务端真正编码信息一致。


另外,一定要注意的是这两个指定编码方案的方法必须在response创建输出流之前调用,输出流一旦创建,编码方案无法后期指定。


【5】浏览器端的解码

浏览器端的解码针对的是服务器返回的响应。浏览器端对返回进行解码的对象包括:header、数据体:

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

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


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


浏览器根据http头中的ContentType("text/html; charset=GBK"),指定的字符集来解码服务器发送过来的字节流。


我们可以调用 HttpServletResponse.setContentType()设置http头的ContentType。

需要注意的是,URL中的PathInfo和QueryString字符串的编码和解码是由浏览器和应用服务器的配置决定的。我们的程序不能设置,也不要期望用request.setCharacterEncoding()方法能设置URL中参数值解码时的字符集(该方法只针对post)。通常我们也无需关注这个,我们更应该关注消息体的编码解码。


如,可能会在Tomcat中这样配置:

 <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000" URIEncoding="UTF-8" 
               redirectPort="8443" />

【6】开发人员必须清楚的servlet规范

(1) HttpServletRequest.setCharacterEncoding()方法 仅仅只适用于设置post提交的request body的编码而不是设置get方法提交的queryString的编码。

该方法告诉应用服务器应该采用什么编码解析post传过来的内容。

(2) HttpServletRequest.getPathInfo()返回的结果是由Servlet服务器解码(decode)过的。

(3) HttpServletRequest.getRequestURI()返回的字符串没有被Servlet服务器decoded过。

(4) POST提交的数据是作为request body的一部分。

(5) 网页的Http头中ContentType("text/html; charset=GBK")的作用:

  • (a) 告诉浏览器网页中数据是什么编码;
  • (b) 表单提交时,通常浏览器会根据ContentType指定的charset对表单中的数据编码,然后发送给服务器的。

这里需要注意的是:这里所说的ContentType是指http头的ContentType,而不是在网页中meta中的ContentType。

(6) JSP页面 pageEncoding作用

如下所示:

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>

pageEncoding作用如下:

response.setContentType("text/html; charset=UTF-8");


目录
相关文章
|
2月前
|
存储 监控 安全
如何在Python Web开发中确保应用的安全性?
如何在Python Web开发中确保应用的安全性?
|
2月前
|
前端开发 JavaScript 安全
前端性能调优:HTTP/2与HTTPS在Web加速中的应用
【10月更文挑战第27天】本文介绍了HTTP/2和HTTPS在前端性能调优中的应用。通过多路复用、服务器推送和头部压缩等特性,HTTP/2显著提升了Web性能。同时,HTTPS确保了数据传输的安全性。文章提供了示例代码,展示了如何使用Node.js创建一个HTTP/2服务器。
69 3
|
2月前
|
前端开发 JavaScript
探索现代Web应用的微前端架构
【10月更文挑战第40天】在数字时代的浪潮中,Web应用的发展日益复杂多变。微前端架构作为一种新兴的设计理念,正逐步改变着传统的单一前端开发模式。本文将深入探讨微前端的核心概念、实现原理及其在实际项目中的应用,同时通过一个简单的代码示例,揭示如何将一个庞大的前端工程拆分成小而美的模块,进而提升项目的可维护性、可扩展性和开发效率。
|
14天前
|
弹性计算 Java 关系型数据库
Web应用上云经典架构实践教学
Web应用上云经典架构实践教学
Web应用上云经典架构实践教学
|
22天前
|
Kubernetes 安全 Devops
有效抵御网络应用及API威胁,聊聊F5 BIG-IP Next Web应用防火墙
有效抵御网络应用及API威胁,聊聊F5 BIG-IP Next Web应用防火墙
53 10
有效抵御网络应用及API威胁,聊聊F5 BIG-IP Next Web应用防火墙
|
14天前
|
弹性计算 Java 数据库
Web应用上云经典架构实战
本课程详细介绍了Web应用上云的经典架构实战,涵盖前期准备、配置ALB、创建服务器组和监听、验证ECS公网能力、环境配置(JDK、Maven、Node、Git)、下载并运行若依框架、操作第二台ECS以及验证高可用性。通过具体步骤和命令,帮助学员快速掌握云上部署的全流程。
|
2月前
|
人工智能 前端开发 计算机视觉
Inpaint-Web:纯浏览器端实现的开源图像处理工具
在刷短视频时,常看到情侣在景区拍照被路人“抢镜”,男朋友用手机将路人“P”掉,既贴心又有趣。最近我发现了一个纯前端实现的开源项目——inpaint-web,可在浏览器端删除照片中的部分内容,非常酷。该项目基于 WebGPU 和 WASM 技术,支持图像修复与放大,已在 GitHub 上获得 5.1k Star。项目地址:[GitHub](https://github.com/lxfater/inpaint-web)。
70 3
 Inpaint-Web:纯浏览器端实现的开源图像处理工具
|
2月前
|
前端开发 JavaScript UED
在数字化时代,Web 应用性能优化尤为重要。本文探讨了CSS与HTML在提升Web性能中的关键作用及未来趋势
在数字化时代,Web 应用性能优化尤为重要。本文探讨了CSS与HTML在提升Web性能中的关键作用及未来趋势,包括样式表优化、DOM操作减少、图像优化等技术,并分析了电商网站的具体案例,强调了技术演进对Web性能的深远影响。
40 5
|
2月前
|
存储 缓存 前端开发
Web端IM聊天消息该不该用浏览器本地存储?一文即懂!
鉴于目前浏览器技术的进步(主要是HTML5的普及),在Web网页端IM聊天应用的技术选型阶段,很多开发者都会纠结到底该不该像原生移动端IM那样将聊天记录缓存在浏览器的本地,还是像传统Web端即时通讯那样继续存储在服务端?本文将为你简洁明了地讲清楚浏览器本地存储技术(Web Storage),然后你就知道到底该怎么选择了。
36 1
|
2月前
|
机器学习/深度学习 人工智能 JavaScript
JavaScript和TypeScript的未来发展趋势及其在Web开发中的应用前景
本文探讨了JavaScript和TypeScript的未来发展趋势及其在Web开发中的应用前景。JavaScript将注重性能优化、跨平台开发、AI融合及WebAssembly整合;TypeScript则强调与框架整合、强类型检查、前端工程化及WebAssembly的深度结合。两者结合发展,特别是在Vue 3.0中完全采用TypeScript编写,预示着未来的Web开发将更加高效、可靠。
50 4