最近几天起的越来越早.. 早上与实验室外面的门纠结了大半个小时，－ －
ZZ昨晚看见的一小段关于 C\C++ 输出中文的评价
还是我来给你们上一课吧。
首先按照c99支持unicode字符集，这里指内存中的字符编码，c++当然应该支持，这是毫无疑问的。
但是unicode的外部表示如utf7,utf8,utf8n,utf16le,utf16be等等外部存储格式，c++委员会显然没有理由理会这些东西，作为世界上最帅的 stl库sgi-stl3.3外带的IO流库认为自己没有义务实现各种各样的字符编码的转换。
事实上这样做会导致stl-io库对操作系统的严格区分，结果必然是舍了一群孩子才套了一只狼。所以，sgi-stl声明除了标准的“C”别的一概不予理会。
结果是如果我们使用sgi-stl而又不提供新的诸如 c_local_stub_win32.cxx这样的基于windows的c-locale底层接口的实现，像goodname那样用什么locale都不管用。
说到这里，如果你在使用stl-port，stl-port4.6比sgi-stl的野心大多了，孩子肯定是舍了，狼大约也没套多。
我并没有做过 stl-port4.6使用其他locale的例子，但我想，他的表现大约会像微软的p.j.先生的stl一样帅吧。
bcb6,cbx部署的stl库恰好就是stl-port的某个版本，如果按照goodname的办法不能成功，那么很不幸stlport又少套了一只狼。
如果你在使用ms的 p.j.先生的stl,那么你很幸运，因为你想要什么，微软都会给你的。
大体上goodname的代码应该行的通。
不过正如微软的座右铭：给你需要的，但请不要看明白我是怎么做的。
虽然微软公开stl源代码，但我宁愿自己从没有看过那个东西。
本人甚至都在怀疑微软使用过什么给这些代码加上1024位的密。使用微软的产品就像生活在Newyork一样：即在地狱又在天堂。
说到这里还没有说到重点，实际上stl-io流在处理内部字符流和外部数据流间的互转换时，使用自带的locale中指定的codecvt*对象，其中的do_in,和do_out实现转换，按照sgi-stl的实现，“c”完成内部的wchar_t和外部的char转换时不会考虑10646更不会考虑其他任何形式的mbcs，事实上c++标准根本就不认识这些东西。
所以当你想要输出汉字时，每个汉字的高位都被丢弃，很不爽吧，解决的办法就是继承一个codecvt重写do_in,do_out在里面用psdk的功能完成 unicode到mbcs的转换，使用那个代码页管用，你就自己试试吧
早上发的囧了,修改一下..