之前就写了文件分割器，经过了各种优化后，感觉不错，那时我就想写一个文本分割器，但是由于对字符编码的不熟悉，所以迟迟没有开工。
最近学习win32编程，虽然老师是在VC6.0下面教授内容，但是因为之前有过自学，加上其它种种原因，我一直就在VS2008下编写。在VS2008下默认使用Unicode字符集(当然，其实是可以使用第二个选项的多字节字符集）。
昨天回去后查了一些资料终于解决了在_wfopen函数打开Unicode文本时，输出到终端和输出到文本里乱码的问题，有了这个基础后，今天我就打算花费一点时间去写一个分割Unicode编码的文本的文本分割器。
悲剧啊，上午搞了3个小时结果输出到文件中时还是有乱码。下午我问了老师，老师说要用二进制方式打开文本。我一试，还是不行，但是我发现我对二进制和文本方式打开文件的不同点不能很清楚的分别，又翻了一会儿书。
又重新分析上午的代码，我用UltraEdit以16进制方式打开分割后的文本，发现乱码的文件没有开头FFFE，但是以文本方式打开时，虽然会自动加入FFFE，但是内容仍然乱码。
于是我尝试认为的加入FFFE，关键的部分来了，我是以FFFE的顺序写入到文本，然后运行程序：
毫无头绪的错误。经过跟踪发现是在fwrite时出错了，我百思不得其解。后来无意中用记事本查看文本编码时，才发现问题：
而正常的状况时，应该是小端法存储数据的（如下图），现在再看上图的错误，其实系统已经告诉我了错误原因了。
于是我已FEFF的顺序写入文本。见证奇迹的时刻到来了，
总结：通过今天的问题，我发现，虽然我之前知道X86架构的cpu是采用小端法存储数据，但是我们在一些常见的编辑器中看到的数据已经是编辑器转换成人类熟悉的格式了，所以当我尝试去直接操控这些数据的存储时，必须采用原始的机器识别的方式。