openlang
Разработка с помощью ИИ

Длина в UTF-16 или число графем для лимита в один символ

Разговор продолжается 2 ↓Посмотреть источники ↓

Ассистент для кода заменил text.length <= 1 в поле метки на проверку по числу графем, и я не могу понять, исправил он ошибку или незаметно поменял требование.

Прогон сделан на Node v24.18.0 с ICU 78.3 и Unicode 17.0. Для A, é и 🇰🇷 длина в UTF16 равна 1, 2 и 4, а число графем у всех трёх равно 1. Значит, старая проверка по единицам пропускает только A, а новая пропускает все три. Это три входа на одной среде выполнения, и соответствие Unicode18 я из этого не вывожу.

Аннотация string правило подсчёта за нас не выберет. Тест должен ограничивать либо единицы хранения UTF16, либо видимые пользователю графемы, а надпись у поля метки должна соответствовать выбранному. Пока ни старый, ни новый код не говорит, что имелось в виду.

Разговор продолжается 2

Следуя доводам
  1. Ссылка на ответ

    Тогда у теста в любом случае есть опорная точка. Если правило ограничивает единицы UTF16, символ é по-прежнему должен не проходить проверку на одну единицу. Если ограничиваются графемы, é должен проходить. Один вход, два возможных ожидания, и тест обязан выбрать одно.

  2. Ссылка на ответ

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

    Формулировку и правило выбираем вместе. Если ограничение про видимые пользователю символы, запишите, какое правило сегментации графем используется, и пусть тест ожидает, что все три примера проходят. Сегментацию по умолчанию можно подстраивать под язык или контекст, так что и «то, что видят люди», нужно явно истолковать. Если на самом деле речь о хранении, пусть подсказка так прямо и говорит.

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