昨天在调试 WAP 网站时发现，在增加了 GB2312 到 UTF-8 转化以后，有些页面显示不正常了——有些页面只有一半的内容，另一半被截掉了。因为被截掉的部分包含了<p>的后半个标签</p>，因此整个页面都显示不出来，而报告错误。经过猜测、尝试，最后终于把问题集中在了 iconv 函数上。在经过高人指点以后，发现这个函数的第二个参数，除了可以指定要转化到的编码以外，还可以增加两个后缀：//TRANSLIT 和 //IGNORE，其中 //TRANSLIT 会自动将不能直接转化的字符变成一个或多个近似的字符，//IGNORE 会忽略掉不能转化的字符，而默认效果是从第一个非法字符截断。但是我尝试了//TRANSLIT 和 //IGNORE 这两个后缀，效果还是不对。于是我想问题可能不是出在这里。
从 GB2312 到 UTF-8 转化应该不会有不能转化的字符，因为 UTF-8 的字符集完全包含了 GB2312 中的字符，所以我tb想大概是前面要转化的字符集指定错了，于是我尝试着把 GB2312 改成 GBK
$ary=addslashes(iconv("GB2312", "UTF-8", $ary));
问题解决！虽然那两个后缀在这里没派上用场，不过也算学了一招，以后肯定会用到的。补记：改成 GBK 后，发现仍然有一封邮件的内容解析不正确。在另一位高人指点下，先换成 GB18030，问题依旧，然后改用 mb_convert_encoding 进行转换，问题解决！不知道是 mb_convert_encoding 问题，还是我的系统问题，我用 mb_convert_encoding 时不支持 GB18030 编码。另外，用 GBK 或者GB18030 作为输入编码，并在输出编码中加上 //IGNORE 后缀，用 iconv 函数也能解决那封含有错误编码的邮件内容解析不正确的问题。不过用 mb_convert_encoding 可以指定多种输入编码，它会根据内容自动识别，这个比 iconv 要好的多。 这里可以将iconv改成从gbk到utf8的转换,不使用gb2312.
$ary=addslashes(iconv("GBK", "UTF-8", $ary));
其实，同事在生成图片文字水印的时候也遇到了这种问题，同事最初用的是GB2312字符集，结果直接报错，说是字符串的offset有问题，但仔细检查后却没有这种问题。后来才发现是直接调用的这个iconv转换出错了。
原来的转换是从gb2312往 UTF8转换，表面上确实没有什么问题，然而，现在的人特别爱装酷，受影响的那位同志，用的是繁体字，繁体字的字库大多情况是属于GBK的，所以后来换成GBK后就正常了。
估计以后再遇上用火星文的朋友，就真的只能使用andot提出的这种方法了。转换成18030，再使用ignore参数。哈哈
mbstring好象最初的版本里没有使用，如果换成这个，估计代码工作量非常大，先将就着点了