2011年七月月 发布的文章

也谈阿根廷队2011美洲杯首演

相信今天上午进行的2011美洲杯阿根廷队的首演又让广大阿根廷球迷"上火"了。同为阿根廷球迷,我和大家的心情是一样一样的。

事实上我也只是看了下半场比赛。这里我还是要提醒那些尚未亲眼观看阿根廷的比赛的朋友们:你需要有一颗坚强的心,否则伤不起啊。一句话概括这场比赛:后防风声鹤唳、中场平庸无奇、前场单打独斗。这似乎是这几年来阿根廷队一贯所表现出来的风格。

阿根廷球迷,真悲哀啊。我们遇到阿根廷足球一个低谷时期。阿根廷足球人才培养管理混乱,青黄不接,特别是中场人才和后卫人才严重短缺。最明显的表象就是阿根廷两大豪门的现状:河床降级,博卡挣扎。前年(2009)的南美解放者杯冠军拉普拉塔大学生队的中场核心居然还是年迈沧桑的贝隆,这与世界新王西班牙的人才辈出对比反差明显。在以上的大背景下,这场比赛的结果似乎也就不足为奇了。

肯定有人反驳:我们有两届金球先生、世界第一人梅西啊,我们应该取得胜利才对。提到梅西,更让人痛苦。可怜梅西了。生不逢时啊,赶上了这么一个阿根廷队。综合阿根廷、梅西以及本场比赛,我这里抛出几个个人观点:

(一) 梅西,仅是这支阿根廷队名义上的核心。
世界上任何一只球队如果拥有了梅西,主教练都会让梅西作为进攻核心。巴蒂斯塔也不例外。赛前巴蒂斯塔就不止一次说过:梅西是阿根廷的进攻核心,其他人都应该适应梅西的提法。但通过这场比赛来看,梅西顶多算是一个名义上的核心:首先上半场顶在中锋位置的梅西很无奈,同伴根本无法创造出射门机会。还得梅西自己回中场给特维斯和拉维奇传好球。二是下半场回撤到中场组织的梅西,拿球的机会太少。你看看巴萨的比赛,哈维和小白传球的第一选择就是梅西。而反观阿根廷,似乎大家更愿意传球给特维斯那个”人民公仆“。三是即使梅西拿到了皮球,同伴也没有及时跑出空间,梅西无法传出好球(对比巴萨比赛中哈维、伊涅斯塔的传球和梅西的跑位就再清楚不过了),同样也没有人上来与梅西呼应,巴萨的比赛中经常会看到梅西、哈维和小白三人在对方的前场快速倒脚,这样做一是不丢球,二是让对方防线随动,露出破绽,等待杀机。

(二) 特维斯破坏阿根廷整体进攻节奏,抢了梅西的球权,与梅西在进攻区域无法共存
2006年的世界杯让我们认识了特维斯,但也是那届世界杯让我对特维斯的印象就不是很好。特维斯在前场接到球后,太喜欢个人带球或个人射门了。本来一次很好的团队配合,到他这就嘎然而止了。而且结果不是球丢了,就是射门偏出好远。在与队友主动寻求配合方面,他与梅西比起来差了好远,也许这就是踢球文化不同导致的吧。在巴萨熏陶出来的与在曼城熏陶出来的就是不一样。有了特维斯在前场,似乎梅西就很郁闷,拿球的机会也变少了,射门机会更是少了很多,因为都被特维斯射光了。今天下半场似乎特维斯拿球次数比梅西还多出很多。该是巴蒂斯塔抉择的时候了,要么拿下特维斯,让阿根廷走的更远;要么留下特维斯,早早离开美洲杯。

(三) 梅西需要改变,需要快速适应阿根廷的现状。
如果说梅西更适合西班牙队,相信了解梅西的人都会点头同意。没错,梅西与特维斯等不同,梅西从小就在西班牙踢球,受到的是拉马西亚足球文化的熏陶。其对于阿根廷足球的理解并不深刻,对南美球员踢球风格了解的甚少。从今天场上的情况来看,南美球员,甚至玻利维亚这样非足球强国国家的队员,对梅西的防守都要比欧洲球员到位。梅西在欧洲成长,突破欧洲球员的防线早有心得,但是南美球员的防守风格还是让梅西吃了不少苦头。梅西需要及时做出改变。需要适应南美足球的风格,需要去主动适配队友。如果梅西还想着2014年的世界杯,那么就应该在这方面多花些心思。否则还不如干脆退出阿根廷国家队得了,因为看不到赢得希望,这样也避免总是担当输球替罪羊。

其实作为阿根廷队的忠实球迷,我还是希望阿根廷能走到最后的。如果这里的”牢骚“能给阿根廷,能给梅西换来一座金光闪闪的美洲杯的话,那么我愿意再写上一万字。阿根廷的慢热也许未必不是一件好事,想想1998和2002的阿根廷,都是大热,结果死的很惨,而2010的西班牙却笑到了最后。中国有句俗话:先赢的是纸,后赢的才是钱。希望慢热的阿根廷后续能给我们带来惊喜。

也谈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。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系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

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats