前几天在做一个项目，碰到这样一个问题：
从服务端A post一个数组参数到另一台服务器B，数组是序列化后传递，服务端A用的是utf-8，服务端B用的是gbk(没办法，因为其他原因实际需要这么设置，不是我喜欢没事找事～)。
一开始测试的时候都用英文，都能成功，也没太在意。后来突然传了一串中文字符，结果到服务端B发现中文变成了乱码。编码问题，几乎而且完全确定和肯定～ 折腾了一会儿，终于用iconv搞定了转码。。
但是新的问题又来了。。服务端B接收不到数组。。汗～～写了log检测，发现数据传递是成功的，数组参数也确实传递过去了，编码转换也没问题～～可是。。反序列化就是得不到数组～～那问题应该就是在数组的序列化和反序列化上面了。。
结果又折腾了好久。。找了好多资料，又不断重复调试，切回英文是成功的，切到中文就不行～～冷静。。冷静。。哦。。忽然间想到。。utf-8的长度为3个字节，gbk的长度是2个字节，会不会是这个原因。
回过头去检查，才发现当时为了图方便，是将数组序列化后进行转码。。问题就来了。。因为反序列化是根据指定的长度进行的，假设有一个字符串 "中文", utf-8长度为3，序列化后是 s:6:"中文"，再做一下转码，还是 s:6:"中文"，可是这时候 "中文" 两个字的实际长度是4，结果反序列化的时候长度不匹配，就导致反序列化错误，输出空对象了～～偷懒惹的祸啊。。改吧～
后来修改了一下转码函数，加了个递归，实现了对数组的转码，将数组转码后再序列化，传过去反序列化。。搞定！
总结两点：
1) 没事儿尽量不要玩多编码通信，能统一编码尽量统一
2) 万一没办法要用到多编码通信，在进行跟长度有关的操作，例如截取字符串/序列化和反序列化等这类操作的时候千万要注意中文字符的长度～～
另外，补充一点。。注意文件的实际存放编码，这个可能也是一些问题的源头～
