自定义博客皮肤VIP专享

*博客头图：

点击选择上传的图片

格式为PNG、JPG，宽度*高度大于1920*100像素，不超过2MB，主视觉建议放在右侧，请参照线上博客头图

请上传大于1920*100像素的图片！

博客底图：

点击选择上传的图片

图片格式为PNG、JPG，不超过1MB，可上下左右平铺至整个背景

栏目图：

点击选择上传的图片

图片格式为PNG、JPG，图片宽度*高度为300*38像素，不超过0.5MB

主标题颜色：

RGB颜色，例如：#AFAFAF

Hover：

RGB颜色，例如：#AFAFAF

副标题颜色：

RGB颜色，例如：#AFAFAF

预览取消提交

自定义博客皮肤

上一步保存

u013833031的博客

程序猿小乌龟优快云认证博客专家优快云认证企业博客

码龄11年

暂无认证

14: 原创

15万+: 周排名

212万+: 总排名

16万+: 访问

: 等级

1003: 积分

18: 粉丝

49: 获赞

7: 评论

102: 收藏

私信

关注

分类专栏

@Value 1篇
事务 1篇
MySQL 2篇
java 基础 2篇
MAVEN 2篇
数据库 4篇
tomcat部署
Java基础 7篇
js 1篇
SSM框架 2篇
velocity

最新评论

java中值传递以及引入传递相关问题记录
喜欢敲代码的Apollo: 少年,我看你骨骼精奇,不如来我博客看看可好
为什么请求时,需要使用URLEncode做encode转码操作
Silent_Walker 回复 Silent_Walker: [code=html] 第三部分post我没看，大家审慎地对待吧。其实原理搞懂了就很容易了，底层就是socket发送接收前后的编码解码对应。落到各种服务器，最好就是查官方文档或者debug看源码。我之前看到说tomcat9自动帮我们处理get的urlDecode，我都忘记了是不是真的，刚才测试了一下，不行，真的，小道信息害死人。这csdn的评论格式真难用 [/code]
为什么请求时,需要使用URLEncode做encode转码操作
Silent_Walker: [code=html] 分析一下这篇文章。第一部分博主转发的，正确。第二部分get，大部分推理正确，写得不完整，但是对我挺有启发，但是博主怎么实践起来就错了呢？！下面给出正确分析原理。 1. 现在假定http协议约定使用 iso-8859-1 字符编码表，这里根据博主推敲的，其实即便是Ascii或者其他字符编码表也不影响推论，重要是客户端和服务端遵守约定，有兴趣可以看看http协议的相关约定。 2. 客户端需要先把原始报文全部转化为iso-8859-1编码字符集中的字符，这个过程叫做urlEncode("charset")，否则iso-8859-1编码解码器会把无法识别的字符转化为"?"63或者空格，会丢失信息。然后才会使用iso-8859-1编码，最后把编码后的字节流写入socket。 3. 服务端（例如tomcat）把socket的字节流进行iso-8859-1解码（约定很重要，不然谁知道用什么解码），然后解析报文（此时就是一堆字符串），获取参数、header之类的，之后需要urlDecode（还原原始报文中的非iso-8859-1字符集的字符，这个过程就是乱码出现的根源，http协议没有规定使用urlencode，服务器不会自动urlDecode，因此需要手动urlDecode 4. 根据以上推论，那么我们在tomcat web应用中使用该方法 URLDecoder.decode(request.getParameter("param"),"charset") 就能拿到中文value 。记住charset要对应客户端。 5. 错误：new String(request.getParameter("name").getBytes("iso-8859-1"),"客户端指定的URL encode编码方式") 博主实践错误的原因就在这里。我这里解释一下吧。request.getParameter("name")拿到urlDeocde前的value；getBytes("iso-8859-1")拿到socket的字节流，因为jvm内部字节表示和http传输的字节是不一样的（两者用的编码不一样）；然后再new String（"客户端指定的URL encode编码方式"），相对于直接使用URL encode 编码socket里面的字节，肯定错啊。 [/code]
为什么请求时,需要使用URLEncode做encode转码操作
Silent_Walker: [code=html] 分析一下这篇文章。第一部分博主转发的，正确。第二部分get，大部分推理正确，写得不完整，但是对我挺有启发，但是博主怎么实践起来就错了呢？！下面给出正确分析原理。 1. 现在假定http协议约定使用 iso-8859-1 字符编码表，这里根据博主推敲的，其实即便是Ascii或者其他字符编码表也不影响推论，重要是客户端和服务端遵守约定，有兴趣可以看看http协议的相关约定。 2. 客户端需要先把原始报文全部转化为iso-8859-1编码字符集中的字符，这个过程叫做urlEncode("charset")，否则iso-8859-1编码解码器会把无法识别的字符转化为"?"63或者空格，会丢失信息。然后才会使用iso-8859-1编码，最后把编码后的字节流写入socket。 3. 服务端（例如tomcat）把socket的字节流进行iso-8859-1解码（约定很重要，不然谁知道用什么解码），然后解析报文（此时就是一堆字符串），获取参数、header之类的，之后需要urlDecode（还原原始报文中的非iso-8859-1字符集的字符，这个过程就是乱码出现的根源，http协议没有规定使用urlencode，服务器不会自动urlDecode，因此需要手动urlDecode 4. 根据以上推论，那么我们在tomcat web应用中使用该方法 URLDecoder.decode(request.getParameter("param"),"charset") 就能拿到中文value 。记住charset要对应客户端。 5. 错误：new String(request.getParameter("name").getBytes("iso-8859-1"),"客户端指定的URL encode编码方式") 博主实践错误的原因就在这里。我这里解释一下吧。request.getParameter("name")拿到urlDeocde前的value；getBytes("iso-8859-1")拿到socket的字节流，因为jvm内部字节表示和http传输的字节是不一样的（两者用的编码不一样）；然后再new String（"客户端指定的URL encode编码方式"），相对于直接使用URL encode 编码socket里面的字节，肯定错啊。 [/code]
为什么请求时,需要使用URLEncode做encode转码操作
qq_36818410: 棒棒的

MAVEN

关注

关注数：文章数：2 文章阅读量：5197 文章收藏量：1

作者: 程序猿小乌龟

Coding change the world!

展开

u013833031的博客

MAVEN

作者: 程序猿小乌龟

Maven编译打包过程(clean install)中遇到相关jdk版本导致的问题

Java class文件的JDK编译版本号