Unicode и выбор внутренней кодировки программы

Для Unucode, если в программе посимвольная работа с текстом, то какое лучше выбрать решение в плане кодировки и работы с ней?

На пример, потребуется прыгнуть на 25-й символ. И подобные вещи.

Как известно любой юникодовый элемент полностью влазит в 4 байта. И можно было бы просто взять кодировку UTF-32, но как-то жаба давит. Для экономии придумали не выдавать под символы лишних байт, если в них у символа стоят одни нули. Таким образом в UTF-8 размер элемента может сокращаться с 4 до 3, 2 и 1 байт. Такой текст становится экономней хранить, а если ещё однобайтную часть отдать полностью под ASCII, то для ещё удобнее. Но тогда для программиста становится не возможно работать с таким текстом как с обычным массивом, ибо элементы в тексте непредсказуемо разных размеров. Когда только ввели UTF-16 и отсчитывать стали по 2 байта, то временно стало можно с любым текстом работать как с обычным массивом, так как все возможные элементы умещались в этих двух байтах. Но потом в стандарт добавили новые языки и всё снова стало уныло. С этого момента по-простому только UTF-32.

Стоит ли выбрать UTF-32 для простой полной поддержки или лучше обрезанную двухбайтовую UTF-16 без всякой египетской письменности и домино? Или может быть всё таки стоит заморочиться на полной поддержке UTF-16 с хренением доп массива начальных байтов каждого элемента?

Каков вообще выбор мастеров в этой сфере программирования?

0

Сообщение от vipermagi заморочиться ... с хренением

Цели у вас какие?

Локализация на мандарине?
Или у вас супернапоминалка для русскоязычного пользователя?
Если так, то и однобайтного Windows-1251 достаточно.

0

Сообщение от gazlan Если так, то и однобайтного Windows-1251 достаточно.

Ага, сначала один такой "зачем мне юникод? Сделаю Windows-1251". Потом другой "зачем мне юникод? Сделаю shift-JIS". А пользователю потом переключай язык системы туда-сюда, чтоб весь этот зоопарк нормально работал.

0

Сообщение от gazlan Цели у вас какие?

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

Изначально пишу под линуксом, но нужен будет кроссплатформ, и скорее всего кроссфреймворк.

0

Можете обратить внимание на либу ICU [home] [wiki].
Она же используется в фреймворке Qt.

0

Сообщение от vipermagi но если расширить задачи и они вдруг станут нужны

Если ... и когда ...

IMHO, для начала стоит убедиться, что это нужно хотя бы вам. По ходу работы цели и приоритеты могут меняться. Начинать надо с минимального прототипа, расширяемого по необходимости, а не с проектирования кроссплатформенного монстра на 123 несуществующих языках.

Можете почитать блог Alconost, чтобы получить представление о локализации.

0

ОС-то какая?

Сообщение от gazlan Если так, то и однобайтного Windows-1251 достаточно

Ну gazlan, как всегда, склоняет людей к древним кодировкам. Если Windows, то никаких 1251, использовать WCHAR, как там и положено. А в Linux, wchar_t 4-байтный, проблем с индексацией нет.

0

Сообщение от gazlan IMHO, для начала стоит убедиться, что это нужно хотя бы вам. По ходу работы цели и приоритеты могут меняться. Начинать надо с минимального прототипа, расширяемого по необходимости, а не с проектирования кроссплатформенного монстра на 123 несуществующих языках. Можете почитать блог Alconost, чтобы получить представление о локализации.

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

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

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

Сообщение от iRomul Можете обратить внимание на либу ICU

Лицензия смущает меня. Не понятно заражает ли ICU мой код своей "nonrestrictive" лицензией, после чего любой скачавший мою прогу сможет и с ней делать всё то, что он мог бы делать с ICU по еёйной лицензии. Если я вот, например, закрыл прогу и бесплатна она только для некомерческого использования у меня, сможет ли скачавший мою прогу комерс, прочитав в ней приложенную лицензию ICU, законно забить на мои запреты к бесплатному коммерческому использованию?

Сообщение от nmcf ОС-то какая?

Кроссплатформенная, но покамест на линуксе будет.

Я настроен читать файл в массив байт и бегать по этим байтам как-то.

Сообщение от nmcf Если Windows, то никаких 1251, использовать WCHAR, как там и положено. А в Linux, wchar_t 4-байтный, проблем с индексацией нет.

В виндовсе WCHAR нужен в количестве двух штук иногда. В линуксе wchar_t почти всегда будет выхватывать два символа из текста. Ну это касательно UTF-16, а если файл в родной UTF-8, то там вообще кашу будет зачерпывать.

0

Сообщение от vipermagi алгоритмы обработки текста

Парсер работает с лексемами. А будет в них 1-2-4 ... много байтов (или просто неравномерные битовые коды), это забота лексера. А ему что один бит взять из потока, что 64 ... туда-сюда по дереву кодов.

0

Сообщение от gazlan Парсер работает с лексемами. А будет в них 1-2-4 ... много байтов (или просто неравномерные битовые коды), это забота лексера. А ему что один бит взять из потока, что 64 ... туда-сюда по дереву кодов.

Я не планирую заниматься синтаксическим или лексическим анализом. Во всяком случае на данный момент задачи такой не стоит. Всё намного проще. Например: найти в тексте слово или кусок слова и скопировать предложение, в которое входит найденная подстрока. Ну или абзац там. Нахватать таких предложений или абзацев и склеить в новый текст. Без всяких деревьев и прочих премудростей.

0

Сообщение от vipermagi найти ... и скопировать

Г-н Журден. Что? Когда я говорю: "Николь, принеси мне туфли и ночной колпак", это проза? Учитель философии. Да, сударь. © Жан-Батист Мольер. Мещанин во дворянстве

Вы не поверите - это и есть анализ. С деревом решений и прочими "премудростями".

0

В 2-байтовый формат utf16 входит и кириллица и многое другое. Так что если иероглифы не нужны, надолго хватит.
Когда-то это было весь Unicode

0

Сообщение от vipermagi И можно было бы просто взять кодировку UTF-32, но как-то жаба давит

А что мешает сделать typedef, который одним лёгким нажатием будет перещёлкиваться с варианта "2 байта" на вариант "4 байта". Ну и попутно при чтении/записи из/в файл поменяется настройка внутренней кодировки. По-моему ты видишь проблему на пустом месте

0

Сообщение от Evg А что мешает сделать typedef, который одним лёгким нажатием будет перещёлкиваться с варианта "2 байта" на вариант "4 байта". Ну и попутно при чтении/записи из/в файл поменяется настройка внутренней кодировки. По-моему ты видишь проблему на пустом месте

Ты предлагаешь на загрузке определять есть ли в тексте символы шире чем 2 байта и включать тогда тайпдеф на 4 для всего текста? Довольно здравая мысль.

Прочитал тут у буржуев, что оказывается повсеместно используется обрезанная двух байтная UTF-16 без заморочек по переключению на 4 байта. Надо бы углубиться в этот увлекательнейший холивар. А пока остановлюсь на варианте определения при загрузке файлов UTF-32 будет или останется 2-х байтный UTF-16; ну и буду иметь в виду ICU.

0

Сообщение от vipermagi Ты предлагаешь на загрузке определять есть ли в тексте символы шире чем 2 байта и включать тогда тайпдеф на 4 для всего текста? Довольно здравая мысль

Нет. Я предлагаю сделать typedef размером в 2 байта и так жить. Если вдруг в будущем возникнет потребность использовать 4-байтный вариант, то заменяешь 2 на 4 и в 2-3-4-5 местах исправляешь код программы, где делается связь с внешним миров (чтение-запись файлов). Уверен на 99%, что до 4-байтного варианта дело никогда не дойдёт: либо не будет реальной потребности, либо программа сдохнет раньше, чем появится потребность

1