Историческая причина позади другой строки, заканчивающейся в различных платформах
Проще говоря, вы можете получить данные следующим образом:
@app.before_request
def before_request():
g.data = request.get_json() or request.values
Теперь g.data является экземпляром werkzeug.ImmutableMultiDict. Затем вы можете использовать g.data, который может справиться с большинством ваших требований. Например, вы можете использовать его так:
@app.route("/something", methods=["POST"])
def do_something():
result = handle(g.data)
return jsonify(data=result)
Конечно, вы можете использовать blueprint вместо app ~~
4 ответа
Наследованные окончания строки DOS CR-LF (что Вы называете \r\n, просто делая символы ASCII явными) от CP/M. CP/M наследовал его от различных операционных систем DEC, которые влияли на разработчика CP/M Gary Kildall.
CR-LF использовался так, чтобы машины телетайпа возвратили печатающую головку левому полю (CR = возврат каретки), и затем переместились в следующую строку (LF = перевод строки).
парни Unix обработали это в драйвере устройства, и когда необходимый перевел LF в CR-LF на выводе к устройствам, которым был нужен он.
И поскольку Вы предположили, Mac OS X теперь использует LF.
Действительно добавить в @Mark Harrison ...
Люди, которые говорят вам, что Unix «просто выводит текст, указанный программистом», а DOS не работает, совершенно не правы. Также есть заявления, что для DOS глупо помечать EOF, когда он видит символ EOF, что ставит вопрос о том, для чего именно этот символ EOF.
Не существует единого истинного соглашения для окончаний строк текстовых файлов - только соглашения для конкретных платформ. В конце концов, даже CR-LF, CR и LF не единственные соглашения о конце строки, которые когда-либо использовались, и ASCII никогда не был даже единственным и единственным набором символов. Проблема заключается в стандартной библиотеке C и среде выполнения, которая не отвлекает эту деталь, зависящую от платформы. Другие языки третьего поколения (такие как Pascal и даже Basic) справились с этим, по крайней мере, до некоторой степени. Из-за этого, когда компиляторы C были написаны для других платформ, для достижения совместимости с существующим исходным кодом и книгами требовались взломы библиотек времени выполнения.
Фактически, именно Unix и Multics первоначально нуждались в переводе строк для консольного ввода-вывода, поскольку пользователи обычно сидели за терминалом ASCII, который требовал завершения строки CR LF. Этот перевод был сделан в драйвере устройства, хотя цель состояла в том, чтобы абстрагироваться от особенностей устройства, предполагая, что было бы лучше принять одно соглашение и придерживаться его для сохраненных текстовых файлов.
Хакерство ввода / вывода на С текст в принципе похоже на то, что делает сейчас CygWin, взламывая среды выполнения Linux, чтобы работать так же, как и можно ожидать в Windows. Есть реальная история взлома, которая превращает их в Unix-подобные, но есть и Wine, превращающий Linux в Windows. Как ни странно, вы можете прочитать неуместную критику Windows в конце строки в CygWin FAQ (ссылка на интернет-архив добавлена в 2013 году - страница больше не существует). Может быть, это просто чувство юмора, поскольку они в основном делают то, что критикуют, но в гораздо более широком масштабе; -)
Стандартная библиотека C ++ (на какой бы платформе она не реализована) избегает этой проблемы используя iostreams, которые абстрагируют от конца строки. Для вывода это меня устраивает. Для ввода мне нужно больше контроля, поэтому я либо интерпретирую посимвольные символы, либо использую генератор сканера.
[ РЕДАКТИРОВАТЬ Оказывается, что зачеркнутое утверждение выше не верно, и никогда не было. std::endl буквально переводится как \n и флеш. \n - это то же самое, что \n, которое вы получаете в C - его обычно называют «новой строкой», но на самом деле это символ перевода строки ASCII, который затем переводится средой выполнения при необходимости. Забавно, что ложные предположения могут быть настолько укоренившимися, что вы никогда не подвергаете их сомнению - в основном, у C ++ не было выбора делать то, что делал C (кроме добавления большего количества слоев сверху) по причинам совместимости, и это всегда должно было быть очевидно.] 1112] Самая большая доля вины от моего POV связана с C, но C - не единственный проект, который не может ожидать его перехода на другие платформы. Обвинять Билла Гейтса - просто чокнутый - все, что он делал, это покупал и полировал вариант тогдашнего популярного CP / M. На самом деле, это просто история - та же самая причина, по которой мы не знаем, какие коды символов от 128 до 255 относятся к большинству текстовых файлов. Учитывая простоту работы со всеми тремя соглашениями о конце строки, странно, что некоторые разработчики все еще настаивают на том, что «соглашение о моих платформах - единственный верный путь, и я навязываю его вам, нравится вам это или нет».
Кроме того, заменит ли кодовая точка Unicode U + 2028 все эти условные обозначения в будущих текстовых файлах? ; -)
В википедии есть довольно длинная статья об окончаниях строк. Раздел «История» отвечает хотя бы на часть вашего вопроса: http://en.wikipedia.org/wiki/Newline#History
Интересно отметить, что CRLF - это в значительной степени интернет-стандарт. То есть почти каждый стандартный интернет-протокол, который ориентирован на линию, использует CRLF. SMTP, POP, IMAP, NNTP и т. Д. Тело электронной почты состоит из строк, оканчивающихся CRLF.