Я не говорил, что мы разрешаем использовать любые символы юникода. Проверка на дубли работает совсем не по сравнению текста, а аналитика никак не страдает.
Теперь можно спрятать аудио наркотики за символами которые будут обходить черный список
У вас кстати есть статистика по количеству знаков в обьявлениях? Среднее, медиана?
Такая статистика у нас конечно же имеется.
Пользователь оперирует не знаками, а абстракциями более высокого порядка
Как раз именно знаками и оперирует пользователь. В особенности профессиональные пользователи, которые встречаются с такой механикой в любой системе.
Возьмите, например, копирайтеров, переводчиков и другие профессии, связанные с текстами в более классическом понимании. Они не берут оплату за страницу или слово. Объем работ и ценность считается по количеству знаков в тексте. Журналисты пишут статью на определенное количество знаков. Знак — универсальная едина измерения, потому что текст может быть воспроизведен на любом носителе, занимать разное количество страниц, экранов, чего угодно. Количество знаков в тексте останется неизменным.
Чтобы прогнозировать занимаемое место, надо понимать, как работает юникод. В частности, в какой кодировке буду храниться текста. Пользователь же оперирует графическими знаками, а не размерами.
Перечитайте мои объяснения еще раз, пожалуйста. Проверки делать по принципу "сколько влезет" нельзя. У каждого пользователя должно быть четкое понимание, сколько знаков он может использовать. При этом каждый пользователь должен иметь идентичные возможности. А сервер должен уметь также проверять ограничения.
Ну и вы ничем не подкрепили утверждение, что с увеличением количества символов разница будет расти, напротив, она скорее будет уменьшаться, чисто статистически.
Чем больше символов разной ширины можно напечатать на условном листе, тем больше вариантов комбинаций с разным количеством символов может быть, тем больше будет разрыв между минимальным и максимальным количеством символов.
Даже представить не могу пользователей, которые пишут 10к знаков в объявлении (многие рассказы заметно короче)
Существуют продавцы, особенно профессиональные, которые используют описание по максимуму.
И вы всерьез беспокоитесь о том, будет ли база весить 100 гигабайт или 120?
Надо уметь прогнозировать требования к железу при изменениях в таких больших проектах. В наших реалиях речь идет далеко не о сотнях ГБ.
Ну и если уж мы рассуждаем о костылях, то нельзя не упомянуть и велосипеды :)
Решение в статье не позиционируется, как альтернатива библиотеке. Я рассматриваю проблему и привожу примеры, как с ней можно бороться. В своем проекте вы можете использовать для решения этой проблемы вышеописанную библиотеку, если считаете это целесообразным.
Можно посчитать, но в среднем эта разница будет мизерной для обычных текстов, частота встречаемости букв определяет гораздо больше. А также длина слов и количество пробелов, так что дискриминации как-то не наблюдаю.
Разница существенно увеличивается с увеличением ограничения на длину. Попробуйте объяснить пользователям, почему они видят объявления с 10 000 знаков в описании, а сами могу написать максимум 9 000, например. У вас это не получится сделать. Вы получите кучу негатива и багрепортов от пользователей.
Решение с оверлеем — это классический пример костыля, когда у вас нет экспертизы/желания, чтобы сделать правильно.
- Решение не выносит никакой критики для адаптивности. На мобилках оно просто не будет работать. - Размеры оверлея я всегда могу поправить руками и обойти валидацию в 2 клика - Такую же валидацию должен уметь делать сервер, потому что клиентскую валидацию всегда можно обойти. Сервер не сможет сделать это никак, кроме как имея константу на количество знаков.
Ваш метод подсчета абсолютно не жизнеспособен, к сожалению. Ограничивая таким образом ввод вы никак не учитываете то, что все символы имеют разную ширину и в один и тот же блок может уместиться их разное количество. Таким образом вы ставите пользователей в неравное положение, когда один может написать условно 1000 знаков, а у другого вместится всего 900.
Ограничения на длину диктуются совсем не UI/UX, а балансом между потребностями пользователя и прогнозированием места и железа, которое будет занимать эти описания при хранении. Когда речь идет о десятках миллионов пользователей, длина каждой строки сохраненной в базе имеет весомое значение.
В слове «йод» три графемы и три кодовые точки: U+0439, U+043E, U+0434. При этом возможна запись буквы «й» в виде пары буквы «и» и комбинируемого бреве U+0306. Эти примеры рассмотрены в статье.
Какие еще проблемы диактритики вы имеете в виду?
В конце статьи четко написано, что рассмотрены далеко не все примеры и особенности, потому что все их охватить в одном материале сложно.
Я не говорил, что мы разрешаем использовать любые символы юникода. Проверка на дубли работает совсем не по сравнению текста, а аналитика никак не страдает.
Поясните, каким образом это связано?
Такая статистика у нас конечно же имеется.
Как раз именно знаками и оперирует пользователь. В особенности профессиональные пользователи, которые встречаются с такой механикой в любой системе.
Возьмите, например, копирайтеров, переводчиков и другие профессии, связанные с текстами в более классическом понимании. Они не берут оплату за страницу или слово. Объем работ и ценность считается по количеству знаков в тексте. Журналисты пишут статью на определенное количество знаков. Знак — универсальная едина измерения, потому что текст может быть воспроизведен на любом носителе, занимать разное количество страниц, экранов, чего угодно. Количество знаков в тексте останется неизменным.
Чтобы прогнозировать занимаемое место, надо понимать, как работает юникод. В частности, в какой кодировке буду храниться текста. Пользователь же оперирует графическими знаками, а не размерами.
Перечитайте мои объяснения еще раз, пожалуйста. Проверки делать по принципу "сколько влезет" нельзя. У каждого пользователя должно быть четкое понимание, сколько знаков он может использовать. При этом каждый пользователь должен иметь идентичные возможности. А сервер должен уметь также проверять ограничения.
Чем больше символов разной ширины можно напечатать на условном листе, тем больше вариантов комбинаций с разным количеством символов может быть, тем больше будет разрыв между минимальным и максимальным количеством символов.
Существуют продавцы, особенно профессиональные, которые используют описание по максимуму.
Надо уметь прогнозировать требования к железу при изменениях в таких больших проектах. В наших реалиях речь идет далеко не о сотнях ГБ.
Решение в статье не позиционируется, как альтернатива библиотеке. Я рассматриваю проблему и привожу примеры, как с ней можно бороться. В своем проекте вы можете использовать для решения этой проблемы вышеописанную библиотеку, если считаете это целесообразным.
Разница существенно увеличивается с увеличением ограничения на длину. Попробуйте объяснить пользователям, почему они видят объявления с 10 000 знаков в описании, а сами могу написать максимум 9 000, например. У вас это не получится сделать. Вы получите кучу негатива и багрепортов от пользователей.
Решение с оверлеем — это классический пример костыля, когда у вас нет экспертизы/желания, чтобы сделать правильно.
- Решение не выносит никакой критики для адаптивности. На мобилках оно просто не будет работать.
- Размеры оверлея я всегда могу поправить руками и обойти валидацию в 2 клика
- Такую же валидацию должен уметь делать сервер, потому что клиентскую валидацию всегда можно обойти. Сервер не сможет сделать это никак, кроме как имея константу на количество знаков.
Ваш метод подсчета абсолютно не жизнеспособен, к сожалению. Ограничивая таким образом ввод вы никак не учитываете то, что все символы имеют разную ширину и в один и тот же блок может уместиться их разное количество. Таким образом вы ставите пользователей в неравное положение, когда один может написать условно 1000 знаков, а у другого вместится всего 900.
Ограничения на длину диктуются совсем не UI/UX, а балансом между потребностями пользователя и прогнозированием места и железа, которое будет занимать эти описания при хранении. Когда речь идет о десятках миллионов пользователей, длина каждой строки сохраненной в базе имеет весомое значение.
Да, проблема правда очень сложная. Снимаю шляпу перед людьми, которые делали Intl.Segmenter и подобные вещи.
Эмодзи, как и wysiwyg редакторы, помогают продавцам лучше оформлять объявления и делать их более привлекательными для покупателей.
Пример с фотоаппаратом синтетический, чтобы показать особенности работы JS.
А чем вам слак не угодил?
Я по ошибке вставил в пример уже нормализованный глиф. Спасибо, что заметили. Уже исправил пример.
Спасибо! Очень приятно получить такой отзыв.
Спасибо за оценку)
В слове «йод» три графемы и три кодовые точки: U+0439, U+043E, U+0434. При этом возможна запись буквы «й» в виде пары буквы «и» и комбинируемого бреве U+0306. Эти примеры рассмотрены в статье.
Какие еще проблемы диактритики вы имеете в виду?
В конце статьи четко написано, что рассмотрены далеко не все примеры и особенности, потому что все их охватить в одном материале сложно.
Узнал об
enterkeyhintВозьму себе на заметку