Question

为什么Firefox和Chrome在POST期间用CR + LF替换LF字符？

我写了以下内容作为测试：

<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.js"></script>
<script type="text/javascript">
function lftest()
{
    var linefeed = "before";
    linefeed += String.fromCharCode(10); //linefeed
    linefeed += "after";
    $("#field").val(linefeed);
    $("#formthing").submit();
}
</script>
</head>

<body>
<form id="formthing" method="post" action="http://someurl.com/resource">
<input type="hidden" id="field" value="" name="line" />
<a href="#" onclick="lftest()">send</a>
</form>
</body>
</html>

开发人员工具网络选项卡显示POST数据：

before%0D%0Aafter

Answer 1

事实证明这与x-www-form-urlencoded编码类型有关。根据{{3}}：

非字母数字字符替换为'％HH'，百分号和两个十六进制数字，表示字符的ASCII码。 换行符表示为“CR LF”对（即'％0D％0A'）。

Answer 2

编辑 - 确保阅读@ pepsi的富有洞察力的评论 - 以下内容可能都是虚假的:-)

<小时/> 这是因为HTTP协议规定CR-LF是除“实体主体”之外的所有内容的行终止符，这些参数不是其中的一部分。

因此，更有趣的问题是，为什么Firefox（和Chrome？不确定）剥离在响应“值”请求时从<textarea>元素值返回字符“DOM元素的属性，但是他们在发布时将CR放回去。这意味着想要像Stackoverflow注释“字符计数器”行为那样的代码必须考虑到这样一个事实，即发布的字符数不一定与“value”属性值中的字符数相同

最后，还有一点值得注意的是，jQuery会规范化浏览器行为，并确保<textarea>元素的“.val（）”响应始终没有CR字符，从而使其统一所有浏览器的错误： - ）

编辑 - 实际上在研究the RFC时，可能是在POST请求中，参数部分被视为“实体主体”。如果是这样，浏览器转换为CR-LF可能只是为了保守。服务器应该是非常灵活的线路终端约定，但也许10年前它们不是，并且浏览器只是做了简单的事情并发送标准化的CR-LF对是安全的。

另请注意，IE总是这样做，排序，但区别在于IE中<textarea>的值始终报告CR字符完整。

在POST期间，Firefox和Chrome用CR + LF替换LF

2 个答案: