再谈UTF-8

    首先要对先前的一篇文章做个纠正，BOM和非BOM Google Earth 都是支持。
    那先前为什么会出现乱码呢？首先要说的是对文件的编码分客户端显示、和服务器的转换。我们那这个天气预报来说。我们的目的是要在GE上显示天气情况，GE作为一个客户端使用的是UTF-8来解析的，他的KML文件里的声明也是UTF-8。
    那好，我们就从这里来一步步的反向查看数据流动的过程以及编码的过程。这个系统有表单页、数据写入数据库页面、数据库、读取数据库生成KML文件页和KML文件。GE客户端显示的是KML文件，他必须是UTF编码的，而这个KML是由ASP页面动态生成的，那我们目标就转向这个ASP页面。我们发现这个页面不在任何浏览器上显示而是直接在后台执行后生成了一个KML文件，那在后台的过程中我们用到了JS脚本，那这里除了在产生的KML文件内容里要<?xml version="1.0" encoding="UTF-8"?>这句，而且在我们的脚本声明里也要指定codepage="UTF-8"这样生成的KML文件才不会出问题。ASP内部是Unicode的，所有文本都是Unicode存储的。需要时转换到指定字符集。codepage指定了IIS按UTF-8编码读取传递过来的字符串
    好，我们到了ASP页面了。如果在这个ASP页面里没有从外部其他地方获取数据那这篇文章就可以到此结束了。但我们发现在这个ASP页面里又从数据库里读取了数据。access里面保存的数据是unicode的，在任何语言系统下都能显示。这里还要说这个depage，他指定了数据从数据库里读取后转换到的目标编码，也就是这里我们需要的UTF-8。如果数据库没问题，那我们到这里也就不会出问题，那数据库会出问题吗？那我们就要看是怎么写入数据库的了。
    数据库的写入。数据的写入我们有个前台的页面上面有表单填写后递交到写入代码来执行数据入库操作。那我们就从这个前台页面开始，在这个前台页面我们要在<meta>标签里面指定一个字符集<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />这个将要指定表单里的数据按什么编码发送（我们看看从输入法开始的编码过程：输入法Unicode–输入框unicode–从Unicode按charset转换到对应编码()–表单发送编码），这里就应该了解charset=UTF-8的重要性了。而还有一个<meta>标签里是<meta http-equiv="Content-Language" content="UTF-8" />，这句是给浏览器的，提示浏览器按什么编码来解析这个表单页。这样我们就可以正确的把表单里的数据按UTF-8发送出去了。发送后再看入库代码的操作。
    写入数据库。入库的时候先要接受表单页的数据。先前说了表单页是以UTF-8的形式发送的，那在保存页里接受的数据也就是UTF-8的，在写入数据库的过程中是把当前获得的数据按保存页面里depage指定的编码进行Unicode映射，再写入到数据库，这就是上面说的access里面保存的数据是unicode的，我们试想一下，如果我们在保存页里depage的值设为"gb2312"，那就和先前的UTF-8不匹配了，当然就可能出现乱码。正确的写入了数据库才能保证以后读取的时候不出问题。