- 论坛徽章:
- 0
|
高手们帮偶瞧瞧
我今天发现了我在编译php5.1.2的过程中和一个库文件出现了不兼容的情况
提示和libiconv-1.9.2p1.tgz这个库文件指针不兼容
libiconv介绍
由于历史原因,国际化的文字常常由于语言或者国家的原因使用不同的编码。随着互联网时代的到来,通过互联网进行文字交流也逐渐增多:浏览外国的网站,这个时候字符编码的转换变得尤为重要。这带来了一个问题,就是许多字符在某一种编码方式中没有。为了解决这种混乱,Unicode的编码方式被建立。Unicode是一种超级编码包含了所有这些编码的字符集,因此一些新的文本格式像XML的默认编码方式就是Unicode.
但是很多老式的计算机还在使用当地的传统的字符编码方式。而一些程序,例如邮件程序和浏览器必须能在这些不同的用户编码之间作转换。其他的一些程序则内置支持Unicode,以顺利支持国际化的处理,但是仍然有在Unicode和其他的传统编码之间转换的需求。GNU的libiconv就是为这两种应用设计的编码转换库。
详细资料
libiconv库为需要做转换的应用提供了一个iconv()的函数,以实现一个字符编码到另一个字符编码的转换。
包括的编码有:
欧洲语系
ASCII, ISO-8859-{1,2,3,4,5,7,9,10,13,14,15,16}, KOI8-R, KOI8-U, KOI8-RU, CP{1250,1251,1252,1253,1254,1257}, CP{850,866}, Mac{Roman,CentralEurope,Iceland,Croatian,Romania}, Mac{Cyrillic,Ukraine,Greek,Turkish}, Macintosh
犹太语系
ISO-8859-{6,8}, CP{1255,1256}, CP862, Mac{Hebrew,Arabic}
日文
EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1
中文
EUC-CN, HZ, GBK, GB18030, EUC-TW, BIG5, CP950, BIG5-HKSCS, ISO-2022-CN, ISO-2022-CN-EXT
朝鲜文
EUC-KR, CP949, ISO-2022-KR, JOHAB
亚美尼亚语
ARMSCII-8
格鲁尼亚语
Georgian-Academy, Georgian-PS
塔吉克语
KOI8-T
泰国语
TIS-620, CP874, MacThai
老挝语
MuleLao-1, CP1133
越南语
VISCII, TCVN, CP1258
特殊平台
HP-ROMAN8, NEXTSTEP
全部Unicode
UTF-8
UCS-2, UCS-2BE, UCS-2LE
UCS-4, UCS-4BE, UCS-4LE
UTF-16, UTF-16BE, UTF-16LE
UTF-32, UTF-32BE, UTF-32LE
UTF-7
C99, JAVA
按照uint16_t或uint32_t的全部Unicode(with machine dependent endianness and alignment)
UCS-2-INTERNAL, UCS-4-INTERNAL
按照`char'或`wchar_t'的某些本地依赖 (with machine dependent endianness and alignment, and with OS and locale dependent semantics)
char, wchar_t 犹太语系
空编码名称等价于"char",它不依赖于本地编码
当选择了配置选项 --enable-extra-encodings 以后,会支持下面几种扩展编码:
欧洲语系
CP{437,737,775,852,853,855,857,858,860,861,863,865,869,1125}
犹太语系
CP864
日语
EUC-JISX0213, Shift_JISX0213, ISO-2022-JP-3
土库曼语
TDS565
特殊平台
RISCOS-LATIN1
通过到Unicode的转换,所有这都可以互相转换些编码。
当然这个翻译也有局限性,比如当一个字符在目标的编码里没有的对应字符的时候,转换程序会自动选择一个最相近的。当目标编码前面加上"//TRANSLIT"的时候,转换开始。
libiconv多被用在应用需要多字节编码而目标系统部支持多自己编码的时候。
[ 本帖最后由 robinwu2008 于 2006-5-15 10:52 编辑 ] |
|