Firefox и Chrome заменяют LF на CR + LF во время POST - PullRequest
Новая
       0

Firefox и Chrome заменяют LF на CR + LF во время POST

4 голосов
/ 06 августа 2011

Почему Firefox и Chrome заменяют символ LF на CR + LF во время POST?

В качестве теста я написал следующее: 

<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

Ответы [ 2 ]

3 голосов
/ 06 августа 2011

Оказывается, это связано с типом кодировки x-www-form-urlencoded. Согласно спецификации :

Не алфавитно-цифровые символы заменяются на «% ЧЧ», знак процента и две шестнадцатеричные цифры, представляющие ASCII-код символа. Разрывы строк представлены в виде пар "CR LF" (т. Е. "% 0D% 0A").

0 голосов
/ 06 августа 2011

изменить & mdash; обязательно прочитайте проницательный комментарий @ pepsi - все это, вероятно, фальшивка :-)

Это потому, что протокол HTTP предусматривает, что CR-LF является ограничителем строки для всего, кроме «тела объекта», параметры которого не являются частью.

Поэтому более интересный вопрос заключается в том, почему Firefox (и Chrome? Не уверен) удаляет , возвращая символы из <textarea> значений элемента при ответе на запросы о свойстве "value" свойства элементы DOM, но они возвращают CR при публикации. Это означает, что код, который хочет делать как поведение «счетчика символов» комментария Stackoverflow, должен учитывать тот факт, что количество символов, которые будут опубликованы, не обязательно совпадает с количеством символов в значении свойства «значение» .

Наконец, также интересно отметить, что jQuery нормализует поведение браузера и гарантирует, что ответ «.val ()» для <textarea> элементов всегда не имеет символов CR, что делает его равномерным неправильно для всех браузеров: -)

изменить & mdash; фактически при изучении RFC может случиться так, что в запросе POST секцию параметров следует считать "телом сущности". Если это так, браузеры конвертируют в CR-LF, вероятно, просто чтобы быть консервативным. Предполагается, что серверы должны быть действительно гибкими с соглашениями об окончании линии, но, может быть, 10 лет назад это не так, и браузеры просто сделали простую вещь и отправили нормализованную пару CR-LF, чтобы быть в безопасности.

Также обратите внимание, что IE всегда делал это, вроде как, но разница в том, что значение <textarea> в IE всегда сообщается с неповрежденными символами CR.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...