textarea 换行符值是否始终标准化为“\n”javascript 字符串？

Question

在 Windows 系统中，我发现由一个换行符组成的文本区域的值等于 JavaScript 字符串"\n"，而不是"\r\n"：

console.log(document.getElementById("textarea").value === "\n"); // true
console.log(document.getElementById("textarea").value === "\r\n"); //false

<textarea name="" id="textarea" cols="30" rows="10">

</textarea>

这是否意味着我在使用 textarea 值时不应该担心CRLFvs问题，因为它们的换行符总是标准化为字符串，所以我可以肯定地说并完成这样的任务 ，而无需考虑不同系统的换行符寻址？LF"\n" === "\u{000A}"lineBreakOnlyValue.length === 1document.getElementById("textarea").value = "\n"

这种行为是否以某种方式具体化？

Answer 1

在当前的 HTML 标准中，它是关于textarea 元素的：

valueAPI 值是IDL 属性、textLengthIDL 属性以及maxlength和内容属性中使用的值minlength。它已标准化，以便换行符使用 U+000A 换行 (LF) 字符。

[...] 获取元素 API 值的算法是返回元素的原始值，并标准化换行符。

换行符的规范化描述如下：

要标准化字符串中的换行符，请将每个 U+000D CR U+000A LF 代码点对替换为单个 U+000A LF 代码点，然后将每个剩余的 U+000D CR 代码点替换为 U+000A LF 代码点。

与其他属性的比较

虽然value属性受到这种规范化的影响，但textContent, innerHTML, ... 属性则不然。

一个小演示：

console.log("innerHTML", JSON.stringify(txt.innerHTML));
console.log("textContent", JSON.stringify(txt.textContent));
console.log("value", JSON.stringify(txt.value));

<textarea id="txt">a&#13;&#10;b</textarea>