从NT向solaris 8移植C/C++应用
客户端：WINDOWS2000/XP
服务端：NT/SOLARIS/AIX等
最近在向solaris 8中移植应用（服务端应用），遇到的问题还不少。
该应用涉及到的东东有：
IBM MQ530相关，TUXEDO8.0 Xeces-c2.4 iconv zlib等
问题一：
在TUXEDO FML中的中文返回前端是乱码。但同样的代码在NT下没有问题。
说明：
在该系统中，服务端会将TUXEDO的FML转化为XML再以UTF-8的编码转到客户端，按常理，只要返回前端是的UTF-8的字符编码，应该没问题，因此先查返到前端的中文数据，发现果然不是UTF-8，后再服务端单独拿Xerces做实验，发现它的确有问题，因为当时服务端的本地编码应是GBK，但Xerces本身并不支持GBK，因此，把本地编码转成UTF-8时变得乱七八糟，后来用一种最快的方法解决了该问题，不用解析器，而是直接拼字符串，代码也不会很复杂，拼完后用iconv转成UTF-8即可。
问题二：
客户端的中文到服务端TUXEDO端后也是乱码
说明：
该问题其实与上面的问题是一样的，但处理却有很大不同，首先，由于前端XML数据复杂，因此必须选用解析器也不能靠自己去解析，其次，Xerces应该可以正常解析UTF-8的XML文档，为什么出来得不到UTF-8呢？原因是当从DOM中取得XMLCh型的字符串时，还要调用XMLString::transcode方法得到char *，但这过程中Xerces却自作聪明的想转成本地编码，结果转出来的东西乱七八糟不能使用，解决方法是从XMLCh用XMLFormatter直接让其输出UTF-8的字符串，再用iconv转成本地编码压入到FML。（从XMLCh到UTF-8的char *应该有比我更好的方法，欢迎指教）
问题三：
一运行到使用vector处便core dump!
说明：
试图push到vector的类型是一个结构体，大体如下：
struct a{
string a1;
string a2
}
后经查，在对结构体赋植前，对其进行了memset操作，类似：
memset(a, 0, sizeof(a));
去掉该操作后，一切正常，原因是，结构体内有复杂类型，应在构造函数中初始化才是安全的，但这些代码在NT下正常。
问题四：
压入FML内的数据出来后变成了0
说明：
原因是在Fadd时，该字段其实是short型，但却压入了一个int型，但FML的操作中只是压入了最初的两个字节，取出来时当然也只有最初压入的两个字节，这种代码在字节序不同的机器上运行的结果是不一样的。
