我应该如何正确使用g ++的-finput-charset编译器选项来编译非UTF-8源文件？

Question

我正在尝试使用-finput-charset编译器选项在g ++中编译UTF-16BE C++源文件,但我总是遇到一堆错误.更多细节如下.

我的环境(在CentOS Linux中):

• g ++:4.1.2
• iconv:2.5
• Linux语言(在终端中):LANG ="en_US.UTF-8"

我的示例源文件(以UTF-16BE编码存储):

// main.cpp:

#include <iostream>

int main()
{
    std::cout << "Hello, UTF-16" << std::endl;
    return 0;
}

我的步骤:

• 我阅读了关于-finput-charset选项的g ++手册. g ++手册说:

-finput-charset = charset 设置输入字符集,用于从输入文件的字符集转换为GCC使用的源字符集.如果区域设置未指定,或GCC无法从区域设置获取此信息,则默认值为UTF-8.这可以通过语言环境或此命令行选项覆盖.目前,如果存在冲突,命令行选项优先.charset可以是系统的" iconv "库例程支持的任何编码.

• 因此我按如下方式输入命令:

g ++ -finput-charset = UTF-16BE main.cpp

我收到了这些错误:

在main.cpp中包含的文件中:1:

/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:error:stray'\ 342'in program

/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:error:stray'\ 274'in program

...(反复,很多,大约4000 +)......

/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:错误:stray'\ 257'在程序中

main.cpp:在函数'int main()'中:

main.cpp:5:错误:'cout'不是'std'的成员

main.cpp:5:错误:'endl'不是'std'的成员

• 手册文本表明charset可以是'iconv'例程支持的任何编码,因此我猜测编译错误可能是由我的iconv库引起的.然后我测试了iconv:

iconv --from-code = UTF-16BE --to-code = UTF-8 --output = main_utf8.cpp main.cpp

按预期生成"main_utf8.cpp"文件.然后我尝试编译它:

g ++ -finput-charset = UTF-8 main_utf8.cpp

请注意,我明确指定了输入字符集以查看是否有任何错误,但这次生成的"a.out"没有任何错误.当我运行它时,它可以产生正确的输出.

最后...

我无法弄清楚我做错了什么.我在网上搜索试图找到这个编译器选项的一些例子,但我不能.

请指教!谢谢!

进一步编辑:

多谢你们!你的回复很快!一些更新:

1. 当我说"UTF-16"时我的意思是"UTF-16 + BOM".事实上我使用的是UTF-16BE.我已经更新了上面的文字.
2. 一些答案说错误是由非UTF-16头文件引起的.如果是这种情况,我的想法是这样的:在编写C/C++项目时,我们总是会包含一些标准的头文件,对吧？比如stdio.h或iostream.如果G ++编译器只处理我们创建的源文件的编码,但从不处理标准库中的源文件,那么这个-finput-charset选项是什么？

最终编辑:

最后,我的解决方案是这样的:

1. 最初,我将源文件的编码更改为GB2312,正如"Lister先生"所述.这个工作正常一段时间,但后来我发现它不适合我的情况,因为系统中的大多数其他部分仍然使用UTF-8进行通信和接口,因此我必须在很多地方转换编码......不仅如此我工作的开销,也可能导致我的程序性能下降.
2. 后来我试图将我的所有源文件转换为UTF-8 + BOM.通过这种方式,Windows中的Visual Studio可以快乐地编译它们,但Linux中的GCC会抱怨.然后我编写了一个shell脚本来删除BOM,在我想用GCC编译代码之前,我先运行这个脚本.
3. 幸运的是,我不必手动在Linux中构建代码,因为TeamCity在我的项目中使用了持续集成工具来自动生成构建.我可以更改TeamCity中的构建步骤,以帮助我在每日构建开始之前运行此脚本.
4. 使用这种UTF-8 + BOM +脚本方法,我决定不在Linux中编辑我的源代码,因为如果我想这样做,我必须确保我的代码可以在我提交之前成功构建,这意味着我必须运行在构建代码之前删除BOM的脚本,这意味着SVN会报告每个文件都被修改(BOM已删除),因此很容易错误地提交错误的文件.为了解决这个问题,我编写了另一个shell脚本来将BOM添加回源文件.虽然我仍然不经常在Linux中编辑我的代码,但是当我真的需要时,我不必面对提交对话框中非常长的更改列表.

Answer 1

编码蓝调

您不能将UTF-16用于源代码文件; 因为您所包含的标题<iostream>不是UTF-16编码的.由于#include逐字包含文件,这意味着您突然有一个UTF-16编码的文件,其中包含大块(显然大约4k)的无效数据.

几乎没有任何理由可以使用UTF-16进行任何操作,所以这也是一样的.

编辑:关于编码支持的问题:操作系统本身不负责提供编码支持,这归结为使用的编译器.

Windows上的g ++完全支持与Linux上的g ++相同的所有编码,因为它是相同的程序,除非您在Windows上使用的任何g ++版本依赖于深度破解的iconv库.

检查您的工具链并确保所有工具都处于正常工作状态.

作为备选; 不要在源文件中使用中文,而是使用英文文字或简单文字,在运行的可执行文件中TOKEN_STYLE_PLACEHOLDER使用l10n和i18n替换它们.

Threedit: -finput-charset几乎可以肯定是从代码页和其他类似的废话时代的延续; 然而; ISO-8859-n文件几乎总是与UTF-8标准头兼容,但请参阅下面的reedit.

Reedit:下次; 记住一句简单的口头禅:"N'DUUH!"; "永远不要使用UTF-8!"

国际化

这种问题的一个常见解决方案是通过例如gettext完全消除问题.

使用gettext时,通常最终会得到一个loc(char *)抽象掉大部分翻译工具特定代码的函数.所以,而不是

#include <iostream>

int main () {
  std::cout << "????" << std::endl;
}

你将会拥有

#include <iostream>

#include "translation.h"

int main () {
  std::cout << loc("DEEPER_MEANING") << std::endl;
}

并且,在zh.po:

msgid DEEPER_MEANING
msgstr "????"

当然,你也可以有一个en.po:

msgid DEEPER_MEANING
msgstr "Still waters run deep"

这可以扩展,并且gettext包具有用于扩展具有变量等的字符串的工具,或者您可以使用它printf来计算不同的语法.

第三种选择

而不必处理具有不同文件编码,文件结尾,字节顺序标记和其他类问题的不同要求的多个编译器; 可以使用MinGW或类似工具进行交叉编译.

此选项需要一些设置,但可能会很好地减少未来的开销和头痛.