这两个函数各有特点，
1、iconv速度快，自然优先选择，但是他有个缺点，如果遇到自己不能转换的字符，就从那里截断。这就导致转码中内容被无故截断。
2、mb_convert_encoding函数效率比较低，但是他遇到无法转换的内容不会截断，这很大程度保留了内容的完整性。但是我发现比如内容有空格，转换出来的内容就有？符号，还是不够完美。
如何结合这两个函数对字符进行转码？
我的思路是这样的：
优先肯定使用iconv函数，因为效率高，而且是内置函数。discuz的转码函数也是优先使用此函数，但是他转码不完整的情况下，就要安排mb_convert_encoding去收拾残局了，问题来了，如何判断他转码不完整？
采用 php+mysql 数据库方式运行的强大网上商店系统，执行效率高速度快，支持多语言，模板和代码分离，轻松创建属于自己的个性化用户界面 v3.5更新： 1).进一步静态化了活动商品. 2).提供了一些重要UFT-8转换文件 3).修复了除了网银在线支付其它支付显示错误的问题. 4).修改了LOGO广告管理,增加LOGO链接后主页LOGO路径错误的问题 5).修改了公告无法发布的问题,可能是打压
回复讨论(解决方案)
虽然 mb_convert_encoding函数 需要加载 php_mbstring 扩展
但加载了就不能说不是内置函数了
对于不可识别的字符，iconv 提供了两个开关供你选用，并不是一味的截断
//TRANSLIT 用相近的字符替代
//IGNORE 丢弃并继续
虽然 mb_convert_encoding函数 需要加载 php_mbstring 扩展
但加载了就不能说不是内置函数了
对于不可识别的字符，iconv 提供了两个开关供你选用，并不是一味的截断
//TRANSLIT 用相近的字符替代
//IGNORE 丢弃并继续
好像我也加了IGNORE 函数，但是有些内容转码还是不够理想。
换句话说，有时候用iconv 行，mb_convert_encoding不行，mb_convert_encoding行，iconv 又不行
虽然 mb_convert_encoding函数 需要加载 php_mbstring 扩展
但加载了就不能说不是内置函数了
对于不可识别的字符，iconv 提供了两个开关供你选用，并不是一味的截断
//TRANSLIT 用相近的字符替代
//IGNORE 丢弃并继续
试验了一下，IGNORE也许是可以绕过去的（之前遇到不能饶的），但是转换某些字符时，把字符丢失了。
比如把“?”符号的转换成gb2312时，iconv没转换过来，但是mb_convert_encoding转换过来了。所以二者各有优缺点，现在只是想怎样才能比较完美的结合起来使用。
