Dimitry SibiryakovNickDeeЭто делает firebird, чтобы проверить не превышает ли юникод-строка
ограничение в N юникодных символов.
Нет, Firebird ничего подобного не делает.
Т.е. проверяет по количеству байт, т.е. тот же N*4?
Он либо проверяет по количеству символов, либо по количеству байт.

Эксперимент. Подключаюсь к базе с win1251.


Т.е. сервер не ругнулся на 20 байт, но ругнулся на 11.
Он может так ругнуться только если считает не байты, а символы (т.е. парсит utf8-строку).

IBExpertNickDeeОн может так ругнуться только если считает не байты, а символы (т.е. парсит utf8-строку).

В данном случае ты ему подсовываешь 11 символов win1251, чтобы он упихал их в VARCHAR(10). Ему даже парсить и конвертировать ничего не надо для того, чтобы дать тебе отлуп.
Возможно. Но когда я подключаюсь через UTF8 в IBExpert, то:
1. При галке "Do NOT perform conversion from to UTF8" я получаю:
-----------------
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Malformed string.
-----------------
даже при


2. Без галки "Do NOT perform conversion from to UTF8" я при

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

я получаю:
-------------
Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
string right truncation.
-------------

Т.е. сервер таки честно считает количество UTF8 символов.

NickDeeТ.е. сервер таки честно считает количество UTF8 символов.
Пардон - не символов, а unicode code points :)

IBExpertУ символов UTF8 жесткая структура, которая легко валидируется. На этом этапе и длина строки в символах UTF8 легко вычисляется.Дак я про это же и говорю - вычисляется разбором строки.

IBExpertСимвол UTF8 - это последовательность от 1 до 4-х байт (теоретически - до 6). В firebird в системных таблицах это 4 байта. И по стандарту тоже 4.
Википедия своими таблицами на 6 байт конечно вводит в заблуждение.

ТаблоидNickDeeСоздавать все поля как VARCHAR(8000)? Это не вариант, т.к. у меня уже есть опыт с заданием стринговых полей по-дефолту как VARCHAR(255) - тормоза существенные. Создавать стринговые поля как блобы? Это тем более не вариантУ тебя сортировки по этим гамаль-абдель-ибн-хаттаб-аль-трампампам - предполагаются ?
Сортировки скорей всего будут. Но это не мне решать :)
Можно сделать чтобы сервер сортировал, можно сделать чтобы грид сортировал. Это настраиваемо. Но по-умолчанию - сервер.
Предполагаю что сервер лучше знает правильную сортировку для UTF8, и лучше это поручить ему. Возможно заблуждаюсь :)

IBExpertNickDeeВ firebird в системных таблицах это 4 байта. И по стандарту тоже 4.

Это максимум. Твои '1234567890' физически будут лежать именно так, занимая ровно 10 байт, а не 40.
Да я знаю что это максимум. И что ansi-символ в utf8 занимает 1 байт, а кириллический - 2.

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

Как я вижу ситуацию, о которой ты печешься в стартовом посте (теория, не проверял в реале). Прога пишет юзеру "в это поле можно вбить не больше 30 символов". Юзер, видя это сообщение, со спокойной душой вбивает 30 символов из "кудрявых" диапазонов юникода. Вбивает он их в DBEdit, который имеет кодировку utf16, та превращает текст в кучку суррогатных пар - UnicodeString длиной, скажем, 50 символов. Если у DBEdit задано свойство MaxLength=30 (Delphi проявит интеллект, ага) - случится фейл. Если нет - либа для работы с Firebird (ну или ты вручную, на худой конец) выдернет из DBEdit 50-симвльную строку в utf16, конвертнет ее в utf8, у которой длина будет как раз те самые "реальные" 30 символов и запишет в БД без исключений. Т.е. в теории проблем никаких нет. Вопрос - насколько хорошо в реале отрабатывает функция MultiByteToWideChar, которая по умолчанию занимается преобразованием utf16 -> utf8, сможет ли она максимально упаковать суррогатные пары, чтобы не вылезти за лимит, или будут нужны доп.ужимки с нормализацией и предварительной проверкой длины utf8-строки во время ввода в DBEdit
У меня нет DBEdit :)
И в первом посте не про то, чтобы ограничить пользователя. Там про создание поля юзером через админку.
Если бы был резиновый varchar, и если бы пользователь хотел специально ограничить длину заданным количеством code points , то я бы создал constraint на поле:

Либо прописал бы проверку в триггере с вменяемым сообщением.
Но не помню чтобы у меня было желание специально ограничить VARCHAR, кроме разве что для нужд хранения GUID и MD5-хэшей.
Т.е если бы был эффективный резиновый тип, я бы в 99% случаев использовал бы его.

ТаблоидNickDeeПредполагаю что сервер лучше знает правильную сортировку для UTF8, и лучше это поручить ему.Не забудь учесть, что на производительность сортировки влияет именно объявленная длина поля, а не фактическое число символов, которое в нём хранится. Кроме того, в undo-лог записи попадают также с паддингом варчаров до объявленной длины ( Тынц ).
Про это есть тикеты в трекере? :)
Я вообще удивляюсь. Вроде все знают что проблема с длинными варчарами есть, но блин ведут себя так, будто проблем нет :)
И главное когда другие советуют использовать гигантские VARCHAR(32000), то никто из разработчиков что-то не вспоминает что там есть "нюансы", и не говорит что вот там, там и там разложены грабельки :) Вот что мешает подсказать? :)

Dimitry SibiryakovNickDeeкогда другие советуют использовать гигантские VARCHAR(32000), то никто из
разработчиков что-то не вспоминает что там есть "нюансы", и не говорит что вот там, там и
там разложены грабельки :) Вот что мешает подсказать? :)
Надежда, что тот, кому такое подсказывают (кстати, я таких подсказок что-то не припомню) -
не полный дебил и понимает последствия.

Я не понимал последствий, но интуитивно чувствовал что они будут, и что мне не понравится :)
Сейчас понимаю лучше.
Кто без интуиции, тем конечно в firebird лучше не идти :) Или нужно хорошо изучать sql.ru и ibase.ru, и обязательно проверять все утверждения :) Короче путь джедая :)