浏览器对编码的确定

我们知道,在一次 HTTP 请求中,浏览器向 HTTP 服务器发起 HTTP request,然后服务器返回 response header,到目前为止,字符的编码都是 ANCII 的,所以都还好,不需要考虑什么解码问题,但是服务器紧跟着传回来的 response body 本质上就是一个字节流了,于是自然而然的就面临一个解码的问题,怎么处理这个问题是我一直以来疑惑已久的。

对于这个问题,如果服务器比较规范,那么应该在 response header 中指明 charset ,这种情况当然是最好的,浏览器直接就可以按照给定的 charset 去解码正文,但是如果没有给出呢?很自然的会想到,HTML 正文里面,是有一个 meta 标签的,在那个 meta 标签中,我们可以指明 charset ,但是,我一直想不通的问题就在这里了:既然正文本身的编码方式就是未知的,而指明编码方式的 meta 又位于正文中,所以这不是一个自我循环的无解问题吗?

在这之前,我记得我曾经在网络上看到一些文章说,这种时候,对于 meta 标签的位置就很重要了,一定要写在 title 之前,给出的原因是说,title 中可能含有非 ANCII 字符,所以如果 meta 在 title 之前的话,就可以让浏览器顺利把 meta 找到并看懂,而如果 meta 在 title 之后,那么 title 中的多字节文本就可能影响了 meta 的被发现。这种轮调,甚至知道今天,(刚刚我搜了一下),还十分流行,见这里,http://touya.iteye.com/blog/26…,还有这里,http://www.jb51.net/article/16…,不可否认,他们的这个思路确实有一定的道理,甚至有人还做了十分详尽的对比测试,例如这里,http://epie.blogbus.com/logs/2…,但是,我依然不理解,我的疑惑是,如果说把 meta 放在 title 之前可以解决问题,那么应该是建立在那个编码是 ANCII 兼容的基础上的,也就是说,需要是 ANCII 的超集,例如变长的 UTF-8 ,如果遇到定长的非兼容编码,不是一样不行吗,例如 16 位定长的 Unicode ,虽然我也自己动手试过,例如这段代码:

<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-16">
		<title>中文</title>
	</head>
	<body>
		<p>中文</p>
	</body>
</html>

把这段代码以 16 位定长 Unicode 保存再浏览,虽然是可以正常解码,但是按照我的理解,应该是不行的啊。

直到今天,才看到一篇博文,介绍的是 Gecko 的解码方案,终于解决了这个疑惑,原来,渲染引擎是会对字节流做一定程度的智能判断的,再在这个基础上,决定解码页面使用的解码方式,博文来自百度搜索研发部,很不错的一个博客:

http://stblog.baidu-tech.com/?…

这篇文章讲的十分清楚,我也就不再多言了,强烈建议仔细读一读,最后附上两篇遇到的讲字符编码比较好的文章:

这个,中文编码杂谈,不知道为什么没了,要看 google cache,还有这个,http://www.fmddlmyy.cn/text16….

One thought on “浏览器对编码的确定

  1. Pingback: 从点击到呈现 — 详解一次HTTP请求(4) | ZRJ

Leave a Reply

Your email address will not be published. Required fields are marked *