昨天在調試 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好象最初的版本里沒有使用，如果換成這個，估計代碼工作量非常大，先將就著點了