标签 GCC 下的文章

也谈C语言对国际化的支持

C语言对国际化的支持由来已久,最初开始于其第一版标准,即C89标准。在C89中我们可以看到用于支持国际化的locale.h、宽字符、宽字符串以及多字节字符(串)。而之后的"C89增补1"标准,即C90标准,以及C95标准又进一步完善了C语言对国际化的支持,增加了wchar.h、 wctype.h以及大量用于操作宽字符(串)和多字节字符(串)的标准库函数。最新一版C语言标准,即C99,让C语言对国际化的支持变得更加成熟,对非英语字符集也给予了更好的支持。

C语言支持国际化的核心就是大家所熟知的locale技术。C语言中的locale模型于C90标准中被引入。locale模型使得一些库函数的外部行为依赖于locale设置。这样的好处就是你无需重新编译代码,你发布的应用即可根据locale来满足不同区域人们的文化习惯。locale包含若干个类别,诸如LC_CTYPE、LC_COLLATE等,其中每个类别都会独立影响某些C函数的外部行为。比较常见的诸如日期时间显示方式、货币表示方式等。

例如,LC_TIME影响strftime的外部行为,不同locale情况下strftime输出的结果会有不同,见下面示例:

int main() {
        time_t now;
        char buf[1024];

        setlocale(LC_ALL, ""); /* set locale to current locale, which is "zh_CN.GB18030" */

        time(&now);
        strftime(buf, sizeof(buf), "%a, %d %b %Y %H:%M:%S GMT", localtime(&now));
        printf("%s\n", buf);

        setlocale( LC_TIME, "en_US.UTF-8" );
        memset(buf, 0, sizeof(buf));
        strftime(buf, sizeof(buf), "%a, %d %b %Y %H:%M:%S GMT", localtime(&now));
        printf("%s\n", buf);
}

这个程序在我的RedHat上输出的结果如下:
五, 01  7月 2011 10:07:59 GMT
Fri, 01 Jul 2011 10:07:59 GMT

locale另外一个重要的作用就是对字符集转换的影响。曾几何时,ASCII字符集曾是计算机上通行的字符集标准,那时的程序员一般根本无需考虑字符集转换。ASCII的好处就是每个字符可以存储在一个字节(8bit)中,其内部表示(Internel Representation)和外部表示(External Representation)是一致的,这样一来,其存储和传输都非常方便。程序内部在内存中对ASCII字符(就是一个字节)的处理(识别字符、计算字符串中字符个数、解析字符串等)也十分简单快捷。不过随着国际化的日益深入,ASCII的缺点便暴露了出来,即其编码集太小了,即便将8个bit都算上,最多也就是256(2的8次方)个字符,这丝毫没有考虑到广大亚洲人民的需要,严重"伤害"了亚洲人民的情感^_^。于是乎亚洲各个国家和地区都纷纷"自己动手,丰衣足食",制定了适合自己国家民族语言文字的字符集标准(当然了,其他大洲的国家也是这个样子的)。这些新字符集编码在满足本国语言需要的同时,也都兼容ASCII字符集,也就是说都是在ASCII字符集的基础上通过扩展字节个数达到支持更多字符的目的的。由于兼容ASCII,所以这些字符集中字符的表示都是非固定长度的,即在ASCII编码区间内的字符(即ASCII字符)用一个字节表示;超出这个区间,就会用2个或3个或更多的字节表示。这样的字符在C语言中被归类称为"多字节字符(multi-bytes character)"。

多字节字符,有着与ASCII同样的优点,即它们是面向字节的,便于传输和存储。之前用于处理ASCII的字符设备(基于字节的)都可以对多字节字符给予很好的支持。不过多字节字符缺点也同样明显。

首先就是程序内部(在内存中)处理起来十分不便。给定一个存储了某种字符集字符的字节数组,如果你没有对应的解析器,你是无法识别字符边界,无法识别出数组中究竟包含了哪些字符的,更不用说返回字符个数等操作了。针对这一问题,C语言引入宽字符的概念,宽字符集中的字符所占用的字节数是相同的,要么都是2 个字节,要么都是4个字节(3字节不利于计算机内存寻址优化),一般最大就是4个字节了,因为4个字节已经可以涵盖全球已知所有语言的所有字符了。在 GCC中,默认C语言宽字符类型,即wchar_t类型的长度为4。我们在内存中操作宽字符显然要比多字节字符更加容易:每个字符与N字节一一对应,这样对于统计字符个数、解析和识别字符大有裨益。因此在考量了多字节字符和宽字符的特点后,一般我们会使用宽字符作为字符在程序中的内部表示(用在各种内存操作中),而在存储、传输和显示过程中则使用多字节字符。再多罗嗦几句:宽字符为何不适于传输和存储呢?大致有以下三个原因:

- 空间利用率不高,或者说比较浪费空间和带宽
我想这个原因不用过多解释了。如果用4字节的宽字符存储一篇英文文章,那么与多字节字符相比,宽字符要浪费3/4的空间。

- 字节序问题
宽字符一般用2或4个字节表示,这样的字符在存储和传输过程中显然会遇到字节序问题,不同的平台采用不同的字节序,这样对于同一份以宽字符存储的数据来说,可能在不同的平台上得到不同的结果。

- 与已有I/O设备兼容性差
以往的设备都是面向字节设备的,处理ASCII字符以及由ASCII扩展而来的多字节字符问题不大。但对于由两个字节或四个字节组成的宽字符来说,显然有些力不从心了。

其次由于各个国家和地区纷纷独立制定多字节字符标准,导致了不同字符集之间的不兼容。比如:GBK编码中"中"字的编码是D6D0,而BIG5中"中"的编码则是A4A4。这样一来,一些涉及文本处理的程序,比如文本编辑器,就需要花费大量的工作在了不同编码间的相互识别和解析上。这时一些组织站了出来,试图建立可以容纳全球所有语言字符的统一字符集,Unicode/ISO 10646(为方便期间,二者之间的一些差异这里就忽略不计了,以下统称Unicode)因此诞生。Unicode简单来说就是一组标量数字集合,其中每个数字映射地球上的一个唯一字符。以往大家对于Unicode的理解就是用2个字节(Unicode-16,UCS-2)或4个字节(Unicode- 32, UCS-4)进行编码的宽字符。实则不然,这些理解只是其一,因为最初使用2个字节(后来发现2个字节是严重不足的)或4个字节可以一一映射 Unicode字符集合,编码值就是Unicode字符对应的Unicode字符集表中的那个数字。但是用宽字符作为Unicode底层编码的实现方式显然也会遇到上面所说的各种问题;于是乎基于多字节编码的Unicode实现出现了,最著名的莫过于utf8了,当然还有utf16和utf32。没错,utf8字符是一种多字节字符,utf8与unicode表示字符个数的能力上是等同的。Unicode字符可以与utf8字符做一一对应的转换。和其它多字节编码方案一样,utf8也兼容ASCII编码,也是面向字节的,utf8可以完全替代各个国家地区自己制定的那些私有编码方案。事实上,目前 utf8已经是全球字符编码的事实标准(de facto standard)了。

我们现在来实现这样一个程序:它可以在不同locale下输出foo.dat文件中的字符个数和字节个数,其中foo.dat文件中存储的数据的编码方式为locale指定的。我们有两个思路:
1、假设我们拥有所有locale的字符解析库,我们可以将数据从文件中读取出来后,用当前locale对应的字符解析库对数据进行解析,得到字符的个数;
2、利用locale技术,将文件中的数据读取后转换为宽字符,再计算宽字符的个数,即为foo.dat文件中字符的个数。

我们粗略对比以下这两种思路,优劣立见。利用locale技术,你无需了解任何有关目标主机字符编码的细节,也无需自携带规模庞大的字符解析库,另外无需做任何修改即可支持新增的locale配置。下面就是一个利用locale技术进行字节/字符计数的例子(仅仅是个例子哦),这个程序可以在不同locale下输出foo.dat中的字符个数和字节个数:

/* wc.c */
int main(int argc, const char *argv[])
{
    int bytes = 0;
    int words = 0;

    setlocale(LC_ALL, "");
    printf("Current locale is %s!\n", setlocale(LC_ALL, NULL));

    FILE *fp = NULL;

    fp = fopen("foo.dat", "rb");
    if (!fp) {
        printf("failed to open foo.dat, err: %d\n", errno);
        return -1;
    }

    char mbs_buf[1024];
    wchar_t wcs_buf[100];
    mbstate_t s;
    size_t n;
    const char *p;
    memset(mbs_buf, 0, sizeof(mbs_buf));

    while (NULL != fgets(mbs_buf, 1024, fp)) {
        memset(&s, 0, sizeof(s));
        memset(wcs_buf, 0, sizeof(wcs_buf));
        p = mbs_buf;

        n = mbsrtowcs(wcs_buf, &p, sizeof(wcs_buf), &s);
        if (n == -1) {
            printf("failed to convert multi-bytes character to wide character, err: %d\n", errno);
            return -1;
        } else {
            bytes += strlen(mbs_buf);
            words += wcslen(wcs_buf);
        }
        memset(mbs_buf, 0, sizeof(mbs_buf));
    }

    printf("bytes = %d\n", bytes);
    printf("words = %d\n", words);

    fclose(fp);
    return 0;
}

分别在具有两个不同locale的账户下制作foo.dat:
cat > foo.dat
中华人民共和国^D (输入Ctrl+D)

在locale为gb18030下的测试结果是:
Current locale is zh_CN.GB18030!
bytes = 14
words = 7

在locale为utf8下的测试结果是:
Current locale is zh_CN.utf8!
bytes = 21
words = 7

在C语言中,除了显式调用库函数在宽字符和多字节字符之间转换外,C语言本身还有一些隐式的转换值得注意。

首先就是宽字符的转换。如果你在源文件中用L"XXX"给一个wchar_t数组赋值,那么Gcc会默认将XXX看成是utf8编码的字符串。如果你的源文件确实是utf8编码的,那么类似wchar_t w[] = L"中国"则相当于编译器做了一次utf8到unicode-32的转换;但是如果你的源码文件不是utf8编码的,比如是gb18030的,那么编译器将提示错误:“converting to execution character set:无效或不完整的多字节字符或宽字符”。这时需要你通过Gcc命令选项显式指定源码字符集类型:-finput-charset='gb18030'。

其次利用%ls输出宽字符串时也需要注意隐式转换,看下面例子:

/* widechar.c, 该文件采用utf8编码 */
int main(int argc, const char *argv[])
{
   wchar_t w[] = L"中国";
   printf("%ls\n", w);
   return 0;
}

编译ok,但执行后发现无法输出“中国"二字。printf在%ls下支持输出宽字符串,但是也是需要显式指定locale的,否则当前LC_ALL就等于"C",在"C"locale下printf显然无法将宽字符"中国"成功转换为utf8编码并输出。我们稍作修改:

/* widechar.c, 该文件采用utf8编码 */
int main(int argc, const char *argv[])
{
   setlocale(LC_ALL, "");
   wchar_t w[] = L"中国";
   printf("%ls\n", w);
   return 0;
}

通过setlocale(LC_ALL, "")将locale指定为用户当前locale,这样我们就可以顺利见到"中国"字样了。printf做了一次宽字符到utf8的转换后,再将utf8字符串打印到控制台上,为我们所见。

最后,C99支持在源码中使用通用字符名(Universal Character Name, UCN)来表示任何扩展字符集中的字符。利用\U或\u来指定一个Unicode字符,但是注意千万不要以为宽字符和\U0000nnnn或\unnnn是等价的。下面这么做是无法达到你的预期的:

wchar_t w = '\u4e2d'; /* 4e2d是"中"字的Unicode编码 */

如果按我们的预期,w中的4个字节应该依次是0×00,0×00,0x4e和0x2d。但经过实际探测,我们得到的却是0×00、0xe4、0xb8和0xad,这恰恰是"中"的utf8编码。而且编译器还在这一行给出了警告:warning: multi-character character constant。这里也是一种隐式转换,使用UCN表示的Unicode字符将首先被按照执行字符集做转换后再作为右值,此时它就和一个多字节字符串无异,所以这里使用char mbs[] = "\u4e2d"才是正确的。我们可以将\u或\U作为转义字符来看待,这样在真正的编译开始之前,当Compiler处理所有转义字符及字符串时,这些字符和字符串将被预先转换为执行字符集中对应的字符,正如\u4e2d被转换为e4b8ad。

也谈C语言的内联函数

有这样一段代码:

/* foo.c */
#include  "stdio.h"

inline void foo() {
    printf("inline foo in %s\n", __FILE__);
}

int main() {
    foo();
    return 0;
}

我采用C99标准,并在不加任何优化选项的情况下编译之:

$ gcc -std=c99 foo.c -o foo
foo.c: In function ‘foo’:
/tmp/ccLGkuIK.o: In function `main':
foo.c:(.text+0×7): undefined reference to `foo'
collect2: ld returned 1 exit status

这样的结果出乎我的意料。我原以为用inline修饰的函数定义,如上面的foo函数,在编译器未开启内联优化时依旧可以作为外部函数定义被编译器使用。但通过上面gcc输出的错误信息来看,inline函数的定义并没有被看待为外部函数定义,这样链接器才无法找到foo这个符号。C99标准新增的inline似乎与我对inline语义的理解有所不同。

C语言原本是不支持inline的,但C++中原生对inline的支持让很多C编译器也为C语言实现了一些支持inline语义的扩展。C99将inline正式放入到标准C语言中,并提供了inline关键字。和C++中的inline一样,C99的inline也是对编译器的一个提示,提示编译器尽量使用函数的内联定义,去除函数调用带来的开销。inline只有在开启编译器优化选项时才会生效。正如上面的例子,当我们打开优化选项并重新编译时,我们会看到:

$ gcc -std=c99 foo.c -O2 -o foo
$./foo
$ inline foo in foo.c

在-O2的优化选项下,编译器进行了内联优化,并采用了foo的inline定义。通过汇编代码我们也可以看出:foo.s中并没有显式地使用call进行函数调用,函数调用被优化掉了:

/* foo.s : gcc -std=c99 foo.c -O2 -S */
    .file   "foo.c"
    .section    .rodata.str1.1,"aMS",@progbits,1
.LC0:
    .string "foo.c"
.LC1:
    .string "inline foo in %s\n"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

我们在另外一个文件bar.c中提供一个foo的外部函数定义:

/* bar.c */
#include

void foo() {
    printf("global foo in %s\n", __FILE__);
}

我们将foo.c和bar.c放在一起编译(未开启优化选项):
$ gcc -std=c99 foo.c bar.c -o foo
$ ./foo
$ global foo in bar.c

链接器为foo.c中的符号foo选择了bar.c中的foo函数定义。这样看来我们甚至可以有两个同名(名字都是foo)的函数定义,只不过一个是inline定义,一个是外部定义,它们并不冲突。

再开启优化选项,我们得到:
$ gcc -std=c99 foo.c bar.c -o foo
$ ./foo
$ inline foo in foo.c

这一次编译器选择了foo的inline定义。

究其原因:foo.c和bar.c分处于两个不同的编译单元,在未开启内联优化的情况下,foo.c对应的目标文件foo.o中foo只是一个未定义的符号,而bar.o中的foo却是一个global符号,并对应一块独立的实现代码。链接器自然采用了bar.c中的foo函数定义。而在开启了内联优化的情况下,编译器在进行foo.o这个编译单元的编译期间就直接对foo进行了优化,并采用了foo的inline定义,直接放到了main函数的汇编代码中,没有显式地call foo,并且foo.o中并未为foo单独生成Global函数代码,这样在最后的链接阶段,bar.o就变成"打酱油"的了^_^。

以上只是为了说明C99内inline语义而做的试验。在现实开发中,我们绝不应该这么去做。我们要确保函数的inline定义和非inline定义的语义一致性。那能否做到让一份函数定义既可以作为inline定义,也可以作为外部函数定义呢?这意味着我们在开启内联优化时,既要在inline函数定义的编译单元里执行内联优化,也要为inline函数生成一份独立的global的函数定义(汇编码)。

我们增加一个头文件foo.h:
/* foo.h */
extern void foo();

/* foo.c */
#include
#include "foo.h"

inline void foo() {
    printf("foo in %s\n", __FILE__);
}

int main() {
    foo();
    return 0;
}

我们在开启优化和未开启优化两种情况下分别编译执行:
$ gcc -std=c99 foo.c -o foo
$ ./foo
$ foo in foo.c

$ gcc -std=c99 foo.c -o foo -O2
$ ./foo
$ foo in foo.c

我们看到:无论哪种情况,我们都可以顺利通过编译,并且得到正确的执行结果。我们来看看汇编码有何变化:

在未开启优化的情况下,我们得到如下汇编码:

.globl foo
    .type   foo, @function
foo:
    pushl   %ebp
    … …
    call    printf
    leave
    ret
    .size   foo, .-foo

    … …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    call    foo
    … …
    ret

内联优化并未生效,main代码中进行了foo的函数调用。但与本文开始时的那个例子不同的是,编译器为foo生成了一份独立的global的函数定义汇编码块,这块代码可以直接被外部引用,也就是说在未开启优化的情况下,foo定义被看成了外部函数定义。

但开启优化选项的情况下,我们得到如下汇编码:
.globl foo
    .type   foo, @function
foo:
    pushl   %ebp
    … …
    call    __printf_chk
    leave
    ret
    … …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret

内联优化生效了,main代码中并未显式地进行foo的函数调用。并且编译器依旧为foo生成了一份独立的global的函数定义汇编码块,这块代码可以直接被外部引用,也就是说在开启优化的情况下,foo定义在本编译单元被看作内联定义,同时对其他编译单元而言,也是外部函数定义。

我们通过在头文件中增加一个外部函数声明实现了我们的目标!不过上面方法虽然实现了一份定义既可以当作inline定义,也可以作为外部定义,但inline定义仅局限于定义它的那个编译单元,其他编译单元即使在开启内联优化时,依旧无法实施内联优化。如果我们希望多个编译单元共享一份inline定义并且这份定义也可以同时作为外部函数定义,我们该如何做呢? – 那我们只能把inline定义放到头文件中了!见下面代码:

/* foo.h */
inline void foo() {
    printf ("foo in %s\n", __FILE__);
}

/* foo.c */
#include
#include "foo.h"

int main() {
    foo();
    return 0;
}

/* bar.c */
#include
#include "foo.h"

void bar() {
    foo();
}

$ gcc -std=c99 foo.c -S -O2
我们看看开启优化情况下的bar.c和foo.c对应的汇编代码,以foo.s为例:

/* foo.s */
… …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret
… …

内联优化生效,bar.s也是一样,不过编译器没有为我们生成foo的独立外部定义代码,这样的foo定义只能作为inline定义,而不能被作为外部函数定义。如果此时不开启优化选项编译,我们还会得到如下错误:
/tmp/ccpp1E7i.o: In function `main':
foo.c:(.text+0×7): undefined reference to `foo'
/tmp/ccQk872R.o: In function `bar':
bar.c:(.text+0×7): undefined reference to `foo'
collect2: ld returned 1 exit status

我们稍作改动,在foo.c和bar.c的文件开始处,我们加上这样一行代码:"extern inline void foo();",加上后,我们重新编译,这回foo在被内联优化的同时,也被生成了一份独立的外部函数定义。我们的目标又达到了!

总之,C99中inline相对比较怪异,使用时务必小心慎重。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats