UTF-8 BUG <br>
事实上 UTF-8 出现的时间很晚，虽然是个很好的东西却没有充分的支持，经常会出现兼容性 BUG。估计该书所在的服务器（目前是 Apache/2.0.49 (Debian GNU/Linux）的默认编码就是 UTF-8，因此浏览正常，可将相同的页面放在其他网站或者本地时，默认编码有可能是别的，例如 GB2312，因此在 <title> 字段就出现了问题：例如 by_disability.html
<title>Dive Into Accessibility: 依障碍编排</title>
之后才出现编码定义：
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
这样之前的汉字实际是当作本地默认编码来解析的，实际整个过程会出现一个字节的乱码，即 UTF-8 编码的“依障碍编排</title>”里会把“<”当成前一个汉字的一部份去处理，因为 UTF-8 中的汉字是三个字节，而 GB2312 等则是两个字节，五个 UTF-8 汉字恰巧等于七个半 GB2312 汉字的长度，于是“<”那就被充当最后一个汉字的后半部分了 -_- 而在 IE 里 <title> 字段如果没有被括回结果会很惨的：白屏。因此原中文版下载的中文版有几个 title 为汉字结尾的页面无法正常读取。
解决方法：</title> 前预留一个空格做备用。
事实上 UTF-8 出现的时间很晚，虽然是个很好的东西却没有充分的支持，经常会出现兼容性 BUG。估计该书所在的服务器（目前是 Apache/2.0.49 (Debian GNU/Linux）的默认编码就是 UTF-8，因此浏览正常，可将相同的页面放在其他网站或者本地时，默认编码有可能是别的，例如 GB2312，因此在 <title> 字段就出现了问题：例如 by_disability.html
<title>Dive Into Accessibility: 依障碍编排</title>
之后才出现编码定义：
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
这样之前的汉字实际是当作本地默认编码来解析的，实际整个过程会出现一个字节的乱码，即 UTF-8 编码的“依障碍编排</title>”里会把“<”当成前一个汉字的一部份去处理，因为 UTF-8 中的汉字是三个字节，而 GB2312 等则是两个字节，五个 UTF-8 汉字恰巧等于七个半 GB2312 汉字的长度，于是“<”那就被充当最后一个汉字的后半部分了 -_- 而在 IE 里 <title> 字段如果没有被括回结果会很惨的：白屏。因此原中文版下载的中文版有几个 title 为汉字结尾的页面无法正常读取。
解决方法：</title> 前预留一个空格做备用。
回复Comments
作者:
{commentrecontent}