晨读ZZ

最近几天起的越来越早.. 早上与实验室外面的门纠结了大半个小时，－ － 

 

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的转换，使用那个代码页管用，你就自己试试吧

 

 

 

 

 

早上发的囧了,修改一下..