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

[xdsl]

5. В большинстве современных программ имеем целочисленные переменные типа Integer (32 бита), иногда int64. Хотя во многих случаях для экономии памяти нам бы по алгоритму хватило SmallInt или ShortInt. Но редкий извращенец экономит таким образом оперативную память под переменные. Тип Integer даже работать будет быстрее на современном проце. Но в строковых переменных полный изврат и маразм, все очень любят тип UTF8, в котором во впервых 8-битный элемент (что уже замедляет работу), так и символы переменной длины, и нужно делать полный парсинг для любой строковой операции. Сколько ни смотрел в инете, ни где не видел разумного объяснения в необходимости строковых переменных с типом UTF8 (не путать с форматом файла на диске).
...

Ничего-так заявление. Было на символ от 1 до 4 байт, а теперь без вариантов - 4 байта. Особо шикарными станут массивы и строки.

Я уже выше писал про целочисленные типы SmallInt или ShortInt. Для вещественных переменных есть тип Single (float по сишному). И кто из современников часто использует данные типы? И почему никого не напрягает 32-битная переменная в цикле for?

Вы вообще понимаете что на хранение в ОЗУ массива из миллиона символов вы предлагает тратить четыре миллиона байт? Вы понимаете, что считывая файл не кодировке utf32 с диска, Вы предлагает каждый символ преобразовывать к четырехбайтному представлению, и делать обратное преобразование при его сохранении? Вы понимаете, СКОЛЬКО Вам придется тратить памяти и ресурсов процессора на банальную потоковую обработку?

После чехарды с разнокодироваными текстами в cp866, cp1251 и koi8-r лично я, русскоязычный, воспринял utf8 как манну небесную.

Полумеры они и в Африке полумеры. А utf8 внес не менее сумбура и хаотичности, тем более файлы на диске в формате UTF8 редко когда содержат в первых символах признак формата UTF8, т.е. как была чехарда с разнокодироваными текстами в cp866, cp1251 и koi8-r, так она и осталась. Открываете файл и не знаете в какой он кодировке, то ли UTF8, то ли cp1251, то ли cp866 и т.п.

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

А по поводу utf-16... много Вы видели текстов программ, кодированных в utf-16, шоб по два байта на символ? Не желаете заняться переводом своих программ в utf-16? Или в utf32?

Большая часть моих проектов реализована и работает под Дельфями. Там в базе utf-16. Программы уже давно переведены на utf-16, и перевод занял так мало времени, т.к. пришлось переработать только собственную строковую библиотеку. В ФПС и Лазаре - уникод был введен совсем неразумно. В Дельфях много лет назад появился WideString и ни каких проблем не было. Затем был введен UnicodeString и опять ни каких проблем. Все гладко

При чем тут типы данных и строковые библиотеки? Я говорил о текстах программ.

[alexey38]

Вы вообще понимаете что на хранение в ОЗУ массива из миллиона символов вы предлагает тратить четыре миллиона байт? Вы понимаете, что считывая файл не кодировке utf32 с диска, Вы предлагает каждый символ преобразовывать к четырехбайтному представлению, и делать обратное преобразование при его сохранении? Вы понимаете, СКОЛЬКО Вам придется тратить памяти и ресурсов процессора на банальную потоковую обработку?

4 миллиона символов - это всего 4 Мб ОЗУ. У меня на одном компе 4 Гб, а на другом 32 Гб. Даже на смарте и то довольно много Мб ОЗУ. Так что в части памяти ОЗУ - это вообще не проблема.

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

Если у Вас файл 100 Гб, то Вы его разом все равно не прочитаете ни в UTF8, ни в UTF16, ни UTF32. Для таких задач другие алгоритмы.

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

При чем тут типы данных и строковые библиотеки? Я говорил о текстах программ.

Какая разница в каком формате на диске хранится текст программы. Да хоть в формате MS Word. В Дельфях сделано по умному, там формат строковых констант соответствует либо Unicode (UTF-16), либо явно заданному типу строковой типизированной константы. Формат файла с текстом программы не влияет на формат строковой константы во время исполнения программы.

А вот конкретно у FPC и Лазаря там все наоборот по извратному. Тут формат текста программы непонятно для чего определяет формат строковой константы во время исполнения программы. Для чего так сделали - непонятно. Если компилятор не может определить тип, он должен был просто выдавать ошибку компиляции с требованием в опциях указать тип. Но кто-то извратился и решил, что формат файла с текстом якобы должен определять и влиять на алгоритм работы программы.

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

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

У меня ни когда не было чехарды при работе с моими файлами. В том числе до появления Unicode. Чехарда возникала когда нужно было в программе обработать чужой файл. Дали файл, но не сказали в какой он кодировке. utf8 - тут также плох, т.к. многие чужие файлы в utf8 не имеют признака в виде первых байт. Кроме магии, нет других способов понять, что чужой файл именно в utf8, а не в cp1251.

Добавлено спустя 5 минут 8 секунд:
У меня есть реальная задача, где суточный объем данных в развернутом виде около 32 Гб. А мне нужно обрабатывать примерно 3-5 лет. Для хранения данных мне даже СУБД не подходит, т.к. в несжатом виде мне нужно около 60 Тб места. Поэтому еще довольно давно перешел на фрагментированное хранение данных в файлах в формате 7z. Разворачиваю в ОЗУ только узкий фрагмент данных, обрабатываю, освобождаю память и пошел дальше.

[SeZuka]

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

Кстати как скормить FPC исходник в UTF-16? Компилятор сразу ругается на первые символы в файле.

[hovadur]

Так какой недостаток у UTF-8? В том, что строковые функции получаются сложными? Так написали уже один раз, добрые ребята из lazarus или delphi. Пользуйся ими и хватай руками вдохновенье.
А недостатки UTF-16 и UTF-32 так просто не уберешь.
Резюмирую опять:
1) Недостаток UTF-16: 2 байт не всегда хватает, иногда нужно 4, невозможно избавиться.
2) Недостаток UTF-32: слишком большие объемы, невозможно избавиться.
3) Недостаток UTF-8: слишком сложные строковые функции, возможно избавиться. Возможно написать их один раз, написать к ним тестов, и пользоваться ими.

[SeZuka]

Резюмирую опять:
1) Недостаток UTF-16: 2 байт не всегда хватает, иногда нужно 4, невозможно избавиться.
2) Недостаток UTF-32: слишком большие объемы, невозможно избавиться.

3) Недостаток UTF-8: 1 байта не всегда хватает, иногда нужно 6, невозможно избавиться! слишком сложные строковые функции, не возможно избавиться. Ну напишите вы их один раз, и что с того, процессору от этого легче не станет от их обработки каждый раз.

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

[hovadur]

3) Недостаток UTF-8: 1 байта не всегда хватает, иногда нужно 6

так с помощью UTF-8 как раз и можно отобразить сколько угодно байт: 1, 2, 4, 6. Не знаю, почему он назван именно UTF-8, но с помощью его можно отобразить хоть 6 байт.

Так что забудьте вы об 1 байте для UTF-8, это не для нас!

Еще раз, UTF-8 - не 1 байт. Так как

Символы, закодированные в UTF-8, могут быть длиной до шести байт

[SeZuka]

Не знаю, почему он назван именно UTF-8, но с помощью его можно отобразить хоть 6 байт

Поправочка, можно отобразить 1 символ, который будет занимать до 6 байт в памяти.

Еще раз, UTF-8 - не 1 байт.

А от 1 до 6. Так в чем тогда преимущество перед UTF-16??? Ни в чем, только одни недостатки!
А как эта кодировка нравится самым многочисленным нациям индийцам и китайцам, у которых все символы буду по 3 байта, а то и 4

[xdsl]

А можно заархивировать и прикрепить исходный код простейшего проекта для Delphi XE2 или XE3. Последняя версия Delphi, с которой я работал, была Delphi 7, и там была обычная cp1251, ужели в XE2-3 перевели исходники на utf-16?

[hovadur]

Так в чем тогда преимущество перед UTF-16?

В том, что UTF-8 может работать с индийцами и китайцами, тогда как с UTF-16 у них могут быть проблемы.

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

А можно заархивировать и прикрепить исходный код простейшего проекта для Delphi XE2 или XE3

Пожалуйста

testxe2.zip

ужели в XE2-3 перевели исходники на utf-16?

Нет, файлы сохраняются все равно в Ansi.

[xdsl]

Нет, файлы сохраняются все равно в Ansi.

Посмотрел архив, действительно, как было cp-1251, так и сталось, никакого UTF-16. А то я уж подумал, на фоне заявлений alexey38, что в эмбаркадэро совсем головой поехали.

[alexs]

В чём сыр-бор?
Lazarus работает нормально с UTF8. Проблем нет.
Просто не забывайте использовать UTF8Copy вместо Copy (ну и прочие аналоги) - и всё работает.
И ещё - при обработке текста в UTF8 не надо использовать методики от моноширинных кодировок. Для UTF8 всё ж есть свои особенности алгоритмов, и если им следовать - то всё будет нормально.

[alexey38]

А можно заархивировать и прикрепить исходный код простейшего проекта для Delphi XE2 или XE3. Последняя версия Delphi, с которой я работал, была Delphi 7, и там была обычная cp1251, ужели в XE2-3 перевели исходники на utf-16?

В Delphi можно для каждого файла исходника выбрать и переконвертировать прямо из среды RAD Studio: ANSI, UTF8, UTF-16 (BE, LE), UTF-32 (BE, LE). Храните исходники так, как именно ВАМ нравится. Алгоритм работы программы от этого не меняется. Строковый тип в программе по умолчанию String=UnicodeString=UTF-16.

Добавлено спустя 9 минут 19 секунд:
Еще раз. Файл на диске можно хранить как угодно: в UTF-8, UTF-16. UTF-32, можно его поверх заархивировать 7z, zip или другими, в этом случае на диске все будет очень компактно.

Теперь про типы данных во время выполнения программы.

3) Недостаток UTF-8: слишком сложные строковые функции, возможно избавиться. Возможно написать их один раз, написать к ним тестов, и пользоваться ими.

а) Неустранимый и постоянно встречающийся недостаток - это переменная длина памяти под символ на любом языке, кроме английского.
б) Неустранимый недостаток - непомерно медленные алгоритмы работы со строками, т.к. наиболее часто встречающаяся операция индексации к символу требует огромных трудозатрат процессора.
в) Мнимое преимущество в более компактном хранении строки в оперативной памяти, делает невозможным его использование для реальных задач с большим объемом строк. Если строка на 1000 символов, то потенциальная экономия ОЗУ до 3 Кб не играет ни какой роли, это даже не смешно. Если строки в десятки, сотни Мб, в Гб, то экономия места в ОЗУ уже заметна, но чрезвычайно медленные алгоритмы не позволяют использовать UTF-8 на практике. Даже покупка самого мощного и дорогого процессора не покрывает потерю быстродействия.

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

1) Недостаток UTF-16: 2 байт не всегда хватает, иногда нужно 4, невозможно избавиться.

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

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

2) Недостаток UTF-32: слишком большие объемы, невозможно избавиться.

Идеальный тип данных для строковых переменных и без недостатков. Для коротких строк излишки памяти незаметны, как незаметен перерасход памяти в переменной цикла integer (4 байта). Для процессоров идет отработка 32 битными словами, что не замедляет, а скорее ускоряет работу на современных процессорах. При обработке длинных строк - это единственный тип строк с UNICODE, который обеспечивает приемлемое быстродействие. В крайнем случае можно для компа купить оперативной памяти в 2-4 раза больше. Но быстродействие реальных задач увеличится как минимум на порядок, а для некоторых задач на несколько порядков. У нас нет возможности покупать процы в 10 раз более быстрые. Даже Extrem Edition уже неразумно дороги, но дают прирост производительности на 10-20%.

[SeZuka]

В чём сыр-бор?

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

[bormant]

UTF-8 -- это транспортная кодировка, все ее достоинства являются достоинствами применительно к передаче текстов (в том числе между little/medium/big endian системами). Если кроме обычной передачи текста требуется обработка с посимвольным перебором (кроме сортировки и поиска подстроки), преобразуйте UTF-8 при получении сразу в ту кодировку, в которой будете проводить обработку (UTF-32/UTF-16/UCS2/CP1251/CP866/KOI8-R/ISO8859-5/...). Преобразовывать обратно в UTF-8 только при сохранении вовне, когда при этом требуется UTF-8. Только и всего.

[xdsl]

В Delphi можно для каждого файла исходника выбрать и переконвертировать прямо из среды RAD Studio: ANSI, UTF8, UTF-16 (BE, LE), UTF-32 (BE, LE). Храните исходники так, как именно ВАМ нравится. Алгоритм работы программы от этого не меняется. Строковый тип в программе по умолчанию String=UnicodeString=UTF-16.

Уважаемый, давайте уже меньше слов - больше кода. Исходника проекта от Вас нет, в исходнике от hovadur имеем
Project1.dpr, Unit1.fmx, Unit1.pas - в cp1251,
Project1.dproj, Project1.dproj.local - в utf8
Project1.identcache - бинарный формат