客户端和服务端的编码“陷阱”（2）

三、 留意Form这个数据入口

Form的数据提交看起来是一个很简单的过程，事实上在这个背后浏览器给我们做了很多工作：（详细可参考W3C网站上的TR文档）
　　1． 检测这个Form是否标准，包括name属性是否存在，disabled是否可用等等一系列信息，同时获取到各种表单的当前值
　　2． 对于一个检测通过的Form，要把它内部的表单元素的值按照他们在文档中的出现顺序，以name/value的形式记录为一组数据集。
　　3． 根据Form的enctype属性指定的content-type对获取到的一组数据集做URL编码
　　4． 最后根据action　和method属性来向服务端发送这组数据集

这里我们需要特别留意的是第三步，这里做URL编码的数据集本身是什么字符编码了？通常情况下它会遵照网页本身的编码，这就是为何我在第二原则里建议你要明确指定你选定的网页编码。假如你的网页是GBK编码，那么表单提交到服务端的数据就是GBK的编码，如果网页是UTF-8，那么提交过去的就是UTF-8的。

这里就有一个问题，如果客户端提交的是UTF-8，而我们服务端（包括数据库）都统一使用的是GBK的编码，那会出现什么问题了？答案是：那会很棘手，服务端不得不对这个UTF-8的数据做编码转换，转换为了GBK才能入库，否则你的数据库里存入的就是UTF-8的编码，乱码又出现了。

事实上这里还有个例外的情况，在W3C的标准中Form是有一个ACCEPT-CHARSET属性的，目的单独指定FORM中的编码，这个比文档的编码设置优先级要高。我个人认为开发中用到的可能性不大，一个指定了编码A的文档，为何要发送编码B的字符呢？如果有真有这个需要，那么在服务端做转换就可以了，没有必要在客户端弄出两种不同的编码，更何况IE这个强硬的家伙又是背离标准的。

A character encoding is a method of converting a sequence of bytes into a sequence of characters.
If ACCEPT-CHARSET is not specified, the form will be submitted in the character encoding specified for the document. If the form includes characters that fall outside the character set specified for the document, Microsoft Internet Explorer will attempt to determine an appropriate character set. If an appropriate character set cannot be determined, then the characters will be encoded as HTML numeric character references. For more information on character sets and numerical character references, see HTML Character Sets. （参考：MSNDhttp://msdn2.microsoft.com/en-us/library/ms533061.aspx）

因此，我们还是“忘记”这个属 * ，没有它，我们的FORM一样可以运转得很好。（也正是因为浏览器默认会给FORM做很多不错的工作，所以我们看到的很多富文本编辑器在提交编辑内容时，都会先把这个内容写入到一个表单的value中，让浏览器自动给它编码。）

第三个原则：清楚地认识Form中的数据的编码是依照网页本身编码的，在提交到服务端之前，这组数据是做了格式化处理，然后做了URL编码。目前服务端不会智能到自动识别FORM发送过来的编码类型，更不会智能到给你自动转换为服务端统一使用的编码。