首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 开发语言 > C语言 >

[议论] GCC与unicode

2013-01-02 
[讨论] GCC与unicodeHI, 大家好小生很有意开发一套工具库 由于牵涉到跨平台和效率问题 我使用了纯C语言来

[讨论] GCC与unicode
HI, 大家好

小生很有意开发一套工具库 由于牵涉到跨平台和效率问题 我使用了纯C语言来编写

但是在处理字符串的问题上 楼主忽然头大了 因此我很希望能和大家分享我遇到的问题


问题 1) utf-8在检索上的小小问题

众所周知 utf-8能很好地兼容POSIX程序接口 而且也利于存储和网络传输 但是在检索多字节字符上却遭遇小小瓶颈

假如有utf-8的字符串 "我们都是程序猿"

但是我们却不能检索在这个字符串中的某个字符 如'程' 而必须将 程 字当做一个字符串来处理 如"程"


问题 2) 向wchar过度 却遭遇内存瓶颈

为了解决问题1) 就只能向wchar求助 但是wchar在linux c中是定义为4字节的 而通常情况下 大多数字符串都只需要两个字节就足够了 而对于utf-32来说 几乎要使用两倍的内存来保存相同内容的utf-16的字符串 这无疑是极大浪费

参考到当下比较知名的库和托管类语言的解决方案 列表如下

windows - utf-16
java    - utf-16
c#      - utf-16
Qt      - utf-16
glib    - utf-8

因此我不是很理解为何linux c偏偏使用utf-32的unicode


问题 3) 即使使用wchar还是要重写io接口

即使决定在linux下使用wchar 还有字符串打印的问题需要解决 因此在标准io接口中是区分宽窄字符的

如wprintf(L"我们都是%ls", L"程序") //注意使用的格式化输出是%ls

假如我们想使用C标准的简洁模式 却不得不实现本地化的printf


问题 4) 构建本地utf-16系统 却遭遇编译器瓶颈

为了解决以上的问题 最直接的办法就是开发一套自适应的字符串库

即将本地的字符类定义为2字节 即使需要重写整套io的接口都不是很大问题 但最大的问题却在编译器上

因为当下的GCC版本无法接受utf-16的字符串字面量

并且当前C环境下没有任何办法将Utf-32或utf-8的字符串字面量直接转换为utf-16


问题 5) 回到问题最初 unicode真的值得吗

实现想不到一个wchar就会引出如此之多的问题 这不禁让我想到问题最初 我们真的需要unicode吗

或许基于utf-8的ansi c就足够了呢 

顺便提一点 glib使用的是utf-8


楼主一下子想到了很多 恐怕在下在技术上还有很大疏漏 因此不排序楼主在某些地方确实想多了 

因此楼主将这些问题列举出来 供大家一起思考



[解决办法]
问题1)L'程'在内存中如果用utf8编码占3个字节。
问题2)linux c可以使用utf-16
问题3)wprintf需要事先setlocale
问题4)自己编写Utf-32或utf-8的字符串字面量直接转换为utf-16
问题5)不妨写一个同时显示中文简体、中文繁体、韩文、日文、阿拉伯文的记事本试试

热点排行