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

回答

相關問題