最近遇到这样的问题，UTF-8的编码在IE8中显示空白，这篇文章讲的很透彻，很不错
E-Dragon CMS 默认生成的所有物理文件都是UTF-8编码。UTF-8 的便利性不可多言，而随着 Blog 也跟着开始变成网站必备的服务之一的 RSS 出现，UTF-8 编码更是搭配 XML 以及全球各种不同语系的网站，可以说是现阶段的最佳编码选择。
再随着 Web 2.0 世代的来临，XML 的使用率也会开始从普及到变成标准，如果你的网站还在使用本地的编码，你可能会随时就会被排除在网站之间交流的便利之外。
从一些知名的 opensource 软件来看，已经纷纷将 UTF-8 设为默认或是建议编码，也可以见到这样的迹象，终于可以不用每每自己再去修改编码。不过必竟这些知名的软件多半是国外生产的，总是会东少一点西少一块。
其实我要说的是，最近一些软件都开始有大幅度的更新，以致于在升级的时候会变得更麻烦，尤其并不是所有的社群都有放出各种方式的升级档，当然遇到大幅度架构的更新，要做 patch 也的确麻烦，所以跟着的就是在使用 UTF-8 时，反而有很多档案须要修正。
这篇要说的问题就是，原本一些在本地编码的页面可以正常的执行，在转换到 UTF-8 之后，只剩下空白的一片，还须要手动指定浏览器所使用的编码为 UTF-8 才可以正常。其实这个问题很单纯，问题就出在以往的习惯在 HTML 的标头的部份我们会这么写
<head>
<title>非英文数字开头的页面标题</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>在逻辑上这并没有任何的问题，不过随着浏览器技术的演进，以前是将整份的 HTML 文件读完后，才显示在浏灠器的窗口上，所以你可以这么说，你所看到的画面已经是浏览器经过解读后的结果，所以你也获得了正确的结果。但是在各种浏览器出现之后，网页显示的速度也变成一个比较的重点，所以页面不再是完整读完后，才全部一次显示，而是边下载的过程中，就边显示在浏览器的窗口上，这时就产生问题了，我们再看一次这段 HTML code.
<head>
<title>非英文数字开头的页面标题</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>当浏览器收到标头的信息时，最先收到的时页面的标题 title 然后送给浏览器显示，这时候浏览器已经错误的解读了这串文字，然后才收到整份文件的编码是 UTF-8 已经来不及了，以致于最后显示的结果可能是错误的编码，或是一个空白的页面(虽然看起来是空白，但是检视原始码时你会发现，还是完整的 HTML 文件内容)。如果你有各类 script language 实作的经验，你可以更清楚的了解，在输出标头之前，是不能输出任何字符的，以 PHP 的例子，你会得到一个 Warning: Cannot modify header information - headers already sent by… 的警告讯息。
多半 script language 都会自动处理送出标头的动作，以节省写程序的时间，再以 PHP 的例子来解释:
<?php
echo "Hola!";
?>其实在这之前 PHP 已经预先帮你处理 Content-type: text/html; 等等的信息了。如果你用 Perl 写过 CGI 就更清楚任何内容输出之前，都要先输出正确的 HTTP Header 才可以得到正确的结果。
回到正题，其实你也应该知道怎么解决了，只要先送出编码就不会有问题了，没错! 所以只要将编码移到第一行，就可以解进这个问题了。
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>非英文数字开头的页面标题</title>
</head>如果你跟我一样是 Hard Coder 问题应该不大，如果你是依赖 Dreamweaver 这类工具，那么请养成输出后再确认一次的好习惯。
注一:
我指的标头即 header，也有档头的说法，我也不知道哪个说法比较正确或通用，大多数都直接说 header，不过为了避免过多的中英夹杂会造成阅读的困扰，所以这边都说标头。
注二:
另一个比较消极的做法，也可以直接设定 Web Server 的默认编码为 UTF-8，这样在预先处理标题时也会送出正确的编码。不过如果你的 Web Server 同时 hosting 多个不同语系的网站，这就不是好方法了。
