Это ответвление этого вопроса: Chrome неправильно считает символы в текстовой области с атрибутом maxlength
В этом вопросе было обнаружено, что Javascript возвращает каретку в один символ, хотя на самом деле это два (\r\n), почему тот?
Тестовая скрипта: http://jsfiddle.net/maniator/E527z/
По неизвестным причинам jQuery всегда преобразует все новые строки в значении <textarea> в один символ. То есть, если браузер дает ему \r\n для новой строки, jQuery гарантирует, что это просто \n в возвращаемом значении .val(). (На самом деле причина, вероятно, не «неизвестна»; вероятно, это нормализует результаты в разных браузерах, потому что IE сообщает, что новые строки имеют длину 2 символа.)
Chrome и Firefox одинаково считают длину тегов <textarea> для целей «maxlength».
Однако спецификация HTTP настаивает на том, чтобы новые строки представлялись как \r\n. Таким образом, jQuery, webkit и Firefox ошибаются. Когда поле опубликовано, webkit и Firefox правильно добавляют новые строки!
В результате «maxlength» в тегах <textarea> практически бесполезна, если ваш код на стороне сервера действительно имеет фиксированный максимальный размер для значения поля.
Изменить Это все еще проблема в 2015 году — по крайней мере, в Chrome 45.0.2454 и IE 11.0.9600.
maxlength не будет работать правильно и считать новые строки как два символа, а именно так данные будут сохранены на бэкэнде?
- person wired_in; 29.10.2014
maxlength (мое личное мнение). Я зарегистрировал ошибки в Firefox и WebKit, и количество причудливых неосведомленных возражений, которые я получил, просто поразительно. Реализации maxlength проверяют длину, возвращаемую .value, то есть длину без символов CR, которые вводятся при отправке формы. Я пошел дальше, и я просто буду придерживаться своего решения JavaScript.
- person Pointy; 30.10.2014
maxlength проверяют длину, возвращаемую .value, то есть длину без символов CR - все наоборот. maxlength подсчитывает CR + LF (чего нет в JavaScript) - как показано выше jsfiddle и в связанном вопросе. Итак, maxlength на самом деле правильно в отношении кода на стороне сервера, это проблема только в том случае, если вы также обрабатываете это с помощью JavaScript на стороне клиента.
- person MrWhite; 06.09.2015
maxlength проверял - было обширное обсуждение ошибок, которое я зарегистрировал тогда как с людьми из Mozilla, так и с WebKit.
- person Pointy; 06.09.2015
\r и \n при рассмотрении maxlength, и это действительно помогает со стандартом HTTP для новых строк POST как \r\n (ввод браузера соответствует серверу). FireFox и Internet Explorer (10 и выше, где была введена поддержка HTML5 textarea maxlength) не учитывают \r при применении maxlength, и в их случае проблема заключается в том, что если сервер следует тем же правилам для усечения данных (что является хорошей идеей при очистке входных данных, потому что maxlength легко обойти), то ввод сервера не совпадает.
- person nothingisnecessary; 21.01.2016
\r + \n) в JavaScript или при применении атрибута maxlength (включая Chrome до 65/67)... при отправке на сервер, разрывы строк удваиваются как \r\n, как и ожидалось по спецификациям.
- person scunliffe; 03.04.2018
\n в мире браузера — это нормально, и что все бэкэнд-решения должны приводить \r\n к \n if, чего хочет бэкэнд/БД. Некоторые части истории Интернета озадачивают меня. Я получаю войну / против \ Unix против Microsoft в пути URL ... но ИМХО, \r\n было ошибкой.
- person scunliffe; 03.04.2018
\r является обязательным, так что избавиться от этого тоже было бы неплохо. Просто странная ситуация.
- person Pointy; 03.04.2018
