forum.clarionlife.net

Игорь Столяров писал(а): 12 Январь 2026, 16:10 И это - правда. Только полноценный UTF-16, а не 2-х байтовый упрощённый вариант.

Вот именно. Там много написано всякого, кроме того, насколько это будет совместимо. И в чём будет выражаться данная совместимость? В получении данных из API, без чего мы, в большинстве своём, проживём и дальше, или в чём-то полезном?

Не совсем понял, чем отличается utf-16 от "упрощенного 2-х байтного варианта"? Utf-16 и есть 2-х байтный вариант представления юникода.

finsoftrz писал(а): 12 Январь 2026, 16:58 Не совсем понял, чем отличается utf-16 от "упрощенного 2-х байтного варианта"?

Вот я тоже не понимаю. Единственное, что приходит в голову, это функции типа LEN(uString) могут возвращать неверную длину строки, если в ней суррогатные (4-хбайтные) символы.

Будет зависеть от реализации len. Если учитывать суррогатные пары, то надо будет перебирать все содержимое строки, что приведет к снижению скорости работы. Как я понял, в настоящее время суррогатные пары не поддерживаются, это покрывает потребность в кодировании символов всех распространенных языков. А фраза RZ по поводу суррогатных пар означает, что при необходимости (если многим надо будет) они реализуют это.
Я тут подумал, а может вообще нет никакого ustring, это только roadmap. А мы кинулись обсуждать.

Дед Пахом писал(а): 12 Январь 2026, 17:01 Единственное, что приходит в голову, это функции типа LEN(uString) могут возвращать неверную длину строки, если в ней суррогатные (4-хбайтные) символы

Ну это меньшее из возможных зол.
Получив из внешней функции (WinAPI) данные с 4-х байтными символами - Clarion в USTRING их интерпретирует как мусор.

Мне вообще не нравится, что USTRING имеет размер. Это просто очередное натягивание совы на глобус ...

Игорь Столяров писал(а): 12 Январь 2026, 19:27 Получив из внешней функции (WinAPI) данные с 4-х байтными символами - Clarion в USTRING их интерпретирует как мусор.

WinAPI либо возвращают указатель на 2-хбайтовый массив, оканчивающийся на <0,0>, либо, если передать NULL в качестве указателя на массив, то возвращают длину, которую можно зарезервировать и в повторном вызове уже прочитать этот массив целиком. Не вижу проблем с реализацией USTRING.

Дед Пахом писал(а): 12 Январь 2026, 20:32 WinAPI либо возвращают указатель на 2-хбайтовый массив

WIDE функции WinAPI возвращают указатель на строку в UTF-16.
Абсолютно нет никаких проблем получить размер ответа и принять результат - что в общем-то сейчас и делается.

Но если мы будем сразу принимать ответ UTF-16 в строку USTRING - то могут быть проблемы.

если ANSI-вариант SomeApiProcA возвращает указатель на строку, оканчивающуюся нулём, то мы передаём в неё ссылку на CSTRING:
То же самое должно быть и для USTRING:

Дед Пахом писал(а): 12 Январь 2026, 21:28 То же самое должно быть и для USTRING:

А вот теперь объясните, оно всего этого геморроя стоило?!

Вспоминается мем с бабкой "Нам этот ваш юникот нахой не нужон!!"

Губин Игорь писал(а): 12 Январь 2026, 21:42 А вот теперь объясните, оно всего этого геморроя стоило?!

Для WinAPI конечно нет. А вот если файловые драйвера будут поддерживать, это другое

Дед Пахом писал(а): 12 Январь 2026, 21:52 А вот если файловые драйвера будут поддерживать, это другое

Пока не знаю нафига мне это...

Зачем вы обсуждаете какие-то суррогатные пары? У меня более приземлённый вопрос - какая БД поддерживает UTF-16? SQLite поддерживает! Как пишут - не совсем полноценно, но у SQLite всё так (шутка).

Драйвер (в теории) должен преобразовывать строку UTF-16 в UTF-8 на лету, прозрачно для нас. То есть к примеру есть таблица то ADD(MyFile) должен корректно передать юникод на сервер, в нужной кодировке.

Дед Пахом писал(а): 12 Январь 2026, 23:40в теории