Re[4]: Best GUI for Windows C++ application - C/C++. Прикладные вопросы

Здравствуйте, Cyberax, Вы писали:

А>>>>- Разбить UTF-8 строку в любом месте нельзя: если разбить ее посреди многобайтового символа, получится лажа.
C>>>А зачем это делать? Разбиение по всяким стандартным разделителям (' ', ',', ';'...) работает нормально.
А>>Не согласен, т.к. это зависит от задачи.
C>Что зависит?

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

А>>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.

C>Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.

Текст, в отличие от бинарных протоколов, оперирует символами, а не байтами. Надеюсь, разница между ними понятна?

C>В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.

Без примеров вы не согласны понять, о чем речь?

Хорошо, приведу пример из практики: разбивка заголовка письма (RFC822 et al) на строки, не превышающие 80 символов длиной.
Алгоритм примерно такой (несущественные детали опущены):
— рубим строку на байты длины N такой, чтобы length( base64( кусок ) ) < 80
— каждый кусок кодируется в base64 отдельно.

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

Это хороший пример?

C>>>А вот за такой "рассчёт размера" (т.е. "ширина страницы / размер символа") я бы избивал железной трубой.
А>>Это твои личные переживания или есть какое-то обоснование?

C>Оно будет криво работать со всеми языками со сложным написанием букв.

Если внутреннее представление библиотеки не допускает сложных написаний букв, оно будет работать прямо.
Никто ведь не утверждает, что внутри библиотеки хранится правоверный UNICODE.

C>>>Для правильного выравнивания текста подсчёт длины UTF-8 строки будет такой мизерной частью кода, что просто смешно.
А>>Зависит от.
А>>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

C>Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.

Открою страшную тайну: задача "вывести строку" в 99% случаев заключается в установке свойства text у какого-нибудь контрола или виджета.

C>"Разбивка на строки" — это такая ерунда.

Да, согласен.
Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.

А>>К примеру, багзилла старых версий выводила русский текст в комментариях к багу весьма по-уродски именно потому, что обрабатывала UTF-8 как обычный ASCII.
C>Зачем ей обрабатывать его?

Пример не понят, потому что недостаточно понятен? Или, может, потому что Анонимус заведомо говорит пургу?

Багзилла выводит комментарии к багу внутри тега <pre>, чтобы форматирование кода не расползалось.
При этом слишком длинные строки заворачиваются, чтобы не приходилось скроллить страницу влево-вправо при просмотре.

А>>>>- Мы-то знаем, что в строке UTF-8, а вот операционная система и рантайм-библиотека — не в курсе.
C>>>А нафиг им это знать?
А>>Затем, чтобы использовать ту же кириллицу
А>>Скорми русское имя файла в UTF-8 под виндой функции CreateFileA() (или fopen(), или классу std::ofstream ) и удивись.
C>Винда — это уродец. В Линуксе всё прекрасно работает fopen("Русское Имя") (текст в utf-8) прекрасно откроет файл с таким именем, вне зависимости от кодировки системы.

Спасибо, добрый человек, ты открыл глаза человечеству.

Вот только одно "но": тема посвящена гую именно под Windows, поэтому откровения немного не в кассу. Как вы говорите, "мимо".

А>>>>А это значит, что придется дополнительно перекодировать из UTF-8 в UCS-2 и обратно при обращении к операционной системе. Заметим, что можно перекодировать и в cтроку char'ов в локальной кодировке, но тогда неизбежна путаница и труднооборимые глюки.
C>>>Зачем?
А>>Затем, чтобы не появлялось удивительных ошибок, когда файл вроде бы есть, а открыть мы его не можем.
А>>Или когда пишем вроде бы в файл "вася.txt", а на диске создается "РеРеРеРе.txt".
C>Странно. У меня таких ошибок нет. ЧЯДНТ?

Дайте догадаюсь. Линукс?

C>>>С каким "юникодом"? UCS-4?
А>>Для меня как для пользователя библиотеки абсолютно не важно, какой конкретно вариант представления выберут разработчики. Вполне допускаю, что там может и не пахнуть правоверным юникодом.
C>До тех пор, пока твоим пользователям не потребуются символы не из BMP.

Как часто они нужны?

Еще раз повторю: там может и не пахнуть правоверным юникодом.
А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.

А>>Основное, что я ожидаю — это то, что
А>>а) его можно легко (средствами библиотеки) перекодировать в тот же UCS-4, UCS-2, UTF-8 или локальную 8-битовую кодировку (в пределах разумного), и
C>utf-8

Не спешите.

А>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>Такого нет, и не может быть в принципе.

"Потому что не может быть никогда", да?

Здравствуйте, Аноним, Вы писали:

C>>Что зависит?
А>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>Так понятнее?
Нет.

А>>>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.
C>>Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.
А>Текст, в отличие от бинарных протоколов, оперирует символами, а не байтами. Надеюсь, разница между ними понятна?
Нет.

Разницу между глифом, code point'ом, символом и байтом знаем?

C>>В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.
А>Без примеров вы не согласны понять, о чем речь?

Да.

А>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>Это хороший пример?
Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.

C>>Оно будет криво работать со всеми языками со сложным написанием букв.
А>Если внутреннее представление библиотеки не допускает сложных написаний букв, оно будет работать прямо.
Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.

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

А>>>Если не стоит задача нарисовать свой ворд, разбивка строки на кусочки нужного размера — это 90% всех задач по форматированию текста.

C>>Мимо. Даже в задаче "вывести строку" большая часть сложности — это обработка символов сложного начертания, композитных символов, кернинга и т.п.
А>Открою страшную тайну: задача "вывести строку" в 99% случаев заключается в установке свойства text у какого-нибудь контрола или виджета.
Да. И поэтому тут нафиг не нужна посимвольная адресация.

C>>"Разбивка на строки" — это такая ерунда.
А>Да, согласен.
А>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.
Ничуть. Всё делается элементарно, даже с UTF-8.

А>>>К примеру, багзилла старых версий выводила русский текст в комментариях к багу весьма по-уродски именно потому, что обрабатывала UTF-8 как обычный ASCII.
C>>Зачем ей обрабатывать его?
А>Пример не понят, потому что недостаточно понятен? Или, может, потому что Анонимус заведомо говорит пургу?

Да. Да.

А>Багзилла выводит комментарии к багу внутри тега <pre>, чтобы форматирование кода не расползалось.
А>При этом слишком длинные строки заворачиваются, чтобы не приходилось скроллить страницу влево-вправо при просмотре.
Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.

C>>Винда — это уродец. В Линуксе всё прекрасно работает fopen("Русское Имя") (текст в utf-8) прекрасно откроет файл с таким именем, вне зависимости от кодировки системы.
А>Спасибо, добрый человек, ты открыл глаза человечеству.
Ага.

C>>До тех пор, пока твоим пользователям не потребуются символы не из BMP.
А>Как часто они нужны?

Бывают. Там много полезных символов есть (некоторые символы валют, к примеру).

А>Еще раз повторю: там может и не пахнуть правоверным юникодом.
А>А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.
Так, непонимание Unicode detected.

А>>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>>Такого нет, и не может быть в принципе.
А>"Потому что не может быть никогда", да?

Именно. Читай стандарт.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

C>>>Что зависит?
А>>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>>Так понятнее?
C>Нет.

Боюсь, тогда я помочь ничем не смогу.

А>>>>Если задача стоит порезать строку на куски определенного размера (простейший пример — для какого-нибудь текст-ориентированного протокола), то резьба по разделителям не нужна и даже вредна.
C>>>Какой "текст-ориентированный протокол" ещё? Если нужно резать на байты — это уже не "текст-ориентированный" протокол, а совсем уж бинарный.
А>>Текст, в отличие от бинарных протоколов, оперирует символами, а не байтами. Надеюсь, разница между ними понятна?
C>Нет.

Сожалею.

C>Разницу между глифом, code point'ом, символом и байтом знаем?

Понт защитан.

C>>>В прошлом флейме никто не привёл реальных примеров из своей практики зачем нужна адресация посимвольно в utf-8 строке.
А>>Без примеров вы не согласны понять, о чем речь?

C>Да.

Тогда, может быть, и не надо?

А>>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>>Это хороший пример?
C>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.

То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

Печально.

C>>>Оно будет криво работать со всеми языками со сложным написанием букв.
А>>Если внутреннее представление библиотеки не допускает сложных написаний букв, оно будет работать прямо.
C>Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.

Я так понимаю, ради этого момента истины вы и затеяли сей беспредметный спор?

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

Опять-таки, зависит от задачи.
Если речь идет о том, чтобы текст правильно отобразился — это одно.
Если же задача состоит в правильном промежуточном преобразовании текста так, чтобы с другой стороны его смогли корректно преобразовать в правильный юникод — это другое.
Если задача состоит в том, чтобы текст не превратился в нечитаемый — это совсем третье.

Впрочем, раз вы отказываетесь понимать о чем речь — спор становится беспредметным.

C>>>"Разбивка на строки" — это такая ерунда.
А>>Да, согласен.
А>>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.

C>Ничуть. Всё делается элементарно, даже с UTF-8.

Поделитесь сакральным знанием — как же это делается?

А>>Багзилла выводит комментарии к багу внутри тега <pre>, чтобы форматирование кода не расползалось.
А>>При этом слишком длинные строки заворачиваются, чтобы не приходилось скроллить страницу влево-вправо при просмотре.
C>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.

Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.

А>>Еще раз повторю: там может и не пахнуть правоверным юникодом.
А>>А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.
C>Так, непонимание Unicode detected.

На фоне вашего нарочитого непонимания примеров моя легкая путаница — просто рай.

А>>>>б) один "юникодный" символ соответствует одному "печатному" символу.
C>>>Такого нет, и не может быть в принципе.
А>>"Потому что не может быть никогда", да?

C>Именно. Читай стандарт.

Стандарт я читал, спасибо. Давненько, правда.

Разговор идет не об абстрактных юникодах в вакууме, а о практическом применении юникода в гуевых фреймворках под Windows.
Посему:
— ваши разглагольствования о красоте линукса немного не в тему;
— в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
— обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
— применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.

Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.

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

Здравствуйте, Аноним, Вы писали:

C>>Разницу между глифом, code point'ом, символом и байтом знаем?

А>Понт защитан.
Невежество атакуе

А>Если речь идет о том, чтобы текст правильно отобразился — это одно.
А>Если же задача состоит в правильном промежуточном преобразовании текста так, чтобы с другой стороны его смогли корректно преобразовать в правильный юникод — это другое.
А>Если задача состоит в том, чтобы текст не превратился в нечитаемый — это совсем третье.

А>Впрочем, раз вы отказываетесь понимать о чем речь — спор становится беспредметным.
Я тоже не понимаю о чем речь. Кто такой "правильный юникод"?

А>Разговор идет не об абстрактных юникодах в вакууме, а о практическом применении юникода в гуевых фреймворках под Windows.
А>Посему:
А>- ваши разглагольствования о красоте линукса немного не в тему;
А>- в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
На винде UTF16 удобнее только тем, что виндовый API его понимает без дополнительных преобразований. Кстати, UTF16 в винде только с Win2000, до этого она понимала только UCS2.

А>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
Это было верно для Unicode 2.0. Потом появились surrogate pairs и привет.

А>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
"хитрый" текст надо отдавать на анализ спец. библиотеке, чтобы она сказала, где строку можно разбивать, а где нельзя. На десктопной винде очевидный выбор — это uniscribe, ScriptStringAnalyse.

Здравствуйте, Аноним, Вы писали:

C>>>>Что зависит?
А>>>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>>>Так понятнее?
C>>Нет.
А>Боюсь, тогда я помочь ничем не смогу.

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

А>>>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>>>Это хороший пример?
C>>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.
А>То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

Совершенно не иллюстрирует. Ибо приведённое решение с произвольной адресацией — кривое.

C>>Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.
А>Я так понимаю, ради этого момента истины вы и затеяли сей беспредметный спор?

Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.

C>>С композитными символами можно побороться нормализацией (со своими проблемами), но вот со сложным начертанием простых способов уже нет. И в обоих случаях нафиг не нужна посимвольная адресация.
А>Опять-таки, зависит от задачи.
Задачи — в студию.

А>Впрочем, раз вы отказываетесь понимать о чем речь — спор становится беспредметным.
Точно, никаких конкретных примеров, одни слова про текстовые редакторы и промежуточные преобразования.

А>>>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.
C>>Ничуть. Всё делается элементарно, даже с UTF-8.
А>Поделитесь сакральным знанием — как же это делается?

Выравнивание по границам символа — примерно 3 строки кода.

C>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
Ну делишь по границам символа тогда.

А>>>Еще раз повторю: там может и не пахнуть правоверным юникодом.
А>>>А значит, разработчики могут кодировать и символы со сложным написанием, и не-ВМР символы как считают нужным. Меня интересует результат.
C>>Так, непонимание Unicode detected.
А>На фоне вашего нарочитого непонимания примеров моя легкая путаница — просто рай.

Так нет примеров-то.

А>Разговор идет не об абстрактных юникодах в вакууме, а о практическом применении юникода в гуевых фреймворках под Windows.
А>Посему:
А>- ваши разглагольствования о красоте линукса немного не в тему;
В тему, как пример правильного использования utf-8.

А>- в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
Какой, (непечатно), win-1251?!?! В виндовых программах нужны ровно _две_ кодировки: UCS-2 и utf-8. Все локальные однобайтовые кодовые страницы — максимум для импорта legacy-данных.

А>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.

А>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.

А>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
Даёт. Хотя бы то, что не надо весь API переделывать.

А>Да, и напоследок: реальные программные проекты не пишутся под сферического клиента в вакууме. В большинстве случаев вполне достаточно поддержки латиницы, западноевропейских языков и (иногда) кириллицы. Языки с RTL написанием или со сложными глифами, скорее всего, потребуют специальной адаптации гуя, а это уже отдельный разговор.
Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.

Здравствуйте, alsemm, Вы писали:

A>Я тоже не понимаю о чем речь. Кто такой "правильный юникод"?

Аналогичный тому, что был на входе.

A>На винде UTF16 удобнее только тем, что виндовый API его понимает без дополнительных преобразований. Кстати, UTF16 в винде только с Win2000, до этого она понимала только UCS2.

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

А>>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
A>Это было верно для Unicode 2.0. Потом появились surrogate pairs и привет.

Внутреннее представление строк в фреймворке (мы ведь все еще о фреймворках, не так ли?) не обязательно должно cjответствовать последнему стандарту Unicode.
Смутно вспоминаю, что в Qt как раз unicode 2.0 в качестве внутренней кодировки, хотя могу и ошибаться.

А>>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
A>"хитрый" текст надо отдавать на анализ спец. библиотеке, чтобы она сказала, где строку можно разбивать, а где нельзя. На десктопной винде очевидный выбор — это uniscribe, ScriptStringAnalyse.

Да.

Здравствуйте, Cyberax, Вы писали:

C>>>>>Что зависит?
А>>>>От задачи зависит, допустимо ли разбиение по разделителям, или же требуется разбиение по печатным символам.
А>>>>Так понятнее?
C>>>Нет.
А>>Боюсь, тогда я помочь ничем не смогу.

C>Т.е. реальных разумных примеров зачем нужна посимвольная произвольная адресация — я так и не увижу, как обычно.

Хе-хе, сколько много требований к примерам. Вы забыли добавить "я должен признать, что пример разумен и реален".

Любой пример можно гордо отвергнуть под предлогом, что он неразумен или нереален.

А>>>>Так вот, если строку порезать посредине символа UTF-8, в большинстве почтовых клиентов заголовок письма отобразится криво.
А>>>>Это хороший пример?
C>>>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.
А>>То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

C>Совершенно не иллюстрирует. Ибо приведённое решение с произвольной адресацией — кривое.

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

Впрочем, для пуритан напомню еще одно: полученная строка не идет на экран напрямую, она пропускается через декодирующую процедуру (которая, кстати, ничего о юникоде не знает — она работает с байтами). К сожалению, декодирование UTF8-заголовков в большинстве реализаций (outlook, thunderbird, были и другие) кривовато и некорректно обрабатывает случаи, когда UTF-8 символ разрезает пополам. Случаи, когда пополам режется surrogate pair, обрабатываются корректно.

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

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

C>>>Учи матчасть: http://en.wikipedia.org/wiki/Complex_scripts и http://en.wikipedia.org/wiki/Unicode#Ready-made_versus_composite_characters Скажем, шрифты с RTL встречаются крайне часто.
А>>Я так понимаю, ради этого момента истины вы и затеяли сей беспредметный спор?

C>Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.

Собственно, я с самого начала писал, что сложная работа с символами требуется не всегда.

C>>>С композитными символами можно побороться нормализацией (со своими проблемами), но вот со сложным начертанием простых способов уже нет. И в обоих случаях нафиг не нужна посимвольная адресация.
А>>Опять-таки, зависит от задачи.
C>Задачи — в студию.

См. выше.
Реальная задача, за решение которой платили разумные деньги.

А>>>>Но при наличии UTF8 она становится нетривиальной и требует или привлечения специальных библиотек, или сакральных знаний о битовом устройстве UTF8.
C>>>Ничуть. Всё делается элементарно, даже с UTF-8.
А>>Поделитесь сакральным знанием — как же это делается?

C>Выравнивание по границам символа — примерно 3 строки кода.

Не могу назвать ваше решение корректным и реальным.

C>>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
C>Ну делишь по границам символа тогда.

Т.е. уже не три строчки, а чуть поболее?

C>Так нет примеров-то.

Примеры есть, но вы старательно делаете вид, что их нет.

А>>- ваши разглагольствования о красоте линукса немного не в тему;
C>В тему, как пример правильного использования utf-8.

Тема, позволю себе напомнить, такова: Best GUI for Windows C++ application
Пример другой операционной системы здесь абсолютно не в тему. Это было бы в тему где-нибудь на форуме, где переписывают Windows под использование utf-8. Я таких, к счастью, не знаю.

А>>- в реальной жизни под виндой UTF8 неудобен именно из-за своей похожести на текст в локальной восьмибитной кодировке, а его использование часто приводит к ошибкам типа "забыли перекодировать в win1251" и "перекодировали дважды";
C>Какой, (непечатно), win-1251?!?! В виндовых программах нужны ровно _две_ кодировки: UCS-2 и utf-8. Все локальные однобайтовые кодовые страницы — максимум для импорта legacy-данных.

А как же UTF-16?

А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?

А>>- обработка строк в формате UTF8 частенько требует знания о формате кодирования в UTF, чтобы можно было хотя бы находить границы символов. При использовании строк а-ля QString или wxString (с многобайтовым представлением символов внутри) границы искать уже не надо;
C>Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.

Пока что это голословное утверждение.
Какие конкретно проблемы мы получаем с RTL?

А>>- применение к любой юникодной кодировке (и utf8 тоже) некоторых алгоритмов приведет к проблемам с символами со сложным написанием. Но универсального решения тут нет — в зависимости от задачи мы или будем резать текст по разделителям слов, или смиримся с вероятностью того, что "хитрый" текст может слегка подпортиться.
C>Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.

Неправда ваша.
Разница есть: применение "тупого" строкового разрезания к utf8-строке дает кривой результат в бОльшем количестве случаев.

А>>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
C>Даёт. Хотя бы то, что не надо весь API переделывать.

Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.

C>Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.
К сожалению, ваше заявление — благое пожелание, и не больше. В реальных проектах, пишущихся в течение нескольких лет, а возможно, и разными программистами, минимальная бдительность с кодировками невозможна. Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.

Здравствуйте, Аноним, Вы писали:

А>>>Боюсь, тогда я помочь ничем не смогу.

C>>Т.е. реальных разумных примеров зачем нужна посимвольная произвольная адресация — я так и не увижу, как обычно.
А>Хе-хе, сколько много требований к примерам. Вы забыли добавить "я должен признать, что пример разумен и реален".

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

Примеров типа: "мне нужно взять десятый символ слева" я могу десятки придумать.

C>>>>Плохой. Так как такой алгоритм не будет работать нормально с арабским. Правильно — это разбить строку на runs по границам слов или глифов.
А>>>То есть для вас приведенный мной пример никак не иллюстрирует проблему разбиения UTF-8 строки?

C>>Совершенно не иллюстрирует. Ибо приведённое решение с произвольной адресацией — кривое.
А>Для забывчивых напомню, что решение приводилось с оговоркой: несущественные детали опущены.
Ага.

А>Впрочем, для пуритан напомню еще одно: полученная строка не идет на экран напрямую, она пропускается через декодирующую процедуру (которая, кстати, ничего о юникоде не знает — она работает с байтами). К сожалению, декодирование UTF8-заголовков в большинстве реализаций (outlook, thunderbird, были и другие) кривовато и некорректно обрабатывает случаи, когда UTF-8 символ разрезает пополам. Случаи, когда пополам режется surrogate pair, обрабатываются корректно.
А при обработке обрезанного символа переключения RTL? Поэтому корректная реализация как раз будет учитывать все сложность Unicode. И там посимвольная адресация будет уже нафиг не нужна.

C>>Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.
А>Собственно, я с самого начала писал, что сложная работа с символами требуется не всегда.
Иногда сойдёт халтура, да.

C>>Задачи — в студию.
А>См. выше.
А>Реальная задача, за решение которой платили разумные деньги.
Переплатили.

C>>>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>>>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
C>>Ну делишь по границам символа тогда.
А>Т.е. уже не три строчки, а чуть поболее?

Ровно 3 строчки. Написать?

C>>Какой, (непечатно), win-1251?!?! В виндовых программах нужны ровно _две_ кодировки: UCS-2 и utf-8. Все локальные однобайтовые кодовые страницы — максимум для импорта legacy-данных.
А>А как же UTF-16?

Да, сорри. Имел в виду именно её.

А>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.

C>>Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.
А>Пока что это голословное утверждение.
А>Какие конкретно проблемы мы получаем с RTL?
Обрезаем символ смены направления — и арабы читают текст слева направо.

C>>Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.
А>Неправда ваша.
А>Разница есть: применение "тупого" строкового разрезания к utf8-строке дает кривой результат в бОльшем количестве случаев.
Разрезание по токенам из ASCII — всегда корректно.

А>>>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
C>>Даёт. Хотя бы то, что не надо весь API переделывать.
А>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
Второе.

C>>Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.
А>К сожалению, ваше заявление — благое пожелание, и не больше. В реальных проектах, пишущихся в течение нескольких лет, а возможно, и разными программистами, минимальная бдительность с кодировками невозможна.
Ещё как возможна. И как раз использование utf-8 этому очень способствует.

А>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?

Здравствуйте, Cyberax, Вы писали:

C>Примеров типа: "мне нужно взять десятый символ слева" я могу десятки придумать.

Отлично.

А>>Впрочем, для пуритан напомню еще одно: полученная строка не идет на экран напрямую, она пропускается через декодирующую процедуру (которая, кстати, ничего о юникоде не знает — она работает с байтами). К сожалению, декодирование UTF8-заголовков в большинстве реализаций (outlook, thunderbird, были и другие) кривовато и некорректно обрабатывает случаи, когда UTF-8 символ разрезает пополам. Случаи, когда пополам режется surrogate pair, обрабатываются корректно.

C>А при обработке обрезанного символа переключения RTL?

Ошибка возникает при декодировании кусочков строки из base64. Обрезания не возникает, если utf-8 символ не порезан пополам (потому как кусочки строки потом соединяются, и "обрезки" прекрасно сливаются).
Посему при обработке символа переключения RTL ничего необычного не случится.

C> Поэтому корректная реализация как раз будет учитывать все сложность Unicode. И там посимвольная адресация будет уже нафиг не нужна.

Да-да, конечно-конечно.

C>>>Собственно, я с самого начала писал, что с символами вообще всё не так уж просто.
А>>Собственно, я с самого начала писал, что сложная работа с символами требуется не всегда.
C>Иногда сойдёт халтура, да.

Иногда это зависит не от нас.

C>>>Задачи — в студию.
А>>См. выше.
А>>Реальная задача, за решение которой платили разумные деньги.
C>Переплатили.

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

C>>>>>Ну так делим по границе слов (по пробелам, запятым и т.п.) и вставляем crlf. Будет прекрасно работать с utf-8.
А>>>>Пока не встретится строка длиной этак в пару килобайт без пробелов, запятых и т. п. А встретится она буквально сразу же — бывали-с случаи.
C>>>Ну делишь по границам символа тогда.
А>>Т.е. уже не три строчки, а чуть поболее?

C>Ровно 3 строчки. Написать?

Конечно.

А>>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
C>Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.

Под виндой зачастую оказывается, что в ASCII-строчке — не utf8, а локальная кодировка.

C>>>Нужно. Иначе получаем проблемы с RTL и прочими товарищами. То что ты их не видишь — это просто тебе везёт.
А>>Пока что это голословное утверждение.
А>>Какие конкретно проблемы мы получаем с RTL?
C>Обрезаем символ смены направления — и арабы читают текст слева направо.

Пример надуманный.

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

C>>>Естественно. Поэтому и нет разницы utf-8 или ucs-2/4.
А>>Неправда ваша.
А>>Разница есть: применение "тупого" строкового разрезания к utf8-строке дает кривой результат в бОльшем количестве случаев.
C>Разрезание по токенам из ASCII — всегда корректно.

Но как мы уже выяснили — не является универсальным методом, а зависит от задачи и от того, что именно мы режем.

А>>>>Итого: utf-8 не дает никаких преимуществ по сравнению с многобайтовыми строками, но имеет пару специфических проблем.
C>>>Даёт. Хотя бы то, что не надо весь API переделывать.
А>>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
C>Второе.

А то, что старые API периодически выдают строки в странной не-utf8 кодировке, вас не смущает?

C>>>Минимальная бдительность с кодировками (и отсутствие тупоголовых решений типа "обрежем по 80-ти байтам") позволяет делать приложения для 99% языков.
А>>К сожалению, ваше заявление — благое пожелание, и не больше. В реальных проектах, пишущихся в течение нескольких лет, а возможно, и разными программистами, минимальная бдительность с кодировками невозможна.
C>Ещё как возможна. И как раз использование utf-8 этому очень способствует.

Голословное утверждение номер 2.

А>>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
C>Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?

Дык — нативный API, который вы сохраняете, работает под виндовсом именно с однобайтовыми кодировками, зависящими от дефолтной локали винды.

А кодировок не обязательно будет много. В пределах программы их может быть всего две (utf8 и ANSI), но на разных региональных вариантах винды кодовая страница будет в этом ANSI разная.

Виндовс — в морг, всем срочно ставить линукс, и вопрос переименовать в "Best GUI for Linux C++ application"? Я вас правильно понимаю?

Здравствуйте, Аноним, Вы писали:

A>>На винде UTF16 удобнее только тем, что виндовый API его понимает без дополнительных преобразований. Кстати, UTF16 в винде только с Win2000, до этого она понимала только UCS2.

А>Внутреннее представление строк в фреймворке (мы ведь все еще о фреймворках, не так ли?) не обязательно должно быть UTF16.
Выбор-то невелик — UTF8, UTF16, или UTF32.

А>Смутно вспоминаю, что в Qt как раз unicode 2.0 в качестве внутренней кодировки, хотя могу и ошибаться.
unicode — это не кодировка.

Здравствуйте, Аноним, Вы писали:

C>>А при обработке обрезанного символа переключения RTL?
А>Ошибка возникает при декодировании кусочков строки из base64. Обрезания не возникает, если utf-8 символ не порезан пополам (потому как кусочки строки потом соединяются, и "обрезки" прекрасно сливаются).
А>Посему при обработке символа переключения RTL ничего необычного не случится.
А ты попробуй.

А>>>Т.е. уже не три строчки, а чуть поболее?

C>>Ровно 3 строчки. Написать?
А>Конечно.
А лень

А>>>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
C>>Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.
А>Под виндой зачастую оказывается, что в ASCII-строчке — не utf8, а локальная кодировка.
Это надо очень постараться при минимальной гигиене.

C>>Обрезаем символ смены направления — и арабы читают текст слева направо.
А>Пример надуманный.

А>Символ смены направления обычно находится в начале строки, а не в середине.
Ну мы же можем и с начала обрезать.

А>>>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
C>>Второе.
А>А то, что старые API периодически выдают строки в странной не-utf8 кодировке, вас не смущает?

Какие именно?

А>>>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
C>>Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?
А>Дык — нативный API, который вы сохраняете, работает под виндовсом именно с однобайтовыми кодировками, зависящими от дефолтной локали винды.

Неа. В Винде нынче весь API есть в wide-варианте (Win98 уже не считаем), так что никто не мешает делать преобразование сразу же в utf-8 после получения результата из API.

Здравствуйте, Cyberax, Вы писали:

C>>>А при обработке обрезанного символа переключения RTL?
А>>Ошибка возникает при декодировании кусочков строки из base64. Обрезания не возникает, если utf-8 символ не порезан пополам (потому как кусочки строки потом соединяются, и "обрезки" прекрасно сливаются).
А>>Посему при обработке символа переключения RTL ничего необычного не случится.
C>А ты попробуй.

А лень

А>>>>Т.е. уже не три строчки, а чуть поболее?

C>>>Ровно 3 строчки. Написать?
А>>Конечно.
C>А лень

Что еще раз подтверждает цель вашего визита в тему.

На том и порешим.

А>>>>А как же неизменность API, о которой вы рассуждаете двумя абзацами ниже?
C>>>Внутреннего API. Конверсию в UTF-16 можно делать в самый момент вызова системных API.
А>>Под виндой зачастую оказывается, что в ASCII-строчке — не utf8, а локальная кодировка.
C>Это надо очень постараться при минимальной гигиене.

К сожалению, реальность несколько отличается от вашего идеализированного представления о гигиене.

C>>>Обрезаем символ смены направления — и арабы читают текст слева направо.
А>>Пример надуманный.

А>>Символ смены направления обычно находится в начале строки, а не в середине.
C>Ну мы же можем и с начала обрезать.

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

А>>>>Вы уж определитесь: или мы все срочно пишем только в UCS2, или таки сохраняем старые API и оперируем ~~горячими заку~~ ASCIIZ-строками.
C>>>Второе.
А>>А то, что старые API периодически выдают строки в странной не-utf8 кодировке, вас не смущает?

C>Какие именно?

Посмотрите сами, какие API возвращают ASCIIZ строки в операционной системе windows.

А>>>>Тут спасает только несовместимость строк на уровне компилятора (char* в wxString не скопируешь — придется преобразовывать осознанно). Если в программе везде используются строки char*, а кодировок больше одной — тушите свет, обязательно откуда-нибудь просочится строчка в неожиданной кодировке.
C>>>Более одной кодировки => в морг. Нафиг однобайтовые кодовые страницы-то?!?
А>>Дык — нативный API, который вы сохраняете, работает под виндовсом именно с однобайтовыми кодировками, зависящими от дефолтной локали винды.

C>Неа. В Винде нынче весь API есть в wide-варианте (Win98 уже не считаем), так что никто не мешает делать преобразование сразу же в utf-8 после получения результата из API.
Неа. В винде нынче весь API есть в ASCII-варианте, о чем, собственно, и ведется речь.

	От:	alsemm
	Дата:	19.10.10 17:05
	Оценка:

	От:	Cyberax
	Дата:	19.10.10 17:15
	Оценка:

	От:	Аноним
	Дата:	20.10.10 07:34
	Оценка:

	От:	Cyberax
	Дата:	20.10.10 08:28
	Оценка:

	От:	Аноним
	Дата:	20.10.10 09:55
	Оценка: