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

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

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

继续阅读“网页中的编码与乱码(5)”

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

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

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

继续阅读“网页中的编码与乱码(4)”

对“有点尴尬诶!该页无法显示”情况的一个说明

最近发现网站出现不少 404 的访问,看了一下是对 url 错误二次编码造成的。

如果出现 404 ,该页无法显示的情况,您的浏览器可能对 url 进行了错误的二次编码(或者是其它的转发环节),‘%’被编码成了 ‘%25’。

% 的 ASCII 码 正好是 25(十六进制),%25 就是 % 本身的转义表示,但它是不需要再转义的。

正确形式://xiaogd.net/%XX%XX...
错误形式://xiaogd.net/%25XX%25XX...

错误形式中,% 被二次转义,变成了 %25,导致了 404 错误。

在后台的 access_log 中,找到这些带有 %25 的错误 url,查看其浏览器用户代理 userAgent 的值多为类似以下:

"Mozilla/5.0 (iPhone; CPU iPhone OS 9_3_4 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13G35 QQ/6.5.3.410 V1_IPH_SQ_6.5.3_1_APP_A Pixel/750 Core/UIWebView NetType/2G Mem/117"

关键词:iPhone,AppleWebKit,QQ,UIWebView

估计为 iphone qq 浏览器内核的 bug。我已在 404 页面添加相应说明。(sorry for that,and don't blame me~)

如果您出现无法访问的情况,欢迎留言告诉我具体的情况,谢谢!(不过如果你用手机访问,应该是不会有留言框出现~~)

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

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

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

继续阅读“网页中的编码与乱码(3)”

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

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

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

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

继续阅读“网页中的编码与乱码(2)”