Забавный но досадный глюк

[xdsl]

Честно говоря, меня утомили ЧСВ и графомания уважаемого alexey38. Подожду, пока эмбаркадеро и майкрософт свои сайты с utа-8 на utf-16 или utf-32 переведут. А пока - до свидания, наскучило...

[hovadur]

А ведь в самом деле у utf-16 переменная длина символа, может быть 2 или 4 байта. Тогда теряется основное преимущество перед UTF-8 - легкость разработки строковых функций. Что на это скажешь alexey38?

[SSerge]

Коллеги, речь о какой либо эффективности кодировок можно было вести в 90-х. Сейчас же, когда с кодировками принято работать исключительно на уровне библиотек, получивших принадлежность операционной системе, остаётся констатировать, что какую бы кодировку вы не применили, она будет однозначно неэффективной. Особенно в том, что касается операций упорядочивания символов, зависящих от локалей ОС.

Кстати, ничего, что сами по себе строковые типы в нынешней реализации паскаля являются категорически неэффективными?

Мало того, что обладают всеми недостатками Си-шных ASCIIZ строк - де не содержат текущей длины, являются указателями и т.п., так еще появляется знаменитая генерация побочных строковых объектов при присвоениях, обходя которую, надо творить, гм, отвратительный и нечитабельный код. Не знаю, как там луч поноса в сторону создателя UTF8, а вот в сторону автора реализации AnsiString в дельфи - определенно не мешало бы. Ну а если задуматься над тем, что сейчас в дельфи уже каждая строка имеет индивидуальный признак кодировки и все присвоения повлекут за собой по минимуму сравнение соответствий кодировок, а по максимуму - постоянную неявную конверсию из одной кодировки в другую, так строки будут еще более неэффективными. И тут будет. Точнее, уже есть, только все предпочитают не замечать

[alexey38]

Честно говоря, меня утомили ЧСВ и графомания уважаемого alexey38. Подожду, пока эмбаркадеро и майкрософт свои сайты с utа-8 на utf-16 или utf-32 переведут. А пока - до свидания, наскучило...

Когда нечего возразить по существу, то в ход идут такие аргументы, как наскучило.

Добавлено спустя 4 минуты 28 секунд:

А ведь в самом деле у utf-16 переменная длина символа, может быть 2 или 4 байта. Тогда теряется основное преимущество перед UTF-8 - легкость разработки строковых функций. Что на это скажешь alexey38?

Перечитайте тему с самого начала, там об этом уже говорилось. Если кратко, то именно UTF-32 самый оптимальный, в части алгоритмов строковых обработок. Работая с UTF-16 конкретно с русским языком, можно при необходимости реализовать строковые функции, не учитывающие 4-х байтовые символы. Это не универсально, но работоспособно. UTF-8 для русскоязычных задач очень плох.

Добавлено спустя 2 минуты 23 секунды:

Коллеги, речь о какой либо эффективности кодировок можно было вести в 90-х. Сейчас же, когда с кодировками принято работать исключительно на уровне библиотек, получивших принадлежность операционной системе, остаётся констатировать, что какую бы кодировку вы не применили, она будет однозначно неэффективной. Особенно в том, что касается операций упорядочивания символов, зависящих от локалей ОС.

Можно работать как через библиотеки ОС, так и без библиотек ОС. 100% совместимый уникод действительно через библиотеки ОС. Но для реальных задач это редко нужно, в основном когда идет смена регистра букв.

Добавлено спустя 5 минут 47 секунд:

Мало того, что обладают всеми недостатками Си-шных ASCIIZ строк - де не содержат текущей длины, являются указателями и т.п., так еще появляется знаменитая генерация побочных строковых объектов при присвоениях, обходя которую, надо творить, гм, отвратительный и нечитабельный код. Не знаю, как там луч поноса в сторону создателя UTF8, а вот в сторону автора реализации AnsiString в дельфи - определенно не мешало бы. Ну а если задуматься над тем, что сейчас в дельфи уже каждая строка имеет индивидуальный признак кодировки и все присвоения повлекут за собой по минимуму сравнение соответствий кодировок, а по максимуму - постоянную неявную конверсию из одной кодировки в другую, так строки будут еще более неэффективными. И тут будет. Точнее, уже есть, только все предпочитают не замечать

С уникодовскими строками есть хитрости - это заложено самим стандартом уникода. Неоптимальности на уровне UTF-32 особой нет, там по структуре все однозначно. В UTF-16 неоднозначность есть, но не для русского языка. В UTF-8 неоднозначность есть. AnsiString в дельфи это не уникод. В Дельфи уникод - UnicodeString. Формат структуры этого типа довольно универсален, но по факту в Дельфях есть только UTF-16, как тип строк, соответственно нет ни каких конвертаций. Именно эта сторона Дельфей лучше продумана, чем в ФПС и Лазаре. Поэтому в Дельфях формат файла с исходником не влияет на кодировку в переменной и строковой константе.

[hovadur]

Перечитайте тему с самого начала, там об этом уже говорилось. Если кратко, то именно UTF-32 самый оптимальный, в части алгоритмов строковых обработок. Работая с UTF-16 конкретно с русским языком, можно при необходимости реализовать строковые функции, не учитывающие 4-х байтовые символы. Это не универсально, но работоспособно. UTF-8 для русскоязычных задач очень плох.

То есть ты согласен, что UTF-16 тоже плох, как и UTF-8, с точки зрения реализации строковых функций?

[alexey38]

То есть ты согласен, что UTF-16 тоже плох, как и UTF-8, с точки зрения реализации строковых функций?

Конечно согласен. Но для русского языка через "костыли" можно реализовать быструю строковую библиотеку под UTF-16, а для UTF-8 даже с "костылями" не получится. Нормальный формат - это UTF-32.
Кроме того, у файлов с UTF-8 обычно не указан BOM, и если специально в программе не указать, что программа может считать файл, не как уникод, а как 8-битный в формате текущей локали.

[hovadur]

Конечно согласен.

Тогда получается, что UTF-8 лучше, чем UTF-16, так как у UTF-8 есть совместимость с ASCII-символами. Даже у UTF-8 с BOM есть совместимость с ASCII-символами.

[alexey38]

Тогда получается, что UTF-8 лучше, чем UTF-16, так как у UTF-8 есть совместимость с ASCII-символами. Даже у UTF-8 с BOM есть совместимость с ASCII-символами.

Как строковый тип переменных в языке UTF-8 - самый плохой тип, т.к. экономия памяти для современных систем не существенна, а снижение производительности серьезное и заметное. Ни какие "костыли" не помогут.
Как формат текстовых файлов на диске UTF-8 - тоже плох, т.к. он совместим с ASCII, ANSI и т.п. только в части первых символов (английский алфавит). Поэтому можно говорить о совместимости только для англоязычного текста (ради чего и был допущен UTF-8 без BOM). Русскоязычный текст в UTF-8 не совместим с ASCII, ANSI и т.п. Это серьезный недостаток. Вы пишите программу, но не можете дать гарантию ее работоспособности. Это даже не костыль, это явный баг. UTF-16 и UTF-32 без BOM не бывает, так что Ваша программа будет однозначно работать верно

[dunin]

Мдя... В теме "Почему не надо программировать на дельфи" подробно историю СССР и жидо-массонский заговор обсудили, в теме про "Чучхе в действии" незаменимость IT специалистов, в теме про "Забавный и досадный глюк" перспективы кодировки UTF-8...

Может голосовалку прикрутить?
Я за UTF-8

[alexey38]

в теме про "Забавный и досадный глюк" перспективы кодировки UTF-8...

Потому, что глюк был связан с кодировкой UTF-8, точнее с тем, что ФПС и Лазарь дает возможность использовать ANSI-шные функции, для строк в кодировке UTF-8. Аналогичный код в Дельфях не глючит, т.к. там для уникодовских строк вызываются уникодовские функции, имеющие перегрузку для двух типов строк. Если посмотреть на историю данного форума, то глюков с UTF-8 было очень много, что говорит о реальном наличии проблем. Там, где хорошо все продуманно, там проблемы не возникают, т.к. они выявляются на уровне ошибок компиляции.

Как гениально хороши были паскалевские строки, которые и со счетчиком ссылок, и с длинною строки. Можно сказать, была идеальная реализация. Появился Уникод - и все пошло не так, и пошли массовые косяки, и резкое падение быстродействия, и необходимость замены проверенных временем алгоритмов и т.д. Вместо того, чтобы признать, что и сама паскалевская реализация (ФПС и Лезерь) не самая удачная, и сами кодировки оказались сложны в обработке, да не редко встречаются ошибки конвертации, так вот некоторые голословно утверждают, что якобы проблем нет. Как нет, если многие об этом говорят. Если реальные замеры быстродействия показывают замедление работы программ на порядки. Есть проблемы.

Добавлено спустя 2 минуты 41 секунду:

Я за UTF-8

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

[hovadur]

Как строковый тип переменных в языке UTF-8 - самый плохой тип

но ведь UTF-16 еще хуже, так как у него нет совместимости даже с ASCII-символами. Ведь так?

[alexey38]

но ведь UTF-16 еще хуже, так как у него нет совместимости даже с ASCII-символами. Ведь так?

Отсутствие бинарной совместимости UTF-16 и ASCII является преимуществом, а не недостатком UTF-16. Зато существует однозначная логическая совместимость ASCII-символов и UTF-16.
UTF-8 точно также не имеет бинарной совместимости с ASCII-символами в полном объеме, она у него существует для нескольких символов. При этом отсутствует возможность однозначной идентификации файла в формате UTF-8, в виду необязательности BOM .
Нельзя быть немножко беременной, так и здесь, либо совместим на 100%, либо тогда несовместим. UTF-8 не совместим с ASCII-символами - это наиболее точное определение.

[hovadur]

UTF-8 не совместим с ASCII-символами - это наиболее точное определение.

Не понял, ведь ASCII-символы - это 1 байт.
Вот есть файл:

Код: Выделить всё

Section=Auto


Сохраняя этот файл в формате UTF-8, я могу открыть его любой программой, в том числе и не понимающей ни UTF-8, ни UTF-16.
А сохраняя его в UTF-16, я уже не открою его программой, не понимающей UTF-16.
Вот так я понимаю совместимость c ASCII-символами.
Поэтому, говорить, что

UTF-8 не совместим с ASCII-символами - это наиболее точное определение.

неверно.

Добавлено спустя 1 минуту 20 секунд:
поэтому я еще раз спрашиваю, ведь UTF-16 еще хуже, так как у него нет совместимости даже с ASCII-символами. Ведь так?

[alexey38]

Не понял, ведь ASCII-символы - это 1 байт.

В UTF-8 любой символ кодируется от 1 до 6 ASCII-символами (1-6 байт), Вы это считаете понятием совместимости? В UTF-16 точно также любой символ кодируется либо двумя ASCII-символами (2-мя байтами), либо 4-мя ASCII-символами (4-мя байтами). Пользуясь Вашей логикой UTF-16 тоже совместим с ASCII-символами.

[runewalsh]

Кстати, ничего, что сами по себе строковые типы в нынешней реализации паскаля являются категорически неэффективными?
Мало того, что обладают всеми недостатками Си-шных ASCIIZ строк - де не содержат текущей длины, являются указателями и т.п.

Доброе утро, теоретик. AnsiString и его родственники хранят длину по отрицательному смещению. Внезапно, да?
А информацию о кодировке несёт тип переменной, т. е. все преобразования известны во время компиляции.