POST中にLFをCR + LFに置き換えたFirefoxとChrome

POST中にFirefoxとChromeがLF文字をCR + LFに置き換えるのはなぜですか？POST中にLFをCR + LFに置き換えたFirefoxとChrome

私はテストとして次のことを書いた：

<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コードを表す 2桁の16進数に置き換えられています。 改行は「CR LF」のペア（「％0D％0A」）で表されます。

出典

2011-08-06 01:21:11 pepsi

編集 — はペプシの洞察に満ちたコメント@読み取るために必ず - 以下はすべて偽の可能性があります:-)

HTTPプロトックCR-LFは「エンティティボディ」以外のすべての行終端文字であり、パラメータはその一部ではないと規定されています。

より興味深い質問は、それはDOM要素の「値」プロパティの要求に応答するときのFirefox（とChrome？わからない）が<textarea>要素値からリターン文字を取り除くことである理由ゆえ、ですが、投稿時にCRを戻します。つまり、Stackoverflowコメントの "文字カウンタ"動作のようにしたいコードは、投稿される文字数が「値」プロパティ値の文字数と必ずしも同じではないという事実を考慮する必要があります。

最後に、それはjQueryのすべてのブラウザのために均一に間違っそれを作る、ブラウザの挙動を正規化し、<textarea>要素常にための「.val（）」レスポンスが全くCR文字を持っていないことを確認することに注意することも興味深いです： - ）実際にはPOSTリクエストのパラメータセクションは、「エンティティ本体」と見なされるべきである場合がありますthe RFCを勉強したとき

編集 —。もしそうなら、ブラウザは単にCR-LFに変換しているだけかもしれません。サーバーはライン終了規則では本当に柔軟性があると思われますが、10年前にはそうではなく、ブラウザーは単純なことを行い、CR-LFペアを標準化して安全に送っていました。

また、IEは常にこれを行っていることに注意してください。ただし、違いは、IEの<textarea>の値は、常にCR文字でそのまま報告されるという点です。

出典

2011-08-05 23:20:25 Pointy

しかし、フォーム入力値はPOST中にエンコードされます。％0AはHTTPプロトコルのLFではありません – pepsi

よく@pepsiは良い点です。それにもかかわらず、それらのブラウザーは私の知る限り、常にこれを行いました。私が今までに見つけた唯一の説明は、プロトコルのものでした。（今、あなたの観察は深刻な疑念の中でその説明を残します:-) – Pointy

POST中にLFをCR + LFに置き換えたFirefoxとChrome

答えて

関連する問題