HANDLE hFile = openfile_help(L"1.txt");
DWORD sizefile = GetFileSize(hFile,NULL);
HANDLE m_hMap = CreateFileMapping(hFile,NULL,PAGE_READWRITE,0,sizefile,L"mapfile");
WCHAR * m_LibStartAddress = (WCHAR*)MapViewOfFile(m_hMap,FILE_MAP_ALL_ACCESS,0,0,0);
printf("%d, %d", *m_LibStartAddress, L'人'); ::UnmapViewOfFile((void*)m_LibStartAddress);
::CloseHandle(m_hMap);
::CloseHandle(hFile);
1.txt里面也有一个人字，怎么输出不一样呢
DWORD sizefile = GetFileSize(hFile,NULL);
HANDLE m_hMap = CreateFileMapping(hFile,NULL,PAGE_READWRITE,0,sizefile,L"mapfile");
WCHAR * m_LibStartAddress = (WCHAR*)MapViewOfFile(m_hMap,FILE_MAP_ALL_ACCESS,0,0,0);
printf("%d, %d", *m_LibStartAddress, L'人'); ::UnmapViewOfFile((void*)m_LibStartAddress);
::CloseHandle(m_hMap);
::CloseHandle(hFile);
1.txt里面也有一个人字，怎么输出不一样呢
一个是：ff fe ba 4e 另一个是：ba 4e 00 00
看出不同了没？
其中的“ba 4e”都表明是“人”，但是高16Bit却不同，造成了转换成数值后的差异。
一个汉字本身只有2Byte(16Bit)，而printf()却读取了4Byte(32Bit)，然后转换，这就是
最终结果不同的原因。
跟直接的字符串有所不同。
printf("%x, %x", *m_LibStartAddress, (L'人'));这样的输出结果是feff, 4eba
Unicode 标准和ISO 10646将0xFEFF定义为字符“零宽度不换行的空格”，同时一般也认同为“字节顺序标准(简称为BOM)”。后者暗示了该字符除了通常的在文本中作为“零宽度不换行的空格”使用外，还有另一种可能的用处。根据Unicode第2.4节和ISO 10646附录F(完整版)所建议的，将0xFEFF字符作为Unicode字节流中的一个“签名”；当接收方收到一个字节流的时候，借助这个首字节，既可以确定该字节流包含了Unicode字符，也可以用来辨认线性化的顺序。在带有该签名的线性化UTF-16流中，如果开始的两个八位字节为0xFE后面跟着0xFF的话，线性化顺序就是big-endian；如果为0xFF后面跟着0xFE，线性化顺序就是little-endian。注意0xFFFE 并不是一个Unicode字符，所以正好用它来作为字节顺序的标志。
很重要的一点就是，如果字符0xFEFF在字节流中的其他地方而不是首字节出现的话，它就必须被解释为“零宽度不换行的空格”。但这句话的反义并不总是正确的：在字节流首位出现的字符0xFEFF可能被解释为“零宽度不换行的空格”，而不一定总是字节顺序标志。
举例来说，如果一个处理将一个UTF-16字符串分隔为许多个部分，那么其中某个部分的子串正好是以零宽度不换行的空格开头的话，就可能以0xFEFF开头。
此外，Unicode标准还建议在开始处理文本前，应该将开头的0xFEFF字符去掉，这样建议的原理是因为在开始位置的这个字符可能是人为添加的编码（一个编码的签名），而不是真正意义上的“零宽度不换行的空格”。需要注意的是这样做可能会影响在另外一个不同层中需要依靠流中所有字符进行处理的外部处理过程（比如说一个数字签名或对字符的计数）。
特别地，虽然有例外情况，但在UTF-16纯文本中，以0xFEFF开始的字符非常可能是一个签名。当连接两个字符串的时候，将这些签名去掉就显得非常重要了，否则生成的字串中的连接点上就可能包含本来没有的“零宽度不换行的空格”。此外，有一些规范要求那些标明为UTF-16的对象必须在开始位置保留0xFEFF字符，同时注明该签名并不是对象本身的组成部分。就是MapViewOfFile最终结果数据前有“字符串头”，"ff fe"，。
原来如此