最近几天起的越来越早.. 早上与实验室外面的门纠结了大半个小时,- -
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的转换,使用那个代码页管用,你就自己试试吧
早上发的囧了,修改一下..