关于Tomcat上请求的编解码问题

最近翻阅《深入分析 Java Web 技术内幕》(作者:许令波),关于Tomcat上Web请求的编解码问题,少了一个小点,可能影响了部分读者的理解,我特意查证了一下,特总结如下:

1. 请求的PathInfo部分用Tomcat的Connector元素的URIEncoding属性指定的编码来解码。

具体使用可参考:https://tomcat.apache.org/tomcat-8.5-doc/config/http.html

2. 第二先说请求体(POST正文)的解析,Tomcat按下次顺序去获取字符编码:

1)用户通过类似代码指定:<%request.setCharsetEncoding("utf-8")%>

2) 请求报文content-type请求头指定的编码。

3)应用web.xml配置的统一编码(这个目前在Servlet4.0规范中)

4) 系统默认的ISO8859-1

3. 另外就是QueryString部分的解析,默认情况下Tomcat采用与1)相同的URIEncoding来解析QueryString。 但同时Tomcat提供了另一个参数useBodyEncodingForURI。字面意思用报文体编码来解析QueryString。  若该参数为true.则Tomcat采用与2)相同的编码来解析QueryString。

时间: 2024-10-12 03:34:25

关于Tomcat上请求的编解码问题的相关文章

搞清tomcat中的编解码

http://www.xuebuyuan.com/1287083.html *********************************** 经常会被乱码问题搅得头晕脑胀.事实上,乱码问题涉及的地方比较多,所以常常有了问题也很难定位,比如,可以发生在容器,可以发生在MVC框架,可以发生在数据库,可以发生在响应等等. 这里分析一下tomcat中是如何编解码的. 以"http://localhost:8080/测试?网络=编程"为例,可以将tomcat中编解码分解为这么几个地方: 1

常用视频格式与视频编解码标准介绍 转

细细算起来,视频文件可以分成两大类:其一是影像文件,比如说常见的VCD便是一例.其二是流式视频文件,这是随着国际互联网的发展而诞生的后起视频之秀,比如说在线实况转播,就是构架在流式视频技术之上的.流式视频(Streaming Video)采用一种"边传边播"的方法,即先从服务器上下载一部分视频文件,形成视频流缓冲区后实时播放,同时继续下载,为接下来的播放做好准备.这种"边传边播"的方法避免了用户必须等待整个文件从Internet上全部下载完毕才能观看的缺点. 1.A

Netty入门系列(3) --使用Netty进行编解码的操作

前言 何为编解码,通俗的来说,我们需要将一串文本信息从A发送到B并且将这段文本进行加工处理,如:A将信息文本信息编码为2进制信息进行传输.B接受到的消息是一串2进制信息,需要将其解码为文本信息才能正常进行处理. 上章我们介绍的Netty如何解决拆包和粘包问题,就是运用了解码的这一功能. java默认的序列化机制 使用Netty大多是java程序猿,我们基于一切都是对象的原则,经常会将对象进行网络传输,那么对于序列化操作肯定大家都是非常熟悉的. 一个对象是不能直接进行网络I/O传输的,jdk默认是

视频编解码,bbv 缓冲区的上溢和下溢

使用硬件相似的数据处理.一般都是数据进来,处理后立即发出去的形式.所以一般有一个数据进,一个数据出,2个接口. 硬件处理基本都要求实时.数据进来,处理之后马上发处理,这个时间要求非常短,一般要求控制在好多毫秒以内,才能达到实时的要求.一般硬件每秒钟能够处理的数据大小,在设计的时候就固定了.不能像软件那样,可以通过增加CPU来提升处理能力.而且硬件的缓存的容量也是在设计的时候就固定了,不能像软件那样,随意申请内存来用. 所以硬件的缓存都不会太大.缓存的数据太大,会造成等待数据处理延时太高.达不到实

Android 关于录音文件的编解码 实现米聊 微信一类的录音上传的功能

最近老大要求做一个类米聊的app,于是就去找解决方案,首先用Android本身的MediaRecorder肯定是不行的,只支持amr,wav,acc,如果要做到Android,Iphone,pc通用的话,这些格式是行不通的,而且在文件大小上尽可能越小越好.那么就只能找第三方编解码库咯. 首先,我去找了同类的软件,像talkbox,微信,米聊,还有很多copy的软件.个人比较喜欢米聊,但是面对TX的强大的潜在用户基数,是任何应用都很难突破的. talkbox Android版用的是ilbc的第三方

speex编解码在android上实现

以前在应用中使用到了Speex编解码,近来总结了一下Speex在android上的实现.Speex是一套主要针对语音的开源免费,无专利保护的音频压缩格式.Speex工程着力于通过提供一个可以替代高性能语音编解码来降低语音应用输入门槛 .另外,相对于其它编解码,Speex也很适合网络应用,在网络应用上有着自己独特的优势.同时,Speex还是GNU工程的一部分,在改版的BSD协议中得到了很好的支持.Speex是基于CELP并且专门为码率在2-44kbps的语音压缩而设计的.Speex源码是基于c语音

(中级篇 NettyNIO编解码开发)第十章-Http协议开发应用

HTTPC超文本传输协议〉协议是建立在TCP传输协议之上的应用层协议,它的发展是万维网协会和Internet工作小组IET'F合作的结果.HTTP是一个属于应用层的面向对象的协议,由于其简捷.快速的方式,适用于分布式超媒体信息系统.它于1990年提出,经过多年的使用和发展,得到了不断地完善和扩展.由于HTTP协议是目前Web开发的主流协议,基于HTTP的应用非常广泛,因此,掌握HTTP的开发非常重要,本章将重点介绍如何基于Netty的HTTP协议技进行HTTP服务端和客户端开发.由于Netty的

Java Web中涉及的编解码

用户从浏览器发起一个HTTP请求,存在编码的地方是URL.Cookie.Paramiter.服务器端接收到HTTP请求后要解析HTTP协议,其中URL.Cookie和POST表单参数要解码,服务器端可能还需要读取硬盘数据(数据库.文件),这些数据都可能存在编码问题.当Servlet处理完所有请求的数据后,需要将这些数据再编码通过Socket发送到用户请求的浏览器里,再经过浏览器解码成为文本.这些过程用图表示如下: 1.URL的编解码 为了验证浏览器是怎么编码URL的,我们选择FireFox浏览器

各种音视频编解码学习详解

各种音视频编解码学习详解 媒体业务是网络的主要业务之间.尤其移动互联网业务的兴起,在运营商和应用开发商中,媒体业务份量极重,其中媒体的编解码服务涉及需求分析.应用开发.释放license收费等等.最近因为项目的关系,需要理清媒体的codec,比较搞的是,在豆丁网上看运营商的规范 标准,同一运营商同样的业务在不同文档中不同的要求,而且有些要求就我看来应当是历史的延续,也就是现在已经很少采用了.所以豆丁上看不出所以然,从 wiki上查.中文的wiki信息量有限,很短,而wiki的英文内容内多,删减版