Имея систему Windows, я обнаружил, что значение textarea, состоящее из одного разрыва строки, равно строке JavaScript "\n", а не "\r\n":
console.info(document.getElementById("textarea").value === "\n"); // true
console.info(document.getElementById("textarea").value === "\r\n"); //false<textarea name = "" id = "textarea" cols = "30" rows = "10">
</textarea>Означает ли это, что я не должен беспокоиться о проблеме CRLF и LF при работе со значениями textarea, поскольку их разрывы строк всегда нормализованы к строке "\n" === "\u{000A}", поэтому я могу с уверенностью сказать, что lineBreakOnlyValue.length === 1 и выполнить такое задание
document.getElementById("textarea").value = "\n" не задумываясь о адресации разрыва строки в разных системах?
Было ли это поведение каким-то образом задано?



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


В текущем стандарте HTML говорится об элементе текстовой области :
Значение API — это значение, используемое в атрибуте
valueIDL, атрибутеtextLengthIDL и атрибутах содержимогоmaxlengthиminlength. Он нормализован таким образом, что для разрывов строк используются символы U+000A LINE FEED (LF).[...] Алгоритм получения значения API элемента состоит в том, чтобы вернуть необработанное значение элемента с нормализованными символами новой строки.
Нормализация новых строк описывается как следует:
Чтобы нормализовать символы новой строки в строке, замените каждую пару кодовых точек U+000D CR U+000A LF на одну кодовую точку U+000A LF, а затем замените каждую оставшуюся кодовую точку U+000D CR на кодовую точку U+000A LF.
В то время как свойство value подлежит этой нормализации, свойства textContent, innerHTML, ... нет.
Небольшая демонстрация:
console.info("innerHTML", JSON.stringify(txt.innerHTML));
console.info("textContent", JSON.stringify(txt.textContent));
console.info("value", JSON.stringify(txt.value));<textarea id = "txt">a b</textarea>Интересно, когда мы нажимаем клавишу enter при использовании системы Windows, будет ли textarea получать CRLF в виде необработанного значения или браузер сам нормализует его до LF?
Я не знаю. Конечно, это возможно, но поскольку JavaScript не может получить доступ к измененному необработанному значению, а только к нормализованному значению, он прозрачен для JavaScript.
более старые версии IE использовали
\r\n, но теперь все (даже блокнот окна) остановились на\n, включая вставку в. Единственное место, где\r\nможет закрасться (на самом деле), это когда FileReader выгружает результат readAsBinaryString() из значения файла, использующего\r\n, в textarea.value. Короче говоря, нет, вам действительно не нужно беспокоиться об этом.