[原创]There's nothing wrong with mono's C# compiler dealing with string encoding

今天解决了一个棘手的问题。
在Mono下面，StreamReader用Encoding.Default竟然无法正常读取GBK编码的文件。

随后展开了调查，用GBK编码的源代码中文Hello world程序竟然输出乱码！
用UTF-8编码的源代码文件编译的程序就是正确的。

难道真都是Mono对编码支持很混乱的原因吗？

不！很多.NET程序员把Encoding.Default理解错了。因为在Windows平台上Encoding.Default确实等于“GB18030”也就是GBK。

但是，随着环境的不同，Encoding.Default也会改变！比如在WinCE或者是一部分Linux，Unix上，默认的编码就是UTF-8，
这时候，Encoding.Default就相当于是Encoding.UTF8！

那要如何在默认是UTF-8的平台读取GBK编码的文件呢？很简单，用Encoding.GetEncoding("GBK")就可以了，GBK兼容GB2312。

以上是个人拙见，欢迎批评指正。

PS:
Oh，yeah yeah，我知道有些人会说，如果在Windows上就没有这样的烦心事，Mono的C＃ complier应该自动处理源文件编码的问题（针对
于关于非默认编码的源文件的问题）。很不幸的告诉你，.NET Framework自带的C＃编译器同样不能正确处理非默认编码的源文件，比如
用Western什么什么的编码的源文件，特殊字符甚至会导致编译失败。但是为什么在Windows下，UTF-8编码的源文件就可以正确处理呢（
在UTF-8不是操作系统默认的编码的情况下）？说实话，that's a little tricky，因为绝大多数的UTF-8的编码都是带有BOM的，很多人应
该还对VS2003中ASP.NET使用UTF-8编码的源文件造成浏览时候变成乱码记忆犹新吧，那就是因为VS2003默认的UTF-8编码是没有BOM的！
导致C＃编译起编译ASP.NET页面的时候错误的使用了默认的GBK的编码，导致了最终页面的乱码现象。好在现在VS2005默认的UTF-8都也已
经是UTF-8 with signature了。哦，BOM的全称是Byte Ordered Mask，目的是为了区别Unicode big或者small endian的，后来被一些Geek
用来区别是不是UTF-8了，当然，这样做有利也有弊，总的来说，不够elegant。