Как вывести русский текст в нужной кодировке на Linux

[andrew.k]

Никогда не пиши программы по принципу "раз работает, значит пойдёт". То что пытаешься сделать описано в 1) стандарте С++ 2) документации Qt. Правильный способ - использовать английский текст и переводить его через tr():

Так и написано "Единственно правильный способ"?

Правильный - да. Возможный - нет.

А где это написано можешь привести?

[sergek]

Другой юзер отредактирует этот код в другом редакторе или в другой кодировке и всё - поплывёт твой русский.

Пытаюсь представить себе эту ситуацию и никак... Этот, другой, когда открывает текст для правок, не видит, что он  в кракозябрах? Или он корректирует какую-то часть, не обращая внимания на остальной текст?
Если программа интернациональная, наверное, вариантов нет, кроме выбора единого языка. Ну, пусть будет американский.
А если проект русскоязычный? Зачем такие сложности, не проще ли команде разработчиков договориться о кодировке исходников?

[andrew.k]

Другой юзер отредактирует этот код в другом редакторе или в другой кодировке и всё - поплывёт твой русский.

Пытаюсь представить себе эту ситуацию и никак... Этот, другой, когда открывает текст для правок, не видит, что он  в кракозябрах? Или он корректирует какую-то часть, не обращая внимания на остальной текст?

Такое возможно конечно же. От невнимательности или от большого размера исходного файла. Не в каждой же строке строковые литералы.

А если проект русскоязычный? Зачем такие сложности, не проще ли команде разработчиков договориться о кодировке исходников?

Обычно так и происходит либо сразу, либо после столкновения с кракозябрами.

А комментарии тоже предлагается на английском писать?
Если люди не в состоянии понимать, что такое кодировка файла, тут ничем не поможешь, никакие нано-технологии не спасут)

UPD: Alex Gustov, Всегда все комментарии на английском. Это единственное правильное решение. Так?

[Alex Custov]

А где это написано можешь привести?

Да, ISO/IEC 14882 "Programming languages-  C++"

2.1.1

Physical source file characters are mapped, in an implementation-defined manner, to the basic source
character set (introducing new-line characters for end-of-line indicators) if necessary. Trigraph
sequences (2.3) are replaced by corresponding single-character internal representations. Any source file
character not in the basic source character set (2.2) is replaced by the universal-character-name that designates
that character. (An implementation may use any internal encoding, so long as an actual
extended character encountered in the source file, and the same extended character expressed in the
source file as a universal-character-name (i.e. using the \uXXXX notation), are handled equivalently.)

2.2.1

The basic source character set consists of 96 characters: the space character, the control characters representing
horizontal tab, vertical tab, form feed, and new-line, plus the following 91 graphical characters:15)
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
_ { } [ ] # ( ) < > % : ; . ? * + - / ˆ & | ˜ ! = , \ " ’

Qt manual:

However, if you want to write portable code, we recommend that you avoid non-ASCII characters in your source files. You can still specify non-ASCII characters portably using escape sequences, for example:

label->setText(tr("F\374r \310lise"));

[andrew.k]

В приведенном отрывке стандарта вводится понятие базового набора символов (base character set) и описание процесса работы с символами которые не входят в базовый набор.
Разве отсюда следует, что нужно и/или можно использовать только базовый?

Насчет второго отрывка: "...if you want to write portable code, we recommend...". Это рекомендация.

Что ты посоветуешь насчет комментариев? Ты тактично умолчал.

[Alex Custov]

В приведенном отрывке стандарта вводится понятие базового набора символов (base character set) и описание процесса работы с символами которые не входят в базовый набор.
Разве отсюда следует, что нужно и/или можно использовать только базовый?

"Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates".  Отсюда в gcc на разных платформах иногда начинают лезть ошибки типа "stray \xxx\xxx..." in program.

Насчет второго отрывка: "...if you want to write portable code, we recommend...". Это рекомендация.

Рекомендация чтобы писать портабельный код. Ты МОЖЕШЬ писать непортабельный код, но будет ли он согласовываться со стандартом - это отдельный вопрос. В твоём случае не будет.

Что ты посоветуешь насчет комментариев? Ты тактично умолчал.

А  что тут говорить, по стандарту - нельзя. По факту - можно, т.к. все известные мне реализации тупо пропускают текст между символами комментария /* */ или //, то есть писать там можно всё что угодно.

[andrew.k]

В приведенном отрывке стандарта вводится понятие базового набора символов (base character set) и описание процесса работы с символами которые не входят в базовый набор.
Разве отсюда следует, что нужно и/или можно использовать только базовый?

"Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates".  Отсюда в gcc на разных платформах иногда начинают лезть ошибки типа "stray \xxx\xxx..." in program.

Это говорит лишь об ущербности этой версии или о том, что она как раз не поддерживает universal-character-name.
Но никак не о том, что так делать нельзя.

Насчет второго отрывка: "...if you want to write portable code, we recommend...". Это рекомендация.

Рекомендация чтобы писать портабельный код. Ты МОЖЕШЬ писать непортабельный код, но будет ли он согласовываться со стандартом - это отдельный вопрос. В твоём случае не будет.

Это смотря насколько широко рассматривать портабельность.
Если я точно знаю, что мне не потребуется локализация моего приложения. То зачем мне tr?
Одни и те же исходники с русским строками прекрасно собираются и в линукс, и в винде. Без каких либо конвертаций и преобразований.
И нет никаких "модных" проблем с кодировкой. Может я что-то не так делаю? )

Что ты посоветуешь насчет комментариев? Ты тактично умолчал.

А  что тут говорить, по стандарту - нельзя. По факту - можно, т.к. все известные мне реализации тупо пропускают текст между символами комментария /* */ или //, то есть писать там можно всё что угодно.

Да почему нельзя-то никак не пойму?
Ты привел текст в котором написано, что не ASCII-символы при компиляции будут заменены на последовательность вида \xxx.
Почему отсюда вывод, что нельзя?
Пока не убедил.

[Alex Custov]

Это говорит лишь об ущербности этой версии или о том, что она как раз не поддерживает universal-character-name.
Но никак не о том, что так делать нельзя.

Конечно нельзя, пример с UTF BOM - яркий пример. В gcc не зря есть флаг, который задаёт кодировку исходника, совсем не зря.

Это смотря насколько широко рассматривать портабельность.
Если я точно знаю, что мне не потребуется локализация моего приложения. То зачем мне tr?
Одни и те же исходники с русским строками прекрасно собираются и в линукс, и в винде. Без каких либо конвертаций и преобразований.
И нет никаких "модных" проблем с кодировкой. Может я что-то не так делаю? )

Ты просто живёшь в счастливое время UTF-8. Скажем, лет восемь назад в том же Линуксе у всех были разные локали, и исходники написанные в разных дистрибутивах имели бы разную кодировку.  Если это работает здесь и сейчас - хорошо. Является ли это правильным решением? Ответь сам на вопрос.

Стандарт ведь не дураки пишут Между прочим, аналогичная ситуация с ID3 тегами в MP3.

Да почему нельзя-то никак не пойму?
Ты привел текст в котором написано, что не ASCII-символы при компиляции будут заменены на последовательность вида \xxx.
Почему отсюда вывод, что нельзя?

Я подумал, и в принципе здесь ты прав, потому что опять же исходя из реалий, что компилятор просто пропускает этот текст.

[andrew.k]

Это говорит лишь об ущербности этой версии или о том, что она как раз не поддерживает universal-character-name.
Но никак не о том, что так делать нельзя.

Конечно нельзя, пример с UTF BOM - яркий пример. В gcc не зря есть флаг, который задаёт кодировку исходника, совсем не зря.

А в чем яркость? В том, что старые версии gcc его не понимают?
Таким же успехом, можно говорить, что исходники написанные в 4.6, не компилятся в 4.4. И делать из этого вывод о непортируемости.

Ты просто живёшь в счастливое время UTF-8. Скажем, лет восемь назад в том же Линуксе у всех были разные локали, и исходники написанные в разных дистрибутивах имели бы разную кодировку.  Если это работает здесь и сейчас - хорошо. Является ли это правильным решением? Ответь сам на вопрос.

Я и пишу исходники в это же самое счастливое время
Но пример, который я приводил, там исходники в кодировке koi8-r как это не печально и они с успехом компилятся под виндой и не имеют проблем с русским языком (это конечно благодаря великому и могучему Qt : ).

Стандарт ведь не дураки пишут Между прочим, аналогичная ситуация с ID3 тегами в MP3.

Конечно не дураки, но пока что мы не обнаружили строк, которые запрещают использовать в исходниках символы отличные от ASCII (Пантер, наверное с ума сходит, читая этот тред : ). Я хочу чтобы меня аргументированно убедили.

Да почему нельзя-то никак не пойму?
Ты привел текст в котором написано, что не ASCII-символы при компиляции будут заменены на последовательность вида \xxx.
Почему отсюда вывод, что нельзя?

Я подумал, и в принципе здесь ты прав, потому что опять же исходя из реалий, что компилятор просто пропускает этот текст.

Как это пропускает, если printf("Очень русский текст\n"); выведет на консоль сам знаешь что)
Я думаю, это сделано лишь для обратной совместимости, для того, чтобы старые версии компиляторов могли внятно объяснить, почему этот исходник не может быть скомпилен (я могу ошибаться).

[Alex Custov]

Конечно не дураки, но пока что мы не обнаружили строк, которые запрещают использовать в исходниках символы отличные от ASCII (Пантер, наверное с ума сходит, читая этот тред : ). Я хочу чтобы меня аргументированно убедили.

Как это не обнаружили?

"Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary". И далее: "Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates that character.", а это значит, что все строковые литералы зависят от кодировки файла! Поменял кодировку - и тю-тю. Откуда компилятор знает, что ты имел ввиду? Он тупо перегонит всё в \xxx... и всё, дальше его не волнует, что русская буква "a" оказалась не на том месте в текущей кодировке.

Как это пропускает, если printf("Очень русский текст\n"); выведет на консоль сам знаешь что)
Я думаю, это сделано лишь для обратной совместимости, для того, чтобы старые версии компиляторов могли внятно объяснить, почему этот исходник не может быть скомпилен (я могу ошибаться).

Речь шла о комментариях, а не о самом коде.

Раз уж ты затронул printf, то покажу кое что с этим printf-ом:

$ ./qt4-template
����� ������� �����

Упс. А где русский текст?

[Bepec]

Алекс вы не приводите аргументов, а пытаетесь убедить, что "Это плохо."

% 80 тем на этом форуме, в проблемах с русским языком в исходниках неаргументированны.

И САМЫЙ ГЛАВНЫЙ ФАКТ:

Я тоже пользовался Английским в программах, ибо лингвист отказывался понимать windows-1251 и переводить его в иные языки.

НО, посмотрев исходники, оказалось что в версии Qt SDK 4.7.2 в lrelease и lupdate статически прилинкованы кодеки БЕЗ windows-1251 Это засада со стороны троллей...

Скачивание исходников - компилирование. И через 5 минут у меня появились утилиты, поддерживающие Великий и Могучий. Коими пользуюсь и сейчас.

Главный аргумент - Открой любой форматированный файл  в другой кодировке, отличной от исходной. Он сохранит работоспособность?
Вот и не стоит упирать на "а вдруг, кто то пересохранит".

update: кстати а что делать, если человек который будет смотреть проект, незнает английского?

[Пантер]

update: кстати а что делать, если человек который будет смотреть проект, незнает английского?

Значит этот человек не нужен.

[Bepec]

Пантер, вот ненадо фатализма Есть нужные люди, незнающие английского. И не обязательно программные.

[Пантер]

Пантер, вот ненадо фатализма Есть нужные люди, незнающие английского. И не обязательно программные.

Эм. А нафига не программисту смотреть код? О_о

[andrew.k]

Конечно не дураки, но пока что мы не обнаружили строк, которые запрещают использовать в исходниках символы отличные от ASCII (Пантер, наверное с ума сходит, читая этот тред : ). Я хочу чтобы меня аргументированно убедили.

Как это не обнаружили?

"Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary". И далее: "Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates that character.", а это значит, что все строковые литералы зависят от кодировки файла! Поменял кодировку - и тю-тю. Откуда компилятор знает, что ты имел ввиду? Он тупо перегонит всё в \xxx... и всё, дальше его не волнует, что русская буква "a" оказалась не на том месте в текущей кодировке.

Похоже конструктив иссяк и началось приперательство. По поводу этого абзаца, я уже писал, что думаю.
Если аргумент не убедил оппонента, его нужно повторять снова и снова?
Тогда: из него не следует, что так делать нельзя.

Речь шла о комментариях, а не о самом коде.

Значит я не уловил твою мысль.

Раз уж ты затронул printf, то покажу кое что с этим printf-ом:

$ ./qt4-template
����� ������� �����

Упс. А где русский текст?

Ну ты сам все прекрасно понимаешь. Воспользуйся поиском

Я могу такой же пример с printf привести, где русский будет прекрасно выводиться.

Код:

$ ./a.out
Очень русский текст

Опять я могу в исходниках не использовать русский язык, а все сделать "правильно" и получить на консоли квадраты. Главное понимать, что ты делаешь.

А если подробно рассмотреть этот пример с printf. То нужно понять, о чем мы говорим. О gcc или о Qt?
Если первое. То скомпили этот исходник только с помощью gcc без использования qt.

Проблема собственно в самом Qt. В том, что по умолчанию он для const char* строк использует кодировку latin1, в которой нет набора русских символов. Хотя в твоем примере, скорее проблема в кодировке файла.
Вывод: в этом примере и собственно по теме, проблема не в компиляторе, а в особенностях Qt.