文档字符集导致的脚本错误

最新推荐文章于 2022-04-12 22:03:52 发布

pingqingbo

最新推荐文章于 2022-04-12 22:03:52 发布

阅读量540

点赞数

分类专栏： asp.net

asp.net 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

Html页面中可以通过meta标签指定页面文档使用的字符集，这样浏览器就会根据此标签使用指定的字符集去解析文档流，而不用靠“猜”了。

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

文档字符集需要对应文件实际存储使用的字符集，否则会引发很多意料不到而又难以调试的Bug。

问题1——页面显示乱码

如果文档中指定的字符集和文件实际存储的字符集不一致，那么就会造成页面的非ASCII字符显示为乱码。如下面的HTML页面（文件的实际存储格式为UTF-8）：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
    </head>
    <body>
        <div>中文</div>
    </body>
</html>

“中文”会变成“涓枃”。

问题2——脚本执行结果不正确

问题1实际上还是比较容易发现的，因为一看到乱码就可以猜到和字符集相关了。但是如果假设你在上面这个页面的基础上写了如下Javascript代码：

<script type="text/javascript">
    location.href = "http://www.example.com/search?q=" + encodeURI("中文");
</script>

你期望将用户重定向到一个特定的页面，你直接在页面中使用了Unicode字符串，并期望encodeURI会使用UTF-8对其进行Url编码。但是实际上你获得的Url却是：

http://www.example.com/search?q=%E6%B6%93%EE%85%9F%E6%9E%83

后台在解析这个Url参数的时候无论使用何种字符集进行Url解码，都无法得到“中文”这个字符串。原因和文章开头提到的乱码问题实际上是同一个问题。如果你的文档字符集和页面存储字符集不一致，那么你在使用非ASCII码字符作字面量（就是直接写在代码里面的字符串）的时候就会出现意料不到的各种问题。

问题3——脚本抛出异常

在问题2举的例子中，脚本执行的时候没有抛出异常，但是其执行的结果却不是我们所期望的。在下面这个例子中，脚本的执行过程甚至会抛出莫名其妙的异常。

<script type="text/javascript">
    alert("对象初始化");
</script>

如果你真到第8行去看那段脚本，你会发现，你死活就是看不出问题来，直到你把中文替换成英文之后你才可能会恍然大悟。

问题4——引用外部脚本导致的异常

现在我们把页面存储成gb2312，再运行问题3中的示例代码，这个时候就没有问题了。为了Html页面的纯洁性，我们将脚本移到一个独立的Js文件中去，并在Html中引用这个脚本文件。如下：

页面index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
    </head>
    <body>
        <script type="text/javascript" src="script/test.js"></script>
    </body>
</html>

脚本script/test.js
alert("对象初始化");

这个时候再查看index.html页面的时候，我们发现，脚本又抛出问题3的异常来了。这是为什么呢？

这是因为，当Html页面在引用一个外部资源的时候，使用的字符集就是当前文档字符集。因此test.js文件会被浏览器使用gb2312字符集去解析，而我在Aptana中建此文件的时候，默认的文件存储格式就是utf-8，因此还是回归到了文档字符集和存储字符集不一致的问题上来。

这个问题，我们可以通过在引用外部资源的时候显式指定charset属性来解决。

<script type="text/javascript" src="script/test.js" charset="utf-8"></script>

update:

以上试验提到的UTF-8均指UTF-8 without BOM，即不带标记的UTF-8。IE、Chrome、Opera和Safari均能支持BOM标记，这就意味着，如果你的文件本身是以UTF-8 with BOM编码的，那么无需指定charset，浏览器也能正确解析。此优先级最高。Firefox则无法正确识别BOM标记，因此总会以页面中指定的charset或者HTTP响应中的charset来解析文档。

pingqingbo

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
文档字符集导致的脚本错误

Html页面中可以通过meta标签指定页面文档使用的字符集，这样浏览器就会根据此标签使用指定的字符集去解析文档流，而不用靠“猜”了。meta http-equiv="Content-Type" content="text/html; charset=utf-8" />文档字符集需要对应文件实际存储使用的字符集，否则会引发很多意料不到而又难以调试的Bug。问题1——页面显示乱码如果文
复制链接

扫一扫

专栏目录