5. C++源文件编码的选择
　　5.1. 几种可行做法
　　根据上面的讨论，目前看来，要兼容Windows/Linux，VC/gcc的话，有几种做法：
　　使用窄字符，源程序中只使用ascii字符，非ascii字符，如中文等通过gettext等工具放到单独的语言包中。
　　这种做法比较多人推荐。
　　兼容VC及gcc各版本。
　　由于源程序中不出现非ascii字符，因此不需要考虑源程序文件的编码问题。
　　兼容各种编码的运行环境。
　　使用窄字符，源程序中允许使用非ascii字符。
　　要求运行环境的编码与程序内码一致，即只支持GB18030编码的Windows及UTF-8编码的Linux。
　　根据源程序使用的编码不同，对编译器的兼容性也不同：
　　使用窄字符，源程序使用带BOM的UTF-8编码。
　　兼容VC各语种的各版本。
　　兼容gcc 4.4.0以上版本。
　　使用窄字符，源程序使用GB18030编码。
　　兼容VC的简体中文各版本。
　　兼容gcc各版本，但在编译时需要加上-finput-char=gb18030参数。
　　使用宽字符，源程序中允许使用非ascii字符。
　　兼容各种编码的运行环境。
　　根据源程序使用的编码不同，对编译器的兼容性也不同：
　　使用窄字符，源程序使用带BOM的UTF-8编码。
　　兼容VC各语种的各版本。
　　兼容gcc 4.4.0以上版本。
　　使用窄字符，源程序使用GB18030编码。
　　兼容VC的简体中文各版本。
　　兼容gcc各版本，但在编译时需要加上-finput-char=gb18030参数。
　　5.2. 推荐做法
　　根据我们的现状，对于需要支持多语种的程序，建议使用窄字符，源程序中只使用ascii字符。
　　对于不需要支持多语种的程序，考虑到重用已有的代码，可以考虑使用窄字符，采用GB18030编码，但只能运行在GB18030编码的Windows环境及UTF-8编码的
　　Linux环境下。
　　6. 其它问题
　　6.1. 用户输入、输出及持久化
　　由于用户输入、输出及从文件、网络等设施读写的数据在程序底层看来都是字节流，因此存在在输入时如何把这些字节流解释成有效的信息，在输出时怎么把程序中的信息转换为正确的字节流的问题。
　　如果程序本身不需要处理这些数据，只是把数据从一个来源搬到另一个地方（如把用户输入保存到文件，或者从一个流读入，写到另一个流等），而输入的字符编码与输出的字符编码一致的话，程序不需要对数据进行任何编码转换，只需要把读入的数据按原样写到输出即可，数据的字符编码与程序的编码没有关系。
　　比如网站应用程序，只需要保证用户页面使用UTF-8编码，数据库、数据文件也都使用UTF-8编码，那么用户输入的数据可以直接写入数据库及数据文件，从数据库或数据文件中读取的数据也可以直接展现给用户，不需要进行编码转换。
　　如果程序需要在一定程序上对数据进行处理（如需要判断字符个数、对字符进行比较、在字符串上附加或去掉内容），要把数据转换为一种明确的字符编码，一般来说是程序内码，再进行处理，在处理后再转换为所需的字符编码进行输出。
　　对于宽字符程序，如果只需要处理采用当前运行环境字符编码的数据，可以通过ios::imbue()可以指定io流的字符编码，在输入、输出时C++标准库会自动在所指定的字符编码与程序内码之间进行编码转换。如果不使用流的话，也可以通过标准的wcstombs()或mbstowcs()函数进行当前编码（通过locale::global()或setlocale()指定）与宽字符之间的转换。
　　对于窄字符程序，如果数据的字符编码与程序内码一致也不需要进行编码转换，直接处理即可。
　　对于其它情形，需要引入iconv或类似的字符编码转换库，以便实现不同
　　字符编码之间的转换。
　　6.2. gettext、iconv的替代品
　　由于gettext及iconv都属于GNU Project，考虑到版权因素，并非所有程序，特别是商业程序，都适合使用这些库。在Boost 1.48.0中，Boost.Locale库首次正式发布，该库提供了gettext、iconv的功能，并在此基础上进行了增强，提供了大小写变换、字符顺序比较、时间的处理 、分词、数字的格式化输入/输出、消息格式化、多语种支持、字符编码转换等功能，值得进一步研究及使用。