Есть исходный английский текстовый файл, написанный латиницей в Unicod UTF-8.
Его требуется перевести на русский язык (ес-но, на кириллице), и при этом сохранить первоначальную кодировку UTF-8.

Все попытки выполнить требуемое, заканчиваются не очень удачно: файл "разбухает" в размере практически в два раза, при том, что количество строк, остается неизменным, при незначительном изменении количества символов в каждой строке (в ту, или другую сторону), т.е. общее количество символов в тексте практически не изменяется.

Просмотр HEX-кода файла встроенным в FAR редактором показывает, что каждый символ кириллического текста отображается двумя символами (не понятными для меня). Это и удваивает общий размер файла.

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

P.S. Кстати, точно такой же китайский файл написанный иероглифами, по размеру практически не отличается от английского.

P.P.S. Не нашел более подходящего раздела для размещения вопроса. Если модератор посчитает, что теме не место в этом разделе, прошу перенести ее, или вообще удалить.

То UTF16 у вас получился.

А вы уверены, что вы все знаете про UTF-8?

Если бы я был в этом уверен, я бы не сунулся с подобным вопросом в раздел для начинающих.

А вы уверены, что ваш встречный вопрос поможет мне в решении проблемы?

Ваша ссылка утверждает, что китайское письмо должно утраивать размер файла, но фактически этого не происходит.
То, что один иероглиф часто соответствует не букве а целому слову или фразе, я знаю!

если хотите 8 битную кодировку - берите русский текст и через блокнот сохраняйте в формате ANSI , при этом будет задействована 8-битная кодировка Windows-1251.

http://ru.wikipedia.org/wiki/Windows-1251

Китайский язык немного по другому устроен, чем русский или английский...
Старый анекдот напомнили: Брежнев приехал в Китай. Полчаса выступает с трибуны, затем подходит
переводчик и произносит лишь одно слово. Выступает еще полчаса - переводчик снова произносит лишь
одно слово. Причем то же самое слово... Извините за оффтоп.

Вот ё.
Китайское предложение может состоять из одного иероглифа. В то время как английское из нескольких слов.
В википедии все доступным языком прописано.

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

Не совсем понятно, как конечная цель коррелирует с описываемыми вами проблемами?
Вот я беру небольшой ASCII-файл 963 байта и с помощью редактора FAR2 сохраняю его как UTF-8. Размер файла становится 1773 байт. Но я не вижу, где тут проблема-то? Если ваша железка действительно способна UTF-8 отображать, то причем тут длины файлов?
Строка символов на экране в любой исходной кодировке должна выглядеть одинаково.

Начинаю понимать, что скорее всего ни при чем.
Еще вопрос. Где и как задается стиль и размер шрифта такого файла?

На этот вопрос лучше всего может ответить разработчик прибора, в вашем случае - китайцы из Теквэя. Или кто-то из хакеров EEVblog-а. Или можете сами докопаться до ответа, если будете изучать man Линукса.

Нигде. Файл содержит текст. Кто и как будет его показывать, ни файл, ни текст в нём не в курсе.

Понял. Спасибо.

Очередной вопрос по кодировке UTF-8.

В тексте есть несколько "нестандартных" символов, описание которых я не нашел в HEX-таблице этой кодировки. Речь идет о символах "Бесконечность" (горизонтальная восьмерка), "Умножение" (не буква "Х" кириллицы или латиницы, а именно крестик), и самое главное - о символе "математическое неравенство" (перечеркнутое "равно"). Предполагаю, что все это символы псевдографики, специально созданные разработчиком для этого прибора.
Редактор FAR2 (и некоторые другие редакторы, но не все) нормально читаю и отображают эти символы. Насколько я понимаю, FAR2 показывает десятичный код символа, под которым расположен курсор, в правом краю своей верхней (служебной?) строки. Этот код для "неравенства" - 8800.
Но любая попытка посмотреть hex-код приводит к модификации, и искажению символа при дальнейшем просмотре - графически он вырождается в "кракозяблу" (ее hex-код, если я его правильно считываю: E2 89 A0). При возврате из режима просмотра hex-кодов в обычный вьювер, FAR2 перекодирует весь текст из UTF-8 в ANSI 1251.
Нужный символ в модифицированном и сохраненном файле, вообще перестается отображаться на дисплее прибора - вместо него рисуется пробел.
Попытка импортировать код символа, или целую строку содержащую этот символ из исходного файла в модифицированный результата не дает - на дисплее символ отсутствует.
Как ни странно, "бесконечность" более лояльно относится к экспериментам с перекодировками - этот символ нормально отображается на дисплее после модификации.
"Умножение" пришлось заменить на литинский "х" - начертания буквы несколько отличаются от оригинального символа, и не только размерами, но с этим можно примириться.
А вот с "неравенством" полный косяк. Для того, чтобы вывести на экран хоть что-то, по смыслу напоминающее "не равно", пришлось рисовать вот такую комбинацию: "<=>". Благо, место позволяет...

Если кто-то сталкивался с подобным, и нашел решение проблемы, прошу подсказать, в каком направлении двигаться.

Вам нужен Unicode редактор, который умеет читать и писать файлы в UTF-8. Любые преобразования внутри редактора в ANSI вам сразу обрежет половину символов

Кто-бы еще ссылкой поделился на такой редактор. Или хотя бы его название озвучил.
Я перепробовал более десятка текстовых редакторов, и только один из них - встроенный в FAR2 - позволил хоть что-то сделать.

Notepad++ ?

Не работает.


Только что перепроверил еще раз. Открыл, перекодировал и сохранил файл в Notepad++, затем залил в прибор.
Увы, неравенство исчезло. Заметил еще - исчезает, так же, символ "№". Хотя в файле оба символа есть, и на компе отображаются нормально.
Парадокс в том, что исходный английский файл с теми же символами вполне адекватно читается прибором, и все символы НОРМАЛЬНО рисуются на дисплее! Но как только эти символы попадают в русский файл, они становятся недоступными для прибора. Хотя весь остальной текст выводится абсолютно нормально.
Дурдом...

Вот два принт-скрина с дисплея скопа, сделанные практически одновременно:

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла


Решил посмотреть, как обстоят дела в немецком и французском вариантах (файлы меню, вшитые в прогу без моего участия, самим производителем).
Чудны дела твои, Господи!
Похоже, китайцы научили прибор выводить на дисплей неравенство только в своем китайском меню, и в английском - для немцев и французов этот математический знак тоже не доступен!

Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла


Вот это неожиданность...

Код символа в UTF8 будет E289A0. Попробуйте.
Конвертировать UTF16 <> UTF8 умеет хоть "Блокнот" из WindowsXP. При открытии\сохранении файла достаточно указывать кодировку (ниже имени файла там, обычно никто внимания не обращает).

По поводу кода Е289А0 я уже писал выше. Я вижу этот код как в оригинальном, английском файле меню, так и в своем переводе, но символ из первого файла читается скопом адекватно, а в моем переводе игнорируется, хотя код символа и там, и там написан одинаково.

С учетом того, что скоп не понимает этот (и пару других) символов не только в моем, русском файле, но и в немецком и французском файлах, залитых самим разработчиком, остается предположить, что проблема где-то внутри самого прибора, а не в моем неумении работать с редакторами текстовых файлов различных кодировок.

Блокнот из винды открывает файл, но не реагирует в нем на код перевода строки (0А), и показывает весь текст сплошным массивом. Или привязывает перенос с размерам окна. И в том, в другом случае это не удобно для правильного форматирования размеров (длин) строк, и сравнения с исходным файлом.

Быть может, в начале файла префикс UFT8 нужен\не нужен? Тот, который EFBBBF.

Проверил.
Префикс EFBBBF есть во всех файлах - и в тех, в которых читаются хитрые символы, и в тех, в которых они не читаются.