У меня на -finput-charset ругается более определённо:


То же самое и с CP1251.

Тогда я сделал проще.

1. Написал строчку в main.c:

2. Открыл main.c в блокноте, и сохранил его в формате UTF-8 (под именем main.txt, чтобы остальные строковые константы не испортить).
3. Открыл main.txt в обычном ascii-редакторе (у меня это редактор FAR-а) и скопировал получившуюся строчку (она выглядит примерно так):

в мой main.c.

И телемаркет ©

Ваш редактор не знает UTF-8 ? o_O
возмите хотя-бы notepad++ или scite - там такие конвертеры встроенные.

Сообщение отредактировал ukpyr - Aug 1 2008, 17:36

Ну и к чему здесь это ваше высказывание? Мне категорически не надо, чтобы мои исходники были в UTF-8. Поэтому такая поддержка — последняя вещь, которую я оценю в редакторе
Просто помог человеку решить его проблему.

Думаю модифицировать макрос для нужного языка неслжоно.

PS: Желание использовать какой-либо иной язык, кроме английского, в дескрипторах было напрочь отбито, когда устройство через 2 года производства вставили в ПК с Milenium (помните такую версию винды?) и ее разнесло в "дребезги-пополам" ((С) Жванецкий). Пришлось отзывать 100000 устройств и перешивать дескрипторы. Возможно в XP или Vista дело улучшилось, но предпочитаю не рисковать.


А разве UTF-8 катит для дескриптора? Разве там не UTF-16?




Мои исходники всегда в UTF-8. И чем это мешае компилятору? Он соответствует ASCII относительно собственно кода.

Компилятору нужна была исходная строка в UTF-8. А он её преобразовал в юникод. (я в bin-файле посмотрел)



А русские строчки? Ну, строковые константы? А таблицы перекодировки для вывода на ЖКИ? А шрифты?
Да ну их, эти геморрои с преобразованием, лучше уж я буду точно знать, что у меня и где

В общем, я сделал примерно так же за следующими исключениями:
1. создал файл с единственной строкой
int Name[] PROGMEM = L"имя";
и #include'ил ее в нужном месте в программу.
2. файл создавал редактором Visal Studio, так как блокнот создает utf-8 с сигнатурой в начале файла, а компилятор на эти символы ругается; у Visal Studio больше возможностей редактирования и им можно создать файл в utf-8 без сигнатуры, даже когда открываешь этот файл повторно, он догадывается о его кодировке (несмотря на отсутствие сигнатуры) и предлагает открыть именно как utf-8


А я думаю что сложновато.

Я знаю людей, которые до сих пор пишут комментари по-русски латинскими буквами на том основании, что когда они работали в ДОСе (!) то там было много кодировок и их комментарий мог где-то не прочитаться. Вы чем-то на него похожи: миллениум всеми успешно забыт, а вы все боитесь русских букв. Хотя юникод придуман как раз для того, чтобы он был единственной кодировкой.

Хорошо известно, что юникод поддерживают только NT-based системы; вместо того, чтобы отзывать 1(0...) устройств, следовало бы в инстукции перечислить ОС с которыми ваше устройство работает.

Тем, что его не понимает редактор AVR-студии. Впрочем, если в нем нет русских букв, то несколько странно утверждать, что он в utf-8

Сообщение отредактировал 777777 - Aug 4 2008, 09:44

А, понял.
Я пишу коментарии на английсом, а строчки всегда в файлах перевода. Ну в общем в отдельных файлах находятся все сообщения для пользователя. В общем используем подход по аналогии QT Linguist. И переводчикам легче.


Можно и меня причислить к ним, хотя и по другой причине. Иногда исходники пытаются скомпилить на виндовс машине, и тогда возникают проблемы с не-латиницей.

Такого подхода я непонимаю. Мои устройства конечно не рботают в ДОС, Вин 3.11 им подобными, но Linux, FreeBSD, Solaris, MacOS 9+, Win98 - NT4 2000 - Vista - обязательны.

Иногда все же бывают строки на не-английском языке прямо в коде. Про avr-gcc ничего не могу сказать, но по крайней мере i686, x86_64, arm, и под некоторые специфические архитектуры проблем это не вызывает.

это с каких пор ?

Сообщение отредактировал ukpyr - Aug 4 2008, 19:05

Запусти какую-нибудь юникодную программу под Win98 и прочитай что она тебе напишет.

4.2
Если *некоторые* недопрограммы под недоОС, написанные недопрограммистами, не умеют пользоваться тем, что есть, это их индивидуальные интимные проблемы.
Кроме того, никто не отменял независящие от вендора реализации работы с Unicode. Вещи, которые, насколько я знаю, *невозможно* сделать в 9х, — это юникодные заголовки окон, юникодный ввод с клавиатуры (без использования "кодовых страниц"), юникод в терминале. Всё остальное можно либо реализовать самому, используя имеющееся API, либо положиться на реализацию от кого-либо ещё, а таких немало: MSLU (от вендора), GLib и компания, Qt.

--
WBR, Andrew