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

为什么Firefox和Chrome在POST期间用CR + LF替换LF字符？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

来源

2011-08-05 pepsi

原来，这与x-www-form-urlencoded编码类型有关。根据the spec：

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

来源

2011-08-06 01:21:11 pepsi

编辑 — 一定阅读@百事的精辟评论 - 以下全部可能都是假的:-)

这是因为HTTP protoc ol规定CR-LF是除了“实体主体”之外的所有行的终止符，这些参数不是其中的一部分。

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

最后，这也是有趣的是，jQuery的标准化浏览器的行为，并确保了“.VAL（）”的回应为<textarea>元素总是没有CR字符，使其均匀错对于所有浏览器： - ）

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

另外请注意，IE也总是这样做，但不同之处在于IE中的<textarea>的值始终以CR字符完整报告。

来源

2011-08-05 23:20:25 Pointy

但表单输入值在POST期间被编码。％0A不是LF协议的HTTP协议 – pepsi

@pepsi这是一个很好的观点。尽管如此，就我所知，这些浏览器总是*做到了这一点，而且我发现的唯一解释就是协议。（当然，你的观察结果让人很怀疑:-) – Pointy

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

回答

相关问题