DotNetNuke作为开源项目，很多地方为我们提供了优良的示范，得以一窥前人的智慧。前几日，因为研究一个DNN的BUG，对文件编码和文件编码相关方面的处理有一些认识。
我们经常需要把一个Text文件（如XML，SQL Script）上传到服务器，然后进行处理（如显示或者执行），这里就涉及到文本文件编码的问题了。
什么是文件编码
首先我们来复习一下编码的基本概念，由于历史原因，Text文件存在ASCII，Unicode，UTF-8，UTF-7等等编码方式;对于中文，还有GB2312;对于Unicode还有Unicode-16，Unicode-32;对于Unicode-16又分为Unicode-16 Little Endian，Unicode-16 Big Endian。要把所有的编码方式列举出来是相当的复杂。想仔细的研究一下各种编码的规则和由来可以参考一下这篇文章：编码,charset,乱码,unicode,utf-8与net简单释义。我们读取一个文本文件时，总是使用某一种编码方式去解码这个文本文件，如果我们使用的解码方式和文本文件本身的编码方式不一致，最后的结果就是得到一个乱码的文件。
我可以不用关心这个麻烦的文件编码吗
大致了解了什么是文件编码，我们来看看在DNN里为什么要和文件编码打交道，这么麻烦，我们不能绕开它吗？
在DNN里，人们可以制作和上传皮肤，模块，语言包的。就拿模块包说吧，模块包里包含各种文本文件，比如定义模块的.dnn文件，数据库的SQL 脚本文件等等。因为DNN是一个开源软件，世界上任何一个地方的人群都可能使用它，所以这些文本文件可能以各种编码格式存储，你无法强制别人只用某一种格式来储存，我们只能侦测每一个遇到文本文件的编码方式，并做对应的解码。
这里要强调的一点是：对于DNN，对文本文件的编码方式做了一些限制，那就是一定要使用带有BOM的Unicode格式，其它格式都一律按不支持处理。所以DNN的代码并不是一个彻底的解决方案，但事情总是取一个平衡，为20%的应用在多做80%的工作，有时候是没必要的。
如何解决文件编码转换的问题
回到我们的问题，对于一个上传到服务器的Text文件，我们要解决的问题就是：“如何得知这个文件的编码方式，并用正确的方式解码，得到 文本文件中的内容。”
如何得知这个文件的编码方式
首先我们来看看如何得知文本文件的编码方式，为了简化问题，我们只讨论Unicode编码这种形式（实际上DNN里也只针对Unicode做了处理），对于其它各种编码的判别方式我们不做讨论。
BOM
这里涉及到一个BOM(Byte Order Mark) 的概念。简单的讲，在Unicode标准中，为了标示文本文件的编码类型，可以在文本文件的开始插入几个特殊的byte，通过这几个特殊的byte，应用程序就可以鉴别文本文件使用的是那种编码了。那几个特殊的byte也被称之为BOM（参考：http://unicode.org/faq/utf_bom.html ）。
对于Unicode，几种编码的BOM如下：
UTF-32, big-endian 文件的前4个byte是：00 00 FE FF
UTF-32, little-endian文件的前4个byte是：FF FE 00 00
UTF-16, big-endian文件的前2个byte是：FE FF
UTF-16, little-endian文件的前2个byte是：FF FE
UTF-8文件的前3个byte是：EF BB BF
UTF-7的规律特殊一点，不是前几个byte，而是所有的byte转换为十进制都小于127。
判定文件编码方式
知道了这一点，你也应该能想到如何判定一个文本文件的编码方式了吧。读取文件的前面几个字节，跟上面的表对比，就可以知道这个文件使用的哪一种编码了。
看看DNN的代码：这个函数在DotNetNuke.Modules.Admin.ResourceInstaller命名空间下的PaFile类里。
GetTextEncodingType
1 Private Function GetTextEncodingType()Function GetTextEncodingType(ByVal Buffer As Byte()) As PaTextEncoding
2 ''UTF7 = No byte higher than 127
3 ''UTF8 = first th
