表单(form) post 方式提交时的编码与乱码(下)

探讨了表单以 post 方式,enctype 为 multipart/form-data 提交时数据所使用的字符集编码(包含缺省使用页面编码及设置了 accept-charset 时两种情形),包括了上传文件及使用中文文件名时的情况,以及后台的接收处理。

在上一篇中提到,post 方式按 enctype 的不同,分成两种情况,一种是 application/x-www-form-urlencoded,前面已经分析过了,这一篇则讨论剩下的那种:multipart/form-data。

继续阅读

表单(form) post 方式提交时的编码与乱码(上)

探讨了表单以 post 方式,enctype 为 application/x-www-form-urlencoded 提交时数据所使用的字符集编码,具体介绍了缺省情况以及设置了 accept-charset 属性时的情况,同时介绍了后台在取出表单数据前如何使用 setCharacterEncoding 来设置正确的解码。

在上一篇章中谈论了表单以 get 提交时的编码与乱码问题,这一章中将讨论以 post 方式提交时的编码与乱码问题。

在前面也同时提到,表单有一个叫 enctype 的属性,它有两个值,application/x-www-form-urlencoded 和 multipart/form-data。这一属性实际只对 post 方式起作用,因为 get 方式实际只支持前一种类型,也就是 application/x-www-form-urlencoded,这是缺省的类型。

在使用 post 方式提交时,缺省的编码类型也依然是这个 application/x-www-form-urlencoded。在这一篇章中,先讨论这一类型;在下篇中,再讨论 multipart/form-data 类型。

继续阅读

表单(form) get 方式提交时的编码与乱码

探讨了表单以 get 方式提交时数据所使用的字符集编码,具体介绍了缺省情况,此时使用文档本身的编码;以及设置了 accept-charset 属性时的情况。

在前面说完了 URL 中的编码与乱码(),也为本章节谈论的主题,关于表单(form)以 get 方式提交时的编码与乱码问题打下了一个良好的基础。

事实上,表单以 get 方式提交就是把表单中的数据拼凑在 url 中提交到后台,也因此与 url 中的编码有着非常紧密的关系,可以说这两种方式是极为类似的。

继续阅读

URL 中的编码与乱码(下)

深入介绍了 URL 中的转义编码,用具体例子讲解了不同页面编码的情况下,查询字符串转义时所使用的编码,还顺带对 url 的组成结构作了介绍。

在上篇中,初步谈论了 URL 中含有中文字符时的转义编码,提到了所使用的编码是 utf-8.

不过你可能会有点疑问,一定都是用 utf-8 编码吗?还是因为页面编码本身是 utf-8 的缘故呢?毕竟在那个例子中,页面的编码也恰好是 utf-8。

继续阅读

URL 中的编码与乱码(上)

深入介绍了 URL 中的转义编码,用具体例子讲解了中文 URL 中的转义情况,以及 tomcat Connector 中的 URIEncoding 设置。

在之前说完了静态 html 页面的中的编码(),接着又谈论了动态 html 页面中的编码问题,具体以 java 平台为例,谈论了 servlet 中的编码与乱码问题以及 jsp 中的编码与乱码问题

虽然没有涉及更多的语言平台,比如 php,asp,乃至 nodejs,python,ruby 等,但背后的原理基本也是相通的。

这一次将转入一个新的话题,就是 URL 中的编码与乱码问题。

继续阅读

JSP 中的字符集编码与乱码问题

深入介绍了 JSP 中的编码与乱码问题,分析对比了 page 指令中的 pageEncoding 属性和 contentType 属性,还对 JSP 与 servlet 及 HTML 的关系作了一个简要介绍。

在说完了网页中的编码与乱码(),servlet 中的编码问题后,这次来探讨一下 JSP 中的编码与乱码问题。

在之前,曾谈到过 JSP 与 HTML 间的关系,JSP 本质上是一个 HTML 的模板,用于在服务端动态生成 HTML,这点跟 servlet 是类似。

其实 JSP 本质就是 servlet,一个 JSP 页面它会被编译成一个 java 文件,实际上就是一个 servlet 类(或其子类,在文章的后面会具体讨论这个问题)。

继续阅读

Java servlet 使用 PrintWriter 时的编码与乱码

介绍了 Java servlet 使用 PrintWriter 时的编码与乱码问题,并探讨了 PrintWriter 的缺省编码与普通字符流的缺省编码的差异。

在前面的网页中的编码与乱码系列中(),曾多次提到使用 servlet 方式构建的动态响应流,不过在那里都是直接使用字节流的方式,不过,更为常见的方式是使用字符流。而在前面,又谈到了 Java 字节流与字符流的话题()。

有了前面的基础,现在来说下 Java servlet 中使用字符流,也即是 PrintWriter 时的编码与乱码问题。

继续阅读

Java 字节流与字符流(3)

在上一篇中比较了使用字节流和字符流来读取(写入)文本文件的优劣后,这一篇主要探讨缺省编码这个主题。

字符流使用缺省编码

通过前面的例子,已经得出了一个结论:字符流=字节流+编码。

可以在构建字符流时显示传入编码参数,那么所得到的字符流就会以该编码来编码(encode)解码(decode)字节流,这会给文本数据处理带来极大方便。

但有时,构建字符流时也可以不传入编码参数,比如如下直接构建一个 InputStreamReader :

继续阅读

Java 字节流与字符流(2)

在上一篇中介绍了字节流与字符流的关系,这一篇主要给出一些具体的代码示例。

使用字节流读取文本文件

上篇中说到,无论是字符流还是字节流,都可以用于读取文本文件,特别是对于一整个文件的读取,两者的差别并不大。来看一个具体的示例,假如有如下 gbk 编码的 txt 文件一枚,具体内容为“hi你好”,对应二进制如下:

继续阅读

网页中的编码与乱码(5)

深入探讨了缺省情况下浏览器的响应行为,包括静态和动态的响应,最后,对所有情况作了一个简单总结。

在上一篇我们谈论了 BOM 编码的页面,并知道了它是有最高优先级的。而这一篇将讨论最后的一个主题,也就是缺省的情况。既然名为缺省,也就不难想到,它的优先级是最低的,也即是在其它情况下都无法确定编码时,才轮到它上场。

继续阅读

网页中的编码与乱码(4)

深入介绍了 html 页面使用 BOM 编码的情况,它的优先级为什么最高以及具体的静态页面和动态响应的测试示例。

这一篇将介绍 BOM 在 html 页面编码中的运用。在最前面曾提到,它的优先级实际上是最高的,在这里,将具体介绍什么是 BOM,还会解析为什么它的优先级最高,然后还会构建一些具体的测试来验证这一点。

继续阅读

网页中的编码与乱码(3)

深入介绍了响应头 Response Headers 中的 Content-Type 中的 charset 信息的应用,包括许多在静态文档和动态文档中的实验与测试的细节,以及一些具体配置和与文档内编码声明的优先级问题。

在上一篇说完了如何通过文档内的编码声明来确定网页的编码通过文档内的编码声明来确定网页的编码,这一篇则开始具体讲述如何通过响应头下的 Content-Type 条目中的 charset 信息来确定文档的编码,包括如何去配置这个响应头,以及一些具体的实验,还有它与文档内编码声明的优先级选择问题。

继续阅读

网页中的编码与乱码(2)

深入介绍了文档内编码声明的应用,包括许多在静态文档和动态文档中的实验与测试的细节,以及其它的一些注意事项等。

接着上一篇中的讨论,也是先从“文档内编码声明”讲起,因为它是最直观也最容易控制的。

不过事实上也没有那么容易,它还是很容易受各种因素干扰,下面会详细介绍整个过程,囊括了静态文档响应和动态文档响应两种情况,以及各种其它注意事项。

继续阅读

网页中的编码与乱码(1)

授人以鱼不如授人以渔,在这里我会告诉有关网页中的编码的一些事实与结论,但我更希望传达给你分析问题的方法,当你遇到乱码困扰时,你能够独立迅速地分析并解决问题。

在之前谈了很多关于字符集编码与乱码的基础知识,可以说,如果你掌握了这些,对于各种乱码问题,就有了一个良好的基础,基本能够分析甚至独立地解决各类的乱码问题。

自然,基础问题的重要性无需多言,但另一方面,具体的问题也同样很重要。据我的观察,具体的问题有很多是关于 web 开发方面所碰到的乱码,尽管从原理方面来说,道理都是一样的,但导致问题产生的许多细节还是值得一说的,所以这次也打算具体谈谈这些方面。

继续阅读

文本在内存中的编码(1)——乱码探源(4)

摘要:文本在内存中的编码以及 String 类型的本质。

让我们从一个故事开始说起。话说北大是很有哲学传统的,当你准备踏进北大校门时,连门卫都会连问你三个终极哲学问题:

你是谁?你从哪里来?你要到哪里去?
那么这与我们的问题又有何关系呢?我觉得理解内存中的编码的关键在于理解 String 类型,因此我们也来探讨一下 String 的前世今生:String 是谁(什么)?String 从哪里来?String 到哪里去?

当我们能够清晰地回答这三个终极问题时,对文本在内存中的编码也算理解得差不多了。

继续阅读