Что на самом деле означает «Content-type: application / json; charset = utf-8»?

Question

Когда я делаю POST-запрос с телом JSON для моей службы REST, я включаю Content-type: application/json; charset=utf-8 в заголовок сообщения.Без этого заголовка я получаю ошибку от сервиса.Я также могу успешно использовать Content-type: application/json без части ;charset=utf-8.

Что именно делает charset=utf-8?Я знаю, что это определяет кодировку символов, но сервис работает без него.Эта кодировка ограничивает символы, которые могут быть в теле сообщения?

Answer 1

Заголовок просто обозначает то, во что закодирован контент. Не обязательно можно определить тип контента из самого контента, то есть вы не можете просто смотреть на контент и знать, что с ним делать. Для этого и нужны HTTP-заголовки, они сообщают получателю, с каким контентом они (предположительно) имеют дело.

Content-type: application/json; charset=utf-8 обозначает содержимое в формате JSON, закодированное в кодировке символов UTF-8. Назначение кодировки несколько избыточно для JSON, поскольку кодировка по умолчанию (только?) Для JSON - UTF-8. Таким образом, в этом случае принимающий сервер, очевидно, счастлив, зная, что имеет дело с JSON, и предполагает, что кодировка UTF-8 по умолчанию, поэтому он работает с заголовком или без него.

Ограничивает ли эта кодировка символы, которые могут быть в теле сообщения?

Нет. Вы можете отправить все, что вы хотите в заголовке и теле. Но, если два не совпадают, вы можете получить неправильные результаты. Если вы укажете в заголовке, что контент имеет кодировку UTF-8, но на самом деле вы отправляете контент с кодировкой Latin1, получатель может выдавать ненужные данные, пытаясь интерпретировать данные с кодировкой Latin1 как UTF-8. Если, конечно, вы указываете, что отправляете данные в кодировке Latin1, и на самом деле это делаете, то да, вы ограничены 256 символами, которые вы можете кодировать в Latin1.

Answer 2

Для обоснования утверждения @ deceze о кодировке JSON по умолчанию UTF-8 ...

С IETF RFC4627 :

JSON-текст ДОЛЖЕН быть закодированв Юникоде.Кодировка по умолчанию - UTF-8.

Поскольку первые два символа текста JSON всегда будут символами ASCII [RFC0020], можно определить, является ли поток октетов UTF-8, UTF-16 (BE или LE) или UTF-32 (BE или LE), взглянув на комбинацию нулей в первых четырех октетах.

      00 00 00 xx  UTF-32BE
      00 xx 00 xx  UTF-16BE
      xx 00 00 00  UTF-32LE
      xx 00 xx 00  UTF-16LE
      xx xx xx xx  UTF-8

Answer 3

Обратите внимание, что IETF RFC4627 заменено на IETF RFC7158 .В разделе [8.1] он возвращает текст, цитируемый @Drew ранее, говоря:

Implementations MUST NOT add a byte order mark to the beginning of a JSON text.

Answer 4

Реализация Dart http обрабатывает байты благодаря этому "charset = utf-8", поэтому я уверен, что несколько реализаций поддерживают это, чтобы избежать "латинского-1" запасного набора символов при чтении байтов из ответа.В моем случае я полностью теряю формат в строке тела ответа, поэтому мне приходится вручную кодировать байты в utf8 или добавлять этот параметр «inner» заголовка в ответ API моего сервера.

Answer 5

Я полностью согласен с @deceze, но хочу развить это "Я получаю ошибку от службы" часть вопроса,

Мы получаем такие ошибки как http 415

Http 415 Неподдерживаемая ошибка типа носителя

Код ответа об ошибке клиента HTTP 415 Unsupported Media Type указывает, что сервер отказывается принять запрос, потому что формат полезной нагрузки находится в неподдерживаемом формате.

Проблема с форматированием может быть связана с указанием в запросе Content-Type или Content-Encoding или из-за прямой проверки данных.

Другими словами, такими как https://stackoverflow.com/a/22643964/914284 в этом примере.

• Мы должны установить правильный тип контента, и мы должны принять правильный тип контента как видно Добавить Content-Type: application / json и Accept: application / json. В противном случае он примет значение по умолчанию