这是这个问题的一个分支：Chrome counts characters wrong in textarea with maxlength attribute
在那个问题中发现Javascript counts carriage returns are one character when in fact it is two (\r\n)，这是为什么呢？
【问题讨论】：
标签： javascript dom carriage-return
由于未知的原因，jQuery 总是将 <textarea> 值中的所有换行符转换为单个字符。也就是说，如果浏览器给它\r\n 换行，jQuery 会确保它在.val() 的返回值中只是\n。 （实际上原因可能不是“未知”；可能是为了跨浏览器标准化结果，因为 IE 报告换行符为 2 个字符长。）
Chrome 和 Firefox 都以相同的方式计算 <textarea> 标记的长度，以达到“最大长度”的目的。
但是，HTTP 规范坚持将换行符表示为 \r\n。因此，jQuery、webkit 和 Firefox 都犯了这个错误。字段发布后，webkit 和 Firefox 会正确添加换行符！
如果您的服务器端代码确实为字段值设置了固定的最大大小，那么<textarea> 标签上的“maxlength”几乎毫无用处。
编辑这在 2015 年仍然是一个问题 - 至少在 Chrome 45.0.2454 和 IE 11.0.9600 上。
【讨论】：
maxlength 的全部意义（我个人的看法）。我已经记录了针对 Firefox 和 WebKit 的错误，并且我得到的奇怪的不知情的回击数量是惊人的。 maxlength 实现检查由.value 返回的长度，也就是说长度没有表单发布时引入的CR 字符。我已经继续前进，我将继续使用我的 JavaScript 解决方案。
maxlength 实现检查.value 返回的长度，也就是说没有 CR 字符的长度" - 反过来。 maxlength 计算 CR+LF（JavaScript 不计算） - 如上面的 jsfiddle 和链接问题所示。因此，maxlength 对于服务器端代码实际上是正确的，如果您还使用客户端 JavaScript 处理它，这只是一个“问题”。
\r + @ 987654339@) 在 JavaScript 中或在应用 maxlength 属性（包括最高 65/67 的 Chrome）时...提交到服务器时，按照规范的预期，换行符“加倍”为 \r\n。