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

[alexey38]

Уважаемый, давайте уже меньше слов - больше кода. Исходника проекта от Вас нет, в исходнике от hovadur имеем

Зачем код? Есть перечень функций в локальном меню:

Безымянный.png

[xdsl]

Вам очень сложно выложить архив простейшего проекта, как это сделал hovadur?

[alexey38]

UTF-8 -- это транспортная кодировка, все ее достоинства являются достоинствами применительно к передаче текстов (в том числе между little/medium/big endian системами).

Как транспортная кодировка, UTF-8 имеет слишком большой размер файла, например, кирилистический текст будет занимать столько же, как и UTF-16. Для транспорта удобнее использовать форматы типа zip, 7z.
Применительно к передаче текстов между little/medium/big endian системами файлы с UTF-8 имеют огромный недостаток, они по халатности и ленности многих юникосидов не имеют BOM-сигнатуры, соответственно кроме латинских букв и цифр вообще непонятно, что за символы там присутствуют, и какая там структура в 16 и 32 битных слов.

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

Вам очень сложно выложить архив простейшего проекта, как это сделал hovadur?

Мне лень создавать 6 вариантов проектов, чтобы проиллюстрировать возможность работы Дельфи в любой из этих кодировок. Интересует - скачайте Дальфи (например, триал) и испытайте его в интересуемом Вас объеме.
Пример исходника в UTF-16:

Безымянный1.png

[bormant]

zip, 7z

Варианты компрессии кодировкам ортогональны, не надо ещё и их сюда мешать.

не имеют BOM

Для UTF-8 BOM не нужен, хоть и возможен, плюсом является автосинхронизация последовательности при потере фрагментов. А вот UTF-16/32 этого свойства лишены.

[xdsl]

to alexey38. В чем проблема, не далее как на предыдущей странице Вы утверждали, что у Вас все программы переведены на utf-16 (http://freepascal.ru/forum/viewtopic.php?p=71431#p71431):

Программы уже давно переведены на utf-16

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

А картинки я и сам могу показывать, и это ни о чем не скажет:

graf1.png

[alexey38]

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

Реальные проекты на Дельфях - это не opensource, и не труд меня, как одного человека. У меня нет просто юридических и моральных прав выкладывать реальные проекты в свободный доступ.
На картинке я Вам наглядно показал, что файл в UTF-16. Создавать тестовые проекты Вы можете сами. Мне непонятно Ваше упорное нежелание скачать триал-версию Дельфи и удовлетворить собственное любопытство в полном объеме. Мне непонятно, для чего я должен создавать и выкладывать фиктивные проекты, и кому это нужно.

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

Варианты компрессии кодировкам ортогональны, не надо ещё и их сюда мешать.

А UTF-8 разве не является вариантом компрессии для UTF-32? Это один из самых простых способов архивации, известный с давних времен, еще с больших ЭВМ.

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

Для UTF-8 BOM не нужен, хоть и возможен, плюсом является автосинхронизация последовательности при потере фрагментов. А вот UTF-16/32 этого свойства лишены.

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

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

А картинки я и сам могу показывать, и это ни о чем не скажет:

А что скажет или что покажет этот же самый текст Project1.lpr не в виде картинки, а в виде файла? Это что ли по Вашему иллюстрирует работоспособность компилятора или среды разработки при работе с файлами в разных кодировках?

[bormant]

один из самых простых способов архивации, известный с давних времен, еще с больших ЭВМ

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

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

BOM нужен, чтобы отличить файл в UTF-8 от файла в ANSI, ASCII и других кодировках

BOM нужен немного для другого -- для определения варианта endian -- little/medium/big, когда размер единичного элемента больше 1 байта, а в UTF-8 BOM всё тот же code point U+FEFF, который после кодирования в UTF-8 выглядит как $ef, $bb, $bf. Речь о другой синхронизации -- несмотря на переменное количество байт в символе, неполное представление одного символа нельзя спутать с другим символом.

[xdsl]

alexey38, Talk is cheap. Show me the code (Torvalds, Linus, 2000-08-25)

Я понял, что кода от Вас не будет и подтверждать свои утверждения вы не собираетесь. Учту на будущее, чтобы не реагировать в дальнейшем на Ваш информационный шум.

[daesher]

Тогда надо формировать собственный формат - UTF8R - вогнать кириллицу в первый байт, а "окно" для последующих символов урезать, скажем, до служебных символов (0-31). И потом везде "форсить" эту кодировку
Ну, ноль нельзя для совместимости с Pchar, останется 31 байт для расширения. Почему бы и нет? При желании, выкинув всякий хлам, можно даже греческие буквы в первый байт забить. Особенно если учесть, что некоторые буквы кириллицы и греческого алфавита совпадают по начертанию... Ну да ладно.
Да, расширенную кириллицу, всякие фигурные кавычки и иже с ними придётся выбросить в двухбайтовый набор, но всё основное останется. А управляющие символы идут во входящей кодировке... В крайнем случае, можно и их оставить, сделав окно на уровне символов 128 - 159. Тогда все греческие буквы уже не уместить.

[alexey38]

Я понял, что кода от Вас не будет и подтверждать свои утверждения вы не собираетесь. Учту на будущее, чтобы не реагировать в дальнейшем на Ваш информационный шум.

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

Речь идет о уникодных кодировках в Лазаре и ФПС, о чрезвычайно сложным и как следствие медленным кодом, при работе с UTF8 в ФПС и Лазаре (это объективная реальность, быстрее не сделать). Как на это влияет возможности среды RAD Studio? В Дельфях есть только UTF-16. Компилятор Дельфи текст программы проглатывает в любой уникодной кодировке, а файл ресурсов формы только в 8-битной ANSI, но там кирилистический текст записывается в виде "Caption = #1040#1085#1072#1083#1080#1079' '#1080#1079#1084#1077#1088#1077#1085#1080#1081", т.е. в .dfm файлах нет не латинских символов.

[absdjfh]

Talk is cheap. Show me the code

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

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

[alexey38]

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

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

[xdsl]

Еще раз убедился, что среди юникода альтернативы UTF-8 нет. Совместимость и компактность, поддержка от 1 до 6 байтов на символ (в то время как юникоду хватает 4 байт, значит - есть возможность роста), отсутствие неоднозначности в BOM (классическая проблема неразличимости UTF-16LE и UTF-32LE). Единственный недостаток - усложнение обработки (тем-же страдает utf-16, т.к. поддерживает 2 или 4 байта на символ, что его апологеты предпочитают игнорировать).

Ни разу в жизни не встречал исходников программ в utf-16 или utf-32. В то время как однобайтные кодировки - повсеместно, utf-8 - несколько реже. Наверняка, как меня тут пытались убедить, в utf-16 хранят исходники коммерческих проектов стоимостью от 10000$ и выше, заглянуть в которые можно только с подпиской о неразглашении (с коммерческими исходниками меньшей стоимости работал, там почему-то кода ни в utf16, ни в utf-32 не встречал).

Мое мнение подтверждает (см. кодировку веб-страницы) ibm.com, oracle.com, intel.com, apple.com, embarcadero.com, microsoft.com и множество других сайтов, среди которых чем дальше, тем меньше встречаются отличные от utf-8 кодировки. freepascal.ru - не исключение.

Ах да, еще меня умиляют вот такие выпады в сторону Кена Томпсона и Роберта Пайка:

Юниксоиды, будучи в своей массе англоязычными из лени и нежелания обеспечивать совместимость старых прог с мультиязычными кодировками выдумали UTF8, который для англоязычных челов как был, так и остался обычной 8-битной кодировкой. Это был изначально баговый путь развития, исходя из расисткого (пренебрежительного) отношения к неанглоязычным челам.

[hovadur]

xdsl я с тобой согласен.

[alexey38]

Ни разу в жизни не встречал исходников программ в utf-16 или utf-32.

В чем магия или величие хранения именно исходников в форматах UTF-8, UTF-16, UTF-32? Что в этом действии такого уникального и важного, что именно хранение исходников дает Вам стимул именно увидеть эти исходники?

Я не понимая Вашего упорства именно в вопросе хранения исходников. Уникодовские кодировки между собой совместимы через конвертирование. Например, хранишь исходник UTF-8, и если надо, то однозначно его конвертируешь в UTF-32. В чем магичность этого элементарного действия, что Вы в это так вцепились?

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

Ах да, еще меня умиляют вот такие выпады в сторону Кена Томпсона и Роберта Пайка:

Вы хотите сказать, что Томпсон и Пайк говорили и писали на русском? И они по Вашему всю жизнь думали только о русских и алгоритмах для русских?

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

Еще раз убедился, что среди юникода альтернативы UTF-8 нет.

Вы про формат хранения или про тип переменных в Паскале? Я чувствую, что Ваша тяга к исходникам говорит о формате файла. Формат файлов на диске меня мало волнует.

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

множество других сайтов, среди которых чем дальше, тем меньше встречаются отличные от utf-8 кодировки.

В каком формате передается HTML по сети меня также мало волнует, т.к. там есть тэг <meta charset="utf-8"/>.
Еще раз я не говорил про форматы хранения данных и форматы транспортировки HTML, т.к. не вижу ни каких проблем. В чем хотите, в том и храните. Если надо, то перекодировать настолько легко, что не стоит за это беспокоится.

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

отсутствие неоднозначности в BOM (классическая проблема неразличимости UTF-16LE и UTF-32LE)

В файлах utf-8 на дисках (не в типах переменных, а именно в файлах) без BOM есть проблема в том, что они не различимы от файлов в других 8-битных форматах. Проблема именно в этом. Браузеры тому в подтверждение, что встречаются страницы, где не работает автораспознавание кодировок, редко, но еще встречается. Именно по отсутствию тэга (meta charset или BOM). Классическая проблема неразличимости UTF-16LE и UTF-32LE существует только в теории. Решается она чтением 4-х, а не 2-х байтов. Любой школьник сможет решить эту классическую проблему.

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

Единственный недостаток - усложнение обработки (тем-же страдает utf-16, т.к. поддерживает 2 или 4 байта на символ, что его апологеты предпочитают игнорировать).

Для типа данных (типа переменных) в программе - это не единственный, а это ОГРОМНЫЙ и СУЩЕСТВЕННЫЙ недостаток. Вы пользуетесь методом пузырьковой сортировки? Ведь единственный недостаток пузырька - это чрезвычайно медленная работа.
Вы считаете, что медленные алгоритмы в программе очень нужны по той причине, что сайт apple.com сделан на UTF-8? Вы, что ли ябломан и символист?

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

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

значит - есть возможность роста

А это классическая беда и самообольщение. Многие люди думали, что они чего-то там предусмотрят на будущее, для роста. Но реальность такова, что не угадываете, где будет рост. Задел на якобы будущее делается не там, где надо, а там где не надо.

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

проектов стоимостью от 10000$

10 т.баксов (300 т.р.) - это месячные затраты (зарплата, налоги, аренда, амортизация) для 2-3 программистов. Не бывает коммерческих проектов с такой низкой себестоимостью. Нужно прибавить хотя бы один нолик, а лучше пару нулей, тогда получите среднюю стоимость простенького проекта для России.