久久综合伊人77777,色婷婷久久综合中文久久蜜桃av,久久电影网

lf426 — Mon, 22 Jul 2013 04:17:00 GMT

�q�么长时间了�Q�我的主要精力放在英语的学习上面。因为我认识到计��机�U�学与国际水�q�的差距巨大�Q�而且语言是关键。简单的��_��你不能指望别人用中文来写注释�Q�用拼音来写函数�?br />对于游戏的设计一直停留在理论�Q�前�D�|��间研�I�了下WE�Q�War3 Map Editor�Q�，发现�q�是很强大的�Q�可以实��C��部分我的游戏设计理念�Q�于是作了这么一张对战地图。其主要设计思�\��是�H�出兵力分合�Q�资源控制的�{�略�Q�减��对手速的��要求�?br />地图其他信息在这里：
http://loih.blog.163.com/

2013�q?0�?0日更新Loih Beta 0.11a Team Mode
�Q�团队模式，支持5v5�Q?br />Loih Beta 0.11a Team Mode

2013�q?�?9日更新Loih Beta 0.11a
�Q�包�?#8220;标准�Ҏ��?#8221;�?#8220;带野怪版”�Q?br />Loih Beta 0.11a

落埃生存战（��Z��Loih 0.07�Q�带AI�Q?br />落埃生存战下�?/a>

落埃�Q�无敌英雄传�?Beta 0.09e
标准�Ҏ��?.09e

落埃�Q�无敌英雄传�?Beta 0.10b
标准�Ҏ��?.10b

lf426 2013-07-22 12:17 发表评论

lf426 — Sat, 26 Jun 2010 11:55:00 GMT

<本文PDF文档下蝲>

��编码的��伤

我们现在知道�Q�C/C++的宽�H��{换是依赖�pȝ��的locale的，�q�且在运行时完成。考虑�q�样一�U�情况，我们在简体中文Windows下编译如下语句：
const char* s = "中文abc";
�Ҏ��我们之前的讨论，�~�译器将按照Windows Codepage936�Q�GB2312�Q�对�q�个字符串进行编码。如果我们在�E�序中运行宽�H��{换函敎ͼ��s转换为宽字符串ws�Q�如果这个程序运行在��体中文环境下是没问题的，��执行从GB2312到UCS-2BE的�{换；但是�Q�如果在其他语言环境下，比如是繁体中文BIG5�Q�程序将�Ҏ��pȝ��的locale执行从BIG5到UCS-2BE的�{换，�q�显然就出现了错误�?br>
补救

有没有补救这个问题的办法呢？一个解��x��案就是执行不依赖locale的宽�H��{换。实际上�Q�这��已�l�不是宽�H��{换之间的问题了，而是�~�码之间转换的问题了。我们可以用GNU的libiconv实现��L��~�码间的转换�Q�对于以上的具体情况�Q�指明是从GB2312到UCS-2BE��׃��会出错。（请参考本人前面的章节�Q?a title=win32下的libiconv href="http://www.shnenglu.com/lf426/archive/2008/03/30/45738.html">win32下的libiconv�Q�，但这昄��是一个笨拙的�{�略�Q�我们在��体中文Windows下必��M��用GB2312到UCS-2BE版本的宽�H��{换函敎ͼ��C��BIG5环境下，��必��重新写从BIG5到UCS-2BE的宽�H��{换函数�?br>
Windows的策�?br>
Windows的策略是淘汰了窄字符�Ԍ��q�脆只用宽字�W�串。所有的��编码全部加上特定宏�Q�比如TEXT()�Q�如果程序是所谓Unicode�~�译�Q�在�~�译时就��译为UCS2-BE——Windows自称为Unicode�~�程�Q�其本质是��用了UCS-2BE�?6位宽字符丌Ӏ?br>
Linux的策�?br>
Linux下根本就不存在这个问题！因�ؓ各种语言的Linux都��用UTF-8的编码，所以，无论�pȝ��locale如何变化�Q�窄到宽转换的规则一直是UTF-8到UTF32-BE �?br>
跨��^台策�?br>
因�ؓ�?6位的范围内，UTF32-BE的前16位�ؓ0�Q�后16位与UCS2-BE是一��L��Q�所以，即��wchar_t的sizeof()不一��P��在一般情况下�Q�跨�q�_��使用宽字�W�（�Ԍ��也应该是兼容的。但是依然存在潜在的问题�Q�就是那�?字节的UTF32�~�码�?br>
gettext�{�略

以上都是��ASCII及以外的�~�码��编码在�E�序中的办法。GNU的gettext提供了另外一�U�选择�Q�在�E�序中只��编码ASCII�Q�多语言支持由gettext函数库在�q�行时加载。（对gettext的介�l�请参考本人前面的章节�Q?a title=Win32下的GetText href="http://www.shnenglu.com/lf426/archive/2008/03/30/45723.html">Win32下的GetText�Q�。gettext的多语言��译文�g不在�E�序中，而是单独的提出来攑֜�特定的位�|�。gettext明确的知道这些翻译文件的�~�码�Q�所以可以准��的告诉�l�系�l�翻译的正确信息�Q�而系�l�将�q�些信息以当前的�pȝ��locale�~�码成窄字符串反馈给�E�序。例如，在简体中文Windows中，gettext的po文�g也可以以UTF-8储存�Q�gettext��po文�g��译成mo文�g�Q�确保mo文�g在�Q何系�l�和语言环境下都能够正确��译。在�q�行是传�l�win32�E�序的窄串符合当前locale�Q�是GB2312。gettext让国际化的翻译更加的方便�Q�缺�Ҏ��目前我没扑ֈ�支持宽字�W�串的版本（据说是有ugettext()支持宽字�W�串�Q�，所以要使用gettext只能使用�H�字�W�串。但是gettext可以转换到宽字符�Ԍ��而且不会出现宽窄转换的问题，因�ؓgettext是运行时�Ҏ��locale��译的。例如：
const char* s = gettext("Chinese a b c");
其中"Chinese a b c"在po中的��译�?中文abc"
使用依赖locale的运行时宽窄转换函数�Q?br>const std::wstring wstr = s2ws(s);
�q�行时调用该po文�g对应的mo文�g�Q�在��体中文环境下��׃��GB2312传给�E�序�Q�在�J�体中文中就以BIG5传给�E�序�Q�这样s2ws()总能够正常换��编码�?br>
更多

在本文的最后，我想回到C++的stream问题上。用fstream转换如此的简单，sstream却不支持。改造一个支持codecvt的string stream需要改造basic_stringbuf。basic_stringbuf和basic_filebuf都派生自basic_streambuf�Q�所不同的是basic_filebuf在构造和open()的时候调用了codecvt�Q�只需要在basic_stringbuf中添加这个功能就可以了。说��h��Ҏ��Q�实际上是需要重新改造一个STL模板�Q�尽��这些模板源代码都是在标准库头文件中现成的，但是我还是水�q�x��限，没有��L��I�了。另外一个思�\是构��Z��个基于内存映��的虚拟文�g�Q�这个框架在boost的iostreams库中�Q�有兴趣的朋友可以深入的研究�?br>�Q�完�Q?

lf426 2010-06-26 19:55 发表评论

��d��解密C++宽字�W�：5、利用fstream转换

lf426 — Sat, 26 Jun 2010 08:40:00 GMT

<本文PDF文档下蝲>

C++的流和本地化�{�略�?br>
BS在设计C++��的时候希望其具备��化，�q�且是可扩展的智能化�Q�也��是��_��C++的流可以“��L��”一些内宏V��比如：

std::cout << 123 << "ok" << std::endl;

�q�句代码中，std::cout是能判断�?23是int�?ok"是const char[3]。利用流的智能，甚至可以做一些基��c�d��的�{换，比如从int到string�Q�string到int�Q?br>

std::string str("123");
std::stringstream sstr(str);
int i;
sstr >> i;

int i = 123;
std::stringstream sstr;
sstr << i;
std::string str = sstr.str();

��管如此�Q�C++�q�不满��Q�C++甚至希望��能“明白”旉��Q�货币的表示法。而时间和货币的表�C�方法在世界范围内是不同的，所以，每一个流都有自己的locale在媄响其行�ؓ�Q�C++中叫做激�z�（imbue�Q�也有翻译成��染�Q�。而我们知道，每一个locale都有多个facet�Q�这些facet�q��L��被use_facet使用的。决定��用哪些facet的，是流的缓存basic_streambuf及其�z��c�basic_stringbuf和basic_filebuf。我们要用到的facet是codecvt�Q�这个facet只被basic_filebuf使用——这��是��Z��么只能用fstream来实现宽�H��{换，而无法��用sstream来实现的原因�?br>头文�Ӟ��

//filename string_wstring_fstream.hpp
#ifndef STRING_WSTRING_FSTREAM_HPP
#define STRING_WSTRING_FSTREAM_HPP

#include <string>

const std::wstring s2ws(const std::string& s);
const std::string ws2s(const std::wstring& s);

#endif

实现�Q?br>

#include <string>
#include <fstream>
#include "string_wstring_fstream.hpp"

const std::wstring s2ws(const std::string& s)
{
    std::locale sys_loc("");

    std::ofstream ofs("cvt_buf");
    ofs << s;
    ofs.close();

    std::wifstream wifs("cvt_buf");
    wifs.imbue(sys_loc);
    std::wstring wstr;
    wifs >> wstr;
    wifs.close();

    return wstr;
}

const std::string ws2s(const std::wstring& s)
{
    std::locale sys_loc("");

    std::wofstream wofs("cvt_buf");
    wofs.imbue(sys_loc);
    wofs << s;
    wofs.close();

    std::ifstream ifs("cvt_buf");
    std::string str;
    ifs >> str;
    ifs.close();

    return str;
}

在窄到宽的�{化中�Q�我们先使用默认的本地化�{�略集（locale�Q�将s通过�H�文件流ofs传入文�g�Q�这是char到char的传递，没有��M��转换�Q�然后我们打开宽文件流wifs�Q��ƈ用系�l�的本地化策略集�Q�locale�Q�去�Ȁ�z�（imbue�Q�之�Q�流在读回宽串wstr的时候，��是char到wchar_t的�{换，�q�且因�ؓ�Ȁ�z�M��sys_loc�Q�所以实现标准窄到宽的�{换�?br>在宽到窄的�{化中�Q�我们先打开的是宽文件流wofs�Q��ƈ且用�pȝ��的本地化�{�略集sys_loc�Ȁ�z�（imbue�Q�之�Q�这时候，因�ؓ要写的文件cvt_buf是一个外部编码，所以执行了从wchar_t到char的标准�{换。读回来的文件流从char到char�Q�不做�Q何�{换�?

lf426 2010-06-26 16:40 发表评论

��d��解密C++宽字�W�：4、利用codecvt和use_facet转换

lf426 — Sat, 26 Jun 2010 05:39:00 GMT

<本文PDF文档下蝲>

locale和facet

C++的locale框架比C更完备。C++除了一个笼�l�本地策略集locale�Q�还可以为locale指定具体的策略facet�Q�甚臛_��以用自己定义的facet��L��造一个现有的locale产生一个新的locale。如果有一个facet�c�NewFacet需要添加到某个old_loc中�Ş成新new_loc�Q�需要另外一个构造函敎ͼ�通常的做法是�Q?br>std::locale new_loc(old_loc, new NewFacet);
标准库里的标准facet都具有自��q��有的功能�Q�访问一个locale对象中特定的facet需要��用模板函数use_facet�Q?br>template const Facet& use_factet(const locale&);
换一�U�说法，use_facet把一个facet�c�d��例化成了对象�Q�由此就可以使用�q�个facet对象的成员函数�?br>
codecvt

codecvt��是一个标准facet。在C++的设计框枉��Q�这是一个通用的代码�{换模李쀔—也��是��_��q�不是仅仅�ؓ宽窄转换制定的�?br>templat class std::codecvt: public locale, public codecvt_base{...};
I表示内部�~�码�Q�E表示外部�~�码�Q�State是不同�{换方式的标识�Q�如果定义如下类型：
typedef std::codecvt CodecvtFacet;
那么CodecvtFacet��是一个标准的宽窄转换facet�Q�其中mbstate_t是标准宽�H��{换的State�?br>
内部�~�码和外部编�?br>
我们考虑�W?节中提到的C++�~�译器读取源文�g时候的情�Ş�Q�当��d��L"中文abc"的时候，外部�~�码�Q�也��是源文件的�~�码�Q�是GB2312或者UTF-8的char�Q�而编译器必须��其��译为UCS-2BE或者UTF-32BE的wchar_t�Q�这也就是程序的内部�~�码。如果不是宽字符�Ԍ��内外�~�码都是char�Q�也��׃��需要�{换了。类似的�Q�当C++��d��文�g的时�?�Q�就会可能需要到内外�~�码转换。事实上�Q�codecvt��正是被文�g��缓存basic_filebuf所使用的。理解这一点很重要�Q�原因会在下一��节看到�?br>
CodecvtFacet的in()和out()
因�ؓ在CodecvtFacet中，内部�~�码讄��为wchar_t�Q�外部编码设�|��ؓchar�Q��{换模式是标准宽窄转换mbstate_t�Q�所以，�c�L��法in()��是从char标准转换到wchar_t�Q�out()��是从wchar_t标准转换到char。这��成了我们正需要的内外转换函数�?br>result in(State& s, const E* from, const E* from_end, const E*& from_next, I* to, I* to_end, I*& to_next) const;
result out(State& s, const I* from, const I* from_end, const I*& from_next, E* to, E* to_end, E*& to_next) const;
其中�Q�s是非const引用�Q�保存着转换位移状态信息。这里需要重点强调的是，因�ؓ转换的实际工作交�l�了�q�行时库�Q�也��是��_��转换可能不是在程序的主进�E�中完成的，而�{换工作依赖于查询s的��|��因此�Q�如果s在�{换结束前析构�Q�就可能抛出�q�行时异常。所以，最安全的办法是�Q�将s讄��为全局变量�Q?br>const�?个指针分别是待�{换字�W�串的�v点，�l�点�Q�和出现错误时候的停点�Q�的下一个位�|�）�Q�另�?个指针是转换目标字符串的��L��Q�终点以及出现错误时候的停点�Q�的下一个位�|�）�?br>
代码如下�Q?br>头文�?br>

//Filename string_wstring_cppcvt.hpp

#ifndef STRING_WSTRING_CPPCVT_HPP
#define STRING_WSTRING_CPPCVT_HPP

#include <iostream>
#include <string>

const std::wstring s2ws(const std::string& s);
const std::string ws2s(const std::wstring& s);

#endif

实现�Q?br>

#include "string_wstring_cppcvt.hpp"

mbstate_t in_cvt_state;
mbstate_t out_cvt_state;

const std::wstring s2ws(const std::string& s)
{
    std::locale sys_loc("");

    const char* src_str = s.c_str();
    const size_t BUFFER_SIZE = s.size() + 1;

    wchar_t* intern_buffer = new wchar_t[BUFFER_SIZE];
    wmemset(intern_buffer, 0, BUFFER_SIZE);

    const char* extern_from = src_str;
    const char* extern_from_end = extern_from + s.size();
    const char* extern_from_next = 0;
    wchar_t* intern_to = intern_buffer;
    wchar_t* intern_to_end = intern_to + BUFFER_SIZE;
    wchar_t* intern_to_next = 0;

    typedef std::codecvt<wchar_t, char, mbstate_t> CodecvtFacet;

    CodecvtFacet::result cvt_rst =
        std::use_facet<CodecvtFacet>(sys_loc).in(
            in_cvt_state,
            extern_from, extern_from_end, extern_from_next,
            intern_to, intern_to_end, intern_to_next);
    if (cvt_rst != CodecvtFacet::ok) {
        switch(cvt_rst) {
            case CodecvtFacet::partial:
                std::cerr << "partial";
                break;
            case CodecvtFacet::error:
                std::cerr << "error";
                break;
            case CodecvtFacet::noconv:
                std::cerr << "noconv";
                break;
            default:
                std::cerr << "unknown";
        }
        std::cerr    << ", please check in_cvt_state."
                    << std::endl;
    }
    std::wstring result = intern_buffer;

    delete []intern_buffer;

    return result;
}

const std::string ws2s(const std::wstring& ws)
{
    std::locale sys_loc("");

    const wchar_t* src_wstr = ws.c_str();
    const size_t MAX_UNICODE_BYTES = 4;
    const size_t BUFFER_SIZE =
                ws.size() * MAX_UNICODE_BYTES + 1;

    char* extern_buffer = new char[BUFFER_SIZE];
    memset(extern_buffer, 0, BUFFER_SIZE);

    const wchar_t* intern_from = src_wstr;
    const wchar_t* intern_from_end = intern_from + ws.size();
    const wchar_t* intern_from_next = 0;
    char* extern_to = extern_buffer;
    char* extern_to_end = extern_to + BUFFER_SIZE;
    char* extern_to_next = 0;

    typedef std::codecvt<wchar_t, char, mbstate_t> CodecvtFacet;

    CodecvtFacet::result cvt_rst =
        std::use_facet<CodecvtFacet>(sys_loc).out(
            out_cvt_state,
            intern_from, intern_from_end, intern_from_next,
            extern_to, extern_to_end, extern_to_next);
    if (cvt_rst != CodecvtFacet::ok) {
        switch(cvt_rst) {
            case CodecvtFacet::partial:
                std::cerr << "partial";
                break;
            case CodecvtFacet::error:
                std::cerr << "error";
                break;
            case CodecvtFacet::noconv:
                std::cerr << "noconv";
                break;
            default:
                std::cerr << "unknown";
        }
        std::cerr    << ", please check out_cvt_state."
                    << std::endl;
    }
    std::string result = extern_buffer;

    delete []extern_buffer;

    return result;
}

最后补充说明一下std::use_facet(sys_loc).in()和std::use_facet(sys_loc).out()。sys_loc是系�l�的locale�Q�这个locale中就包含着特定的codecvt facet�Q�我们已�l�typedef��Z��CodecvtFacet。用use_facet对CodecvtFacet�q�行了实例化�Q�所以可以��用这个facet的方法in()和out()�?

lf426 2010-06-26 13:39 发表评论

��d��解密C++宽字�W�：3、利用C�q�行时库函数转换

lf426 — Sat, 26 Jun 2010 03:17:00 GMT

<本文PDF文档下蝲>

std::locale

通过前面两节的知识，我们知道了在C/C++中，字符�Q�串�Q�和宽字�W�（�Ԍ��之间的�{换不是简单的�Q�固定的数学关系�Q�宽�H��{换依赖于本地化策略集�Q�locale�Q�。换句话��_��一个程序在�q�行之前�q�不知道�pȝ��的本地化�{�略集是什么，�E�序只有在运行之后才通过locale获得当时的本地化�{�略集�?br>C有自��q��locale函数�Q�我们这里直接介�l�C++的locale�c�R�?br>先讨论locale的构造函敎ͼ�
locale() throw();
�q�个构造函数是获得当前�E�序的locale�Q�用法如下：
std::locale app_loc = std::locale();
或者（�q�是构造对象的两种表示方式�Q�后同）
std::locale app_loc;
另外一个构造函数是�Q?br>explicit locale(const char* name);
�q�个构造函��C��name的名字创建新的locale。重要的locale对象有：
std::locale sys_loc("");      //获得当前�pȝ��环境的locale
std::locale C_loc("C");      或�?nbsp;     std::locale C_loc = std::locale::classic();      //获得C定义locale
std::locale old_loc = std::locale::global(new_loc);      //��new_loc讄��为当前全局locale�Q��ƈ��原来的locale�q�回�l�old_loc
除了�q�些�Q�其它的name具体名字依赖于C++�~�译器和操作�pȝ��Q�比如Linux下gcc中文�pȝ��的locale名字�?zh_CN.UTF-8"�Q�中文Windows可以�?chs"�Q�更加完整的名字可以用name()函数查看�Q��?br>
mbstowcs()和wcstombs()

�q�两个C�q�行时库函数依赖于全局locale�q�行转换�Q�所以，使用前必��d��讄��全局locale�?br>std::locale已经包含�?lt;iostream>中了�Q�再加上我们需要用到的C++字符�Ԍ��所以包�?lt;string>�?br>我们先看�H�到宽的转换函数�Q?br>

const std::wstring s2ws(const std::string& s)
{
    std::locale old_loc =
        std::locale::global(std::locale(""));

    const char* src_str = s.c_str();
    const size_t buffer_size = s.size() + 1;
    wchar_t* dst_wstr = new wchar_t[buffer_size];
    wmemset(dst_wstr, 0, buffer_size);
    mbstowcs(dst_wstr, src_str, buffer_size);
    std::wstring result = dst_wstr;
    delete []dst_wstr;

    std::locale::global(old_loc);

    return result;
}

我们��全局locale讄��为系�l�locale�Q��ƈ保存原来的全局locale在old_loc中�?br>在制定�{换空间缓存大��的时候，考虑如下�Q�char是用1个或多个对象�Q�也��是1个或者多个字节来表示各种�W�号�Q�比如，GB2312�?个字节表�C�数字和字母�Q?个字节表�C�汉字；UTF-8用一个字节表�C�数字和字母�Q?个字节表�C�汉字，4个字节表�C�Z��些很��用到的�W�号�Q�比如音乐中G大调�W�号�{�。wchar_t是用1个对象（2字节或�?字节�Q�来表示各种�W�号。因此，表示同样的字�W�串�Q�宽字符串的大小�Q�也��是wchar_t对象的数量）��L��于或者等于窄字符串大��（char对象数量�Q�的�?1是�ؓ了在最后预留一个��gؓ0的对象，以便让C风格的char或者wchar_t字符串自动截断——这当然是宽串大��等于窄串大��的时候才会用上的�Q�大部分时候，字符串早在前面某个�{换完毕的位置��p��0值对象所截断了�?br>最后我们将全局locale讄��回原来的old_loc�?br>�H�串到宽串的转换函数�Q?br>

const std::string ws2s(const std::wstring& ws)
{
    std::locale old_loc =
        std::locale::global(std::locale(""));

    const wchar_t* src_wstr = ws.c_str();
    size_t buffer_size = ws.size() * 4 + 1;
    char* dst_str = new char[buffer_size];
    memset(dst_str, 0, buffer_size);
    wcstombs(dst_str ,src_wstr, buffer_size);
    std::string result = dst_str;
    delete []dst_str;

    std::locale::global(old_loc);

    return result;
}

�q�里考虑转换�I�间�~�存大小的策略正好相反，在最极端的情况下�Q�所有的wchar_t都需�?个char来表�C�，所以最大的可能��是4倍加1�?br>�q�两个函数在VC和gcc中都能正常运行（MinGW因�ؓ前面说到的原因不支持宽字�W�的正常使用�Q�，在VC中会�l�出不安全的警告�Q�这是告诉给那些弄不清宽�H��{换实质的人的警告�Q�对于了解到目前�q�些知识的你我来��_��q�就是啰嗦了�?

lf426 2010-06-26 11:17 发表评论

��d��解密C++宽字�W�：2、Unicode和UTF

lf426 — Fri, 25 Jun 2010 13:51:00 GMT

<本文PDF文档下蝲>

Unicode和UCS

Unicode和UCS是两个独立的�l�织分别制定的一套编码标准，但是因�ؓ历史的原因，�q�两套标准是完全一��L��。Unicode�q�个词用得比较多的原因可能是因�ؓ比较�Ҏ��C��Q�如果没有特别的声明�Q�在本文所提及的Unicode和UCS��是一个意思。Unicode的目标是建立一套可以包含�h�c�L��有语�a�文字�W�号你想得到想不到的各种东西的编码，其编码容量甚至预留了火星语以及银河系以外语言的空间——开个玩�W�，反正��单的��_��Unicode�~�码集��够的大，如果用计��机单位来表�C�，其数量比3个字节大一些，不到4个字节�?br>
Unicode和UTF

因�ؓUnicode包含的内容太多，其编码在计算��Z��的表�C�方法就成�ؓ了一个有必要研究的问题。传�l�编码，比如标准�?位ASCII�Q�在计算��Z��的表�C�方法就是占一个字节的�?位，�q�似乎是不需要解释就�W�合大家习惯的表�C�方法。但是当今Unicode的��L��辑ֈ�32位（计算机的最��单位是字节�Q�所以大�?字节�Q�就只能臛_��?字节表示�Q�，对于大部分常用字�W�，比如Unicode�~�码只占一个字节大��的��p��字母�Q�占两个字节大小汉字�Q�都�?个字节来储存太奢侈了。另外，如果都用4字节直接表示�Q�就不可避免的出��Cؓ0的字节。而我们知道，在C语言中，0x00的字节就�?\0'�Q�表�C�的是一个字�W�串�Q�char字符�Ԍ��非wchar_t�Q�的�l�束�Q�换句话��_��C风格的char字符串无法表�C�Unicode�?br>因�ؓ�c�M��的种�U�问题，为Unicode在计��机中的�~�码�Ҏ��出现了，�q�就是UTF�Q�所对应的，为UCS�~�码实现的方式也有自��q��说法。一般来��_��UTF-x�Q�x表示�q�套�~�码一个单位至��占用x位，因�ؓUnicode最长达�?2位，所以UTF-x通常是变长的——除了UTF-32�Q�而UCS-y表示一个单位就占用y个字节，所以能表示当今Unicode的UCS-y只有UCS-4�Q�但是因为历史的原因�Q�当Unicode�q�没那么庞大的时候，2个字节��够表�C�，所以有UCS-2�Q�现在看来，UCS-2所能表�C�的Unicode只是当今Unicode的一个子集�?br>也就是说�Q�如果某�U�编码，能根据一定的规则��法�Q�得到Unicode�~�码�Q�那么这�U�编码方式就可以�U�C��为UTF�?br>
UTF-8和Windows GB2312

UTF-8是一�?#8220;聪明”的编码，可能�?�Q?�Q?�Q?个字节表�C�。通过UTF-8的算法，每一个字节表�C�的信息都很明确�Q�这是不是某个Unicode�~�码的第一个字节；如果是第一个字节，�q�是一个几位Unicode�~�码。这�U?#8220;聪明”被称为UTF-8的自我同步，也是UTF-8成�ؓ�|�络传输标准�~�码的原因�?br>另外�Q�UTF-8也不会出�?字节�Q�所以可以表�C�Zؓchar字符�Ԍ��所以可以成为系�l�的�~�码。Linux�pȝ��默认使用UTF-8�~�码�?br>Windows GB2312一般自�U�CؓGB2312�Q�其实真正的名字应该是Windows Codepage 936�Q�这也是一�U�变长的�~�码�Q?个字节表�C�Z��l�的ASCII部分�Q�汉字部分是两个字节的GBK�Q�国标扩�Q�展�Q�，拼音声母�Q�。Codepage 936也可以表�C�Zؓchar字符�Ԍ��是中文Windows�pȝ��的默认编码�?br>我们在第1节中看到�?br>const char* s = "中文abc";
在Windows中的�~�码��是Codepage 936�Q�在Linux中的�~�码��是UTF-8�?br>需要注意的是，Codepage 936不像UTF�Q�跟Unicode没有换算的关�p�，所以只能通过“代码��?#8221;技术查表对应�?br>
UTF-16和UCS-2

UTF-16�?个字节或�?个字节表�C�。在2个字节大��的时候，跟UCS-2是一��L��。UTF-16不像UTF-8�Q�没有自我同步机�Ӟ��所以，�~�码大位在前�q�是��位在前�Q�就成了见仁见智的问题。我们在�W?节中�Q?#8220;�?#8221;的UCS-2BE�Q�因为是两个字节�Q�所以也��是UTF-16BE�Q�编码是0x4E2D�Q�这里的BE��是大位在后的意思（也就是小位在前了�Q�，对应的，如果是UCS-2LE�Q�编码就成了0x2D4E�?br>Windows中的wchar_t��是采用UCS-2BE�~�码。需要指出的是，C++标准中对wchar_t的要求是要能表示所有系�l�能识别的字�W�。Windows自称支持Unicode�Q�但是其wchar_t却不能表�C�所有的Unicode�Q�由此违背了C++标准�?br>
UTF-32和UCS-4

UTF-32在目前阶�D늭�价于UCS-4�Q�都用定长的4个字节表�C�。UTF-32同样存在BE和LE的问题。Linux的wchar_t�~�码��是UTF-32BE。在16位以内的时候，UTF-32BE的后两位�Q�前两位�?x00 0x00�Q�等价于UTF-16BE也就�{��h于UCS-2BE

BOM

��Z��说明一个文仉��用的是什么编码，在文件最开始的部分�Q�可以有BOM�Q�比�?xFE 0xFF表示UTF-16BE�Q?xFF 0xFE 0x00 0x00表示UTF-32LE。UTF-8原本是不需要BOM的，因�ؓ其自我同步的�Ҏ��，但是��Z��明确说明�q�是UTF-8�Q�而不是让文本�~�辑器去猜）�Q�也可以加上UTF-8的BOM�Q?xEF 0xBB 0xBF

以上内容都讲�q�得很概略，详细信息��h��阅维基百�U�相兛_��宏V�?

lf426 2010-06-25 21:51 发表评论

��d��解密C++宽字�W�：1、从char到wchar_t

lf426 — Fri, 25 Jun 2010 06:41:00 GMT

<本文PDF文档下蝲>

“�q�个问题比你惌��中复�?#8221;
�Q�我也学下BS的风��|��虽然�q�句话是我自�׃��时想说的。^^�Q?br>
从字�W�到整数

char是一�U�整数类型，�q�句话的含义是，char所能表�C�的字符在C/C++中都是整数类型。好�Q�接下来�Q�很多文章就会�D��Z��个典型例子，比如�Q?a'的数值就�?x61。这�U�说法对吗？如果你细心的读过K&R和BS对于C和C++描述的原著，你就会马上反驳道�Q?x61只是'a'的ASCII��|��q�没有�Q何规定C/C++的char值必��d��应ASCII。C/C++甚至没有规定char占几位，只是规定了sizeof(char)�{�于1�?br>当然�Q�目前大部分情况下，char�?位的�Q��ƈ且，在ASCII范围内的��|��与ASCII对应�?br>
本地化策略集�Q�locale�Q?br>
“��?a'��译�?x61的整数�?#8221;�Q?#8220;��ASCII范围内的�~�码与char的整数值对应�v�?#8221;�Q�类��D��L��规定�Q�是特定�pȝ��和特定编译器制定的，C/C++中有个特定的名词来描�q�这�U�规定的集合�Q�本地化�{�略集（locale。也有翻译成“现场”�Q�。而翻译——也��是代码转换�Q�codecvt�Q�只是这个集合中的一个，C++中定义�ؓ�{�略�Q�facet。也有翻译�ؓ“刻面”�Q?br>
C/C++的编译策�?br>
“本地化策略集”是个很好的概念，可惜在字�W�和字符串这个层面上�Q�C/C++�q�不使用�Q�C++的locale通常只是影响��（stream�Q�）�Q�C/C++使用更直接简单的�{�略�Q�硬�~�码�?br>��单的��_��字符�Q�串�Q�在�E�序文�g�Q�可执行文�g�Q�非源文�Ӟ��中的表示�Q�与在程序执行中在内存中的表�C�Z��致。考虑两种情况�Q?br>A、char c = 0x61;
B、char c = 'a';
情况A下，�~�译器可以直接认识作为整数的c�Q�但是在情况B下，�~�译器必��d��'a'��译成整数。编译器的策略也很简单，��是直接��d��字符�Q�串�Q�在源文件中的编码数倹{��比如：
const char* s = "中文abc";
�q�段字符串在GB2312�Q�Windows 936�Q�，也就是我们的windows默认中文�pȝ��源文件中的编码�ؓ�Q?br>0xD6   0xD0   0xCE 0xC4 0x61 0x62 0x63
在UTF-8�Q�也��是Linux默认�pȝ��源文件中的编码�ؓ�Q?br>0xE4   0xB8   0xAD   0xE6   0x96   0x87   0x61   0x62   0x63
一般情况下�Q�编译器会忠实于源文件的�~�码为s赋��|��例外的情冉|��如VC会自作聪明的把大部分其他�c�d��~�码的字�W�串转换成GB2312�Q�除了像UTF-8 without signature�q�样的幸存者）�?br>�E�序在执行的时候，s也就保持是这��L��~�码�Q�不会再做其他的转换�?br>
宽字�W?wchar_t
正如char没有规定大小�Q�wchar_t同样没有标准限定�Q�标准只是要求一个wchar_t可以表示��M��pȝ��所能认识的字符�Q�在win32中，wchar_t�?6位；Linux中是32位。wchar_t同样没有规定�~�码�Q�因为Unicode的概忉|��们后面才解释�Q�所以这里只是提一下，在win32中，wchar_t的编码是UCS-2BE�Q�而Linux中是UTF-32BE�Q�等价于UCS-4BE�Q�，不过��单的��_��?6位以内，一个字�W�的�q?�U�编码值是一��L��。因此：
const wchar_t* ws = L"中文abc";
的编码分别�ؓ�Q?br>0x4E2D   0x6587    0x0061   0x0062   0x0063                                                //win32�Q?6�?br>0x00004E2D   0x00006587    0x00000061   0x00000062   0x00000063        //Linux�Q?2�?br>大写的L是告诉编译器�Q�这是宽字符丌Ӏ�所以，�q�时候是需要编译器�Ҏ��locale来进行翻译的�?br>比如�Q�在Windows环境中，�~�译器的��译�{�略是GB2312到UCS-2BE�Q�Linux环境中的�{�略是UTF-8到UTF-32BE�?br>�q�时候就要求源文件的�~�码与编译器的本地化�{�略集中代码��译的策略一��_��例如VC只能��d��GB2312的源代码�Q�这里还是例外，VC太自作聪明了 �Q�会��很多其他代码在�~�译时自动�{换成GB2312�Q�，而gcc只能��d��UTF-8的源代码�Q�这里就有个��尬�Q�MinGW�q�行win32下，所以只有GB2312�pȝ��才认�Q�而MinGW却用gcc�~�写�Q�所以自己只认UTF-8�Q�所以结果就是，MinGW的宽字符被废掉了�Q��?br>宽字�W�（�Ԍ��q��译器��译�Q�还是被��编码进�E�序文�g中�?

lf426 2010-06-25 14:41 发表评论

socket �~�程入门教程�Q�六�Q�UDP应用�Q?、UDP版的Echo Client

lf426 — Sat, 12 Jun 2010 04:11:00 GMT

同样的，我们��UDP版的doEcho()也设计成�q�回bool�Q�true表示循环�l�箋�Q�false表示关闭客户端�?/p>

class UDPEchoClient: public UDPClientSock{
public:
    explicit UDPEchoClient(
                int pre_buffer_size = 32);
    ~UDPEchoClient();
    bool doEcho(const std::string& echo_message);
};

我们依然使用C++字符丌Ӏ?br>

UDPEchoClient::UDPEchoClient(
                int pre_buffer_size):
UDPClientSock(pre_buffer_size)
{}

UDPEchoClient::~UDPEchoClient()
{}

bool UDPEchoClient::doEcho(const std::string& echo_message)
{
    if ( UDPSendtoDest(echo_message.data(), echo_message.size()) < 0) {
        return false;
    }
    if (echo_message == "/shutdown") {
        return false;
    }
    if (UDPReceive() < 0) {
        return false;
    }
    std::cout.write(preBuffer, preReceivedLength);
    std::cout << std::endl;
    return true;
}

当echo_message�?#8220;�I?#8221;的时候，卌��入直接回车，是一�?"�Q�用C风格来说�Q�即�?\0'�Q�从C++来说�Q�是const char[1]�Q�其C++风格的长度echo_message.size()�?�Q�这时候就会发送一�?#8220;0长度”的UDP数据包�?br>另外�Q�我们小心设计了关闭服务器的��h��Q�发�?shutdown后，客户端会自动�q�回false�Q�表�C�Z��关闭�Q�不再等待来自服务器的recvfrom()。否则，服务器已�l�关闭，recvfrom()则会一直阻塞�?br>

int main(int argc, char* argv[])
{
    unsigned short server_port = 5000;
    if (argc == 3 && atoi(argv[2]) > 0) {
        server_port = atoi(argv[2]);
    }

    WinsockAPI winsockInfo;
    winsockInfo.showVersion();

    UDPEchoClient echo_client;
    echo_client.UDPSetDest(argv[1], server_port);

    std::string msg;
    bool go_on = true;
    while (msg != "/exit" && go_on){
        std::cout << "Echo: ";
        std::getline(std::cin, msg);
        go_on = echo_client.doEcho(msg);
    }

    return 0;
}

�ȝ��序中�Q�如果��?exit�Q�会先发送给服务器，然后再关闭�?br>本章完整源代码：
Linux�Q?br>http://www.163pan.com/files/c0l000h0t.html
win32�Q?br>http://www.163pan.com/files/c0o000h09.html

lf426 2010-06-12 12:11 发表评论

socket �~�程入门教程�Q�六�Q�UDP应用�Q?、UDP版的Echo Server

lf426 — Sat, 12 Jun 2010 03:16:00 GMT

与TCP版的Echo Server�c�M��Q�我们从Server Socket�c�M��z��出Echo Server�c�R�?br>

class UDPEchoServer: public UDPServerSock{
public:
    explicit UDPEchoServer(
                unsigned short server_port,
                int pre_buffer_size = 32);
    ~UDPEchoServer();
    bool handEcho();
};

我们依然让handEcho()�q�回一个bool�Q�true表示客户�?#8220;正常”��d��Q�这里没�?#8220;断开”�q�个词是因�ؓUDP是无�q�接的；另外�Q�我们这里用recvfrom()�q�回��于0来表�C�客��L��其实�?#8220;非正�?#8221;的离开了，比如�q�接被重�|�。事实上�Q�作为UDP服务器，�Ҏ��不关心客��L��是在�q�还是已�l�离开�Q�，false表示客户端发出指令要求服务器端关闭�?br>

UDPEchoServer::UDPEchoServer(
                unsigned short server_port,
                int pre_buffer_size):
UDPServerSock(server_port, pre_buffer_size)
{}

UDPEchoServer::~UDPEchoServer()
{}

bool UDPEchoServer::handEcho()
{
    const std::string SHUTDOWN_CMD = "/shutdown";
    while (UDPReceive() >= 0) {
        std::string cmd(preBuffer, SHUTDOWN_CMD.size());
        if (cmd == SHUTDOWN_CMD &&
            preReceivedLength == static_cast<int>(SHUTDOWN_CMD.size())) {
            return false;
        }
        std::cout    << "Client ( "
                    << inet_ntoa(lastfromSockAddr.sin_addr)
                    << " : "
                    << ntohs(lastfromSockAddr.sin_port)
                    << " ) sent a message."
                    << std::endl;
        UDPSetDest(lastfromSockAddr);
        UDPSendtoDest(preBuffer, preReceivedLength);
    }
    return true;
}

�q�里跟TCP有些�l�微的差别。在TCP中，recv()�q�回0表示�q�接正常断开�Q�而UDP中没有连接和断开的概念，recv()或者recvfrom()�q�回0表示收到一�?字节大小数据的数据报。另外，因�ؓTCP是一对一�q�接的，所以一旦连接上�Q�TCP服务器只能处理来自一个客��L��的echo��h��Q�后面会讲到多线�E�的使用�Q�就可以让TCP同时处理多个客户端了�Q�；而UDP服务器则可以处理来自��M��客户端的echo��h��Q��ؓ了返回信息到正确的客��L��Q�我们的�{�略是，接收一个UDP数据包后�Q�马上刷新发送目标地址��Z��一�ơ接收地址�Q�然后再回发数据�Q�所以这里每�ơ多了一个重新指定发送目的地的函数�?br>最后，�ȝ��序基本不需要改变：

int main(int argc, char* argv[])
{
    const unsigned short DEFAULT_PORT = 5000;
    unsigned short server_port = DEFAULT_PORT;
    if (argc == 2 && atoi(argv[1]) > 0) {
        server_port = atoi(argv[1]);
    }

    UDPEchoServer echo_server(server_port);

    bool go_on = true;
    while (go_on){
        go_on = echo_server.handEcho();
    }

    return 0;
}

本章完整源代码下载：
Linux�Q?br>http://www.163pan.com/files/c0l000h0s.html
win32�Q?br>http://www.163pan.com/files/c0o000h08.html

lf426 2010-06-12 11:16 发表评论

socket �~�程入门教程�Q�五�Q�UDP原理�Q?、预读MSG_PEEK

lf426 — Fri, 11 Jun 2010 05:30:00 GMT

recv()和recvfrom()的第4个参数可以调整函数行为�?br>

#include <sys/types.h>
#include <sys/socket.h>
ssize_t recv(int s, void *buf, size_t len, int flags);
ssize_t recvfrom(int s, void *buf, size_t len, int flags,
struct sockaddr *from, socklen_t *fromlen);

因�ؓUDP是按数据包接收的�Q�我们在接收之前�q�不知道�q�个数据包有多大。一个策略是�Q�我们准备��够大的应用程序缓存以免出错，但是�q�个“��_��?#8221;的概忉|��建立在我们对传送的数据事先有了解的情况下，比如是我们自��p��计服务器端和客户端�ƈ且制定应用层协议�Q�另外一�U�策略是�Q�将一个数据包的相关信息记录在数据包的前面的一些字节中�Q�比如说大小�Q�这��P��我们可以通过预读数据包的前面一�D�，得到�q�个数据包的相关信息�Q�比如说大小�Q�然后再安排�~�存�?br>�q�个预读的flag��是MSG_PEEK。��用预��d��Q�RecvQ的下一条UDP数据包信息被��d��来，但是�q�不从RecvQ中弹出�?br>UDP也可以通过recvfrom()预读获得来向的远�E�地址�Q�从而可以提供给比如connect()�{�函��C��用�?br>需要说明的是，在Linux下（我是Debian�pȝ��Q�从一个n字节的UDP数据包中预读取小于n个字节的数据是完全没有问题的�Q�但是在WinSock下会引�v一个异�?0040�Q�WSAEMSGSIZE�Q�，��x��说win32下recv()或者recvfrom()在这�U�情况下会返�?1。其异常信息大概是读取的数据长度��于数据包的长度——而这个正是我们计划中的事情�?

lf426 2010-06-11 13:30 发表评论