同一篇文章，转码我优先使用iconv函数，mb_convert_encoding函数备用。
同一篇文章：phpinfo里面的iconv的信息如下
iconv implementation "libiconv"
这样用iconv转码内容完整
另一台机器phpinfo信息如下：
iconv implementation glibc
这样，用iconv转码内容不完整，尽管开启了那个忽略参数。换用mb_convert_encoding函数，内容完整。
请问如何解决这个问题？至少能想个办法，哪台机器装glibc哪台装libiconv，然后做出判断，选用不同的转码函数吧？
回复讨论(解决方案)
估计你是*nix下的
参考
http://rd.189works.com/article-38990-1.html
说到底是码表的问题，必要时自己做码表就是
估计你是*nix下的
参考
http://rd.189works.com/article-38990-1.html
说到底是码表的问题，必要时自己做码表就是
我也说了嘛，用mb_convert_encoding函数肯定能解决啊，关键是你得判断何时先用mb_convert_encoding函数，何时先用iconv函数，优先肯定用iconv函数的，因为效率高，何况mb_convert_encoding也有自己的少许缺陷。
引用 1 楼 snmr_com 的回复:估计你是*nix下的
参考
http://rd.189works.com/article-38990-1.html
说到底是码表的问题，必要时自己做码表就是
我也说了嘛，用mb_convert_encoding函数肯定能解决啊，关键是你得判断何时先用mb_convert_encoding函数，何时先用iconv函……
照那个方法，估计是要判断操作系统了，linux就先用mb_convert_encoding，window就先用iconv，可是这真是完美解决方案吗？
glibc是gnu发布的libc库，即c运行库。glibc是linux系统中最底层的api，几乎其它任何运行库都会依赖于glibc。glibc除了封装linux操作系统所提供的系统服务外，它本身也提供了许多其它一些必要功能服务的实现。由于 glibc 囊括了几乎所有的 UNIX 通行的标准，可以想见其内容包罗万有。而就像其他的 UNIX 系统一样，其内含的档案群分散于系统的树状目录结构中，像一个支架一般撑起整个作业系统。在 GNU/Linux 系统中，其C函式库发展史点出了GNU/Linux 演进的几个重要里程碑，用 glibc 作为系统的C函式库，是GNU/Linux演进的一个重要里程碑。
libiconv历史简介
由于历史原因，国际化的文字常常由于语言或者国家的原因使用不同的编码。随着互联网时代的到来，通过互联网进行文字交流也逐渐增多：浏览外国的网站，这个时候字符编码的转换变得尤为重要。这带来了一个问题，就是许多字符在某一种编码方式中没有。为了解决这种混乱，Unicode的编码方式被建立。Unicode是一种超级编码包含了所有这些编码的字符集，因此一些新的文本格式像XML的默认编码方式就是Unicode.
但是很多老式的计算机还在使用当地的传统的字符编码方式。而一些程序，例如邮件程序和浏览器必须能在这些不同的用户编码之间作转换。其他的一些程序则内置支持Unicode，以顺利支持国际化的处理，但是仍然有在Unicode和其他的传统编码之间转换的需求。GNU的libiconv就是为这两种应用设计的编码转换库。