Как правильно использовать параметр компилятора s-finput-charset g++для компиляции исходного файла, отличного от UTF-8?

Я пытаюсь скомпилировать исходный файл UTF-16BE C++ в G++ с параметром компилятора-finput-charset, но я всегда получаю кучу ошибок. Более детально следовать.

моя среда (в 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;
}

мой шаги:

• Я прочитал руководство g++ о опции-finput-charset. руководство g++ говорит:

- finput-charset=charset Установить входной набор символов, используемый для перевода из набора символов входного файла в исходный набор символов, используемый ССЗ. Если языковой стандарт не указан или GCC не может получить это информация из локали,значение по умолчанию-UTF-8. Это может быть переопределяется параметром locale или командной строки. В настоящее время параметр командной строки имеет приоритет, если конфликт. charset может быть любой кодировкой, поддерживаемой системой "iconv" обычной библиотеке.

• таким образом, я ввел команду следующим образом:

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

и я получил эти ошибки:

в файл в комплекте с основной.cpp: 1:

в/usr/lib в/ССЗ/для i386-RedHat это-линукс/4.1.2/../../../../ включить/c++ / 4.1.2 / iostream:1: ошибка: stray '342 ' в программе

в/usr/lib в/ССЗ/для i386-RedHat это-линукс/4.1.2/../../../../ включить/c++ / 4.1.2 / iostream:1: ошибка: stray '274 ' в программе

...(неоднократно, много, около 4000+)...

в/usr/lib в/ССЗ/для i386-RedHat это-линукс/4.1.2/../../../../ включить/c++ / 4.1.2 / iostream:1: ошибка: stray '257 ' в программе

main.cpp: в функции ' int main()’:

main.cpp: 5: ошибка: 'cout’ не является членом 'std'

main.cpp: 5: ошибка: "endl" не является членом "std"

• текст руководства предполагает, что кодировка может быть любой кодировкой, поддерживаемой подпрограммой "iconv", поэтому я предположил, что ошибки компиляции могут быть вызваны моей библиотекой iconv. Затем я проверил iconv:

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

A " 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, как сказал" мистер Листер " ниже. Некоторое время это работало нормально, но позже я нашел, что это не подходит для моей ситуации, потому что большинство других частей системы все еще используют UTF-8 для связи и интерфейсов, поэтому я должен преобразовать кодировку во многих местах... Не только издержки моей работы, это также может привести к некоторому снижению производительности в моей программе.
2. позже я попытался преобразовать все мои исходные файлы в UTF-8 + BOM. Таким образом, Visual Studio в Windows может скомпилировать их с удовольствием, но GCC в Linux будет жаловаться. Затем я написал сценарий оболочки для удаления спецификации, и прежде чем я хочу скомпилировать свой код с GCC, я сначала запускаю этот сценарий.
3. К счастью, мне не нужно создавать код в Linux вручную, потому что TeamCity инструмент непрерывной интеграции используется в моем проекте для автоматического создания сборки. Я мог бы изменить шаги сборки в TeamCity, чтобы помочь мне работать этот сценарий перед началом ежедневной сборки.
4. С этой кодировке UTF-8 + спецификации + скрипт способ, я решил не редактировать исходный код в Linux, потому что если я хочу делать так, я должен убедиться, что мой код может построить успешно, прежде чем я совершить это, что означает, что я должен запустить сценарий, чтобы удалить BOM, прежде чем я построить код, что означает, что СВН будет отчитываться каждый файл изменен(спецификации удален), таким образом, сделать его очень легко совершить по ошибке не тот файл. Чтобы решить эту проблему, я написал другой сценарий оболочки для добавьте спецификацию обратно в исходные файлы. Хотя я все еще не очень часто редактирую свой код в Linux, но когда мне действительно нужно, мне не нужно сталкиваться с ужасно длинным списком изменений в диалоговом окне фиксации.