Можно ли использовать параметр charset с типом контента application/json в http/1.1?

Например, это действительный запрос ajax:

$.ajax({
    type: "POST",
    url: "SomePage.aspx/GetSomeObjects",
    contentType: "application/json; charset=utf-8",
    ...
});

Это иногда используется как пример или программное обеспечение может перерыв без явной кодировки.

rfc 4627 для типа application/json говорит, что он не принимает никаких параметров в разделе 6:

The MIME media type for JSON text is application/json.

Type name: application

Subtype name: json

Required parameters: n/a

Optional parameters: n/a

Можно интерпретировать, что кодировку не следует использовать с приложением /json.

И раздел 3 предлагает что нет необходимости указывать кодировку:

JSON text SHALL be encoded in Unicode.  The default encoding is
UTF-8.

Since the first two characters of a JSON text will always be ASCII
characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.

        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

потому что кодировки UTF-8,16,32 могут быть выведены из содержимого. Почему он говорит, что UTF-8 по умолчанию? Способ выбора другой кодировки символов не указан в rfc, и кодировка может быть найдена детерминистически в любом случае. Или существуют другие (не UTF-8,16,32) кодировки символов, которые поддерживают Unicode?

Некоторые утверждают, что charset можно использовать:

Я не согласен с вашей оценкой, что ее нужно удалить. RFC 2046 что "другие типы медиа, кроме подтипов" текста ", могут выбрать используйте параметр charset, как определено здесь", что указывает на то, что нет ограничений на наличие параметра charset на типы приложений. Кроме того, в RFC 2045 указано, что "MIME реализации должны игнорировать любые параметры, имена которых они не признать". Поэтому неразумно предположить, что существует какой-либо вред делая его присутствие.

May rfc-совместимое программное обеспечение генерирует приложение типа контента /json с параметром charset? Должно ли программное обеспечение, совместимое с rfc, принимать такие запросы?

Ответ 1

Недавний json rfc 7159 говорит:

Примечание. Для этой регистрации не задан параметр "charset".
      Добавление одного действительно не влияет на совместимых получателей.

i.e., charset должен быть проигнорирован совместимыми получателями.

Это согласуется с rfc 2045: "Реализации MIME должны игнорировать любые параметры, имена которых они не распознают". потому что rfc 7159 все еще указывает: "Обязательные параметры: n/a; Необязательные параметры: n/a" для типа приложения /json mime media (без параметров).

Текст json больше не привязан к объекту или массиву, а старый раздел 3, который вычисляет кодировку символов на основе первые два символа ушли в новый rfc. UTF-8, UTF-16 или UTF-32 разрешены, но нет способа указать кодировку (нет спецификации, UTF-8 по умолчанию).

Можно использовать параметр charset с типом содержимого application/json в http/1.1?

Нет вреда, если используется charset="utf-8" - utf-8 является кодировкой по умолчанию для текста json, но другие значения могут вводить в заблуждение, поскольку значение должно игнорироваться получателями-совместимыми. Это может только сломать клиентов, которые неправильно обрабатывают заголовок Content-Type, например сравнивая его дословно с "application/json" или клиентами, которые пытаются использовать не что-то вроде utf-8 кодирование для декодирования json-текста.

May rfc-совместимое программное обеспечение генерирует приложение типа контента /json с параметром charset?

нет. Для приложения /json не определены параметры.

Должно ли программное обеспечение, совместимое с rfc, принимать такие запросы?

да, это должно быть. Значение charset должно игнорироваться.


ECMA-404 (формат обмена данными JSON) определяет текст json в терминах кодовых точек Unicode, то есть сам json не указывает на поведение, связанное с деталями кодирования.

ECMA-262 (спецификация языка ECMAScript) также определяет формат json поверх String (тип Unicode).

Ответ 2

application/json не определяет параметр charset, поэтому его некорректно включать. Что RFC 2046 говорит, что типы приложений вообще могут иметь параметр charset, например application/xml. Но JSON этого не делает.

Ответ 3

Должно ли программное обеспечение, совместимое с rfc, принимать такие запросы?

По словам Джулиана Решке, ответ, видимо, нет. Однако, как вы указали, , вы потенциально столкнетесь с этим в дикой природе, а затем вам придется справляться с ней, если вы хотите поговорить с теми не совместимыми с rfc хостами.

Во-первых, если у вас есть код, который обрабатывает Accept-Charset и часть кодировки типов контента для текстовых сообщений в вашей инфраструктуре HTTP, почему бы просто не использовать ее для JSON? Программируя, это проще (нет специального правила для json) и более общего.

Лично я бы сказал, отпустите Unicode (используя кодирование, которое вы указываете) для каждого фрагмента текста. К сожалению, есть клиентские устройства, например. Японские мобильные телефоны, , которые не обрабатывают Unicode, но только Shift_JIS. В противном случае они были бы счастливы потребителями JSON (и платят клиентам). Итак, что ты собираешься делать? В моем конкретном случае, чтобы получить этих клиентов на борту, я настроил кодировку с помощью стандартных HTTP-механизмов.

На стороне примечания, HTTP 2.0 сейчас работает, и если ребята когда-либо надеются создать стандарт, который жестко соблюдается, им придется писать приемочные тесты. Конечно, это также означает исключение вышеупомянутых унаследованных клиентов, если правила не могут быть согнуты время от времени.

И какой смысл быть послушным, если никто другой, кроме вас? Интересно, совместим ли даже Opera или, если на то пошло, если все RFC, которые он реализует, можно однозначно интерпретировать в первую очередь. Я так не думаю, особенно в случае более крупных, таких как HTTP.

Если это звучит как HTTP-трещина, позвольте мне просто сказать следующее: HTTP - отличный стандарт с концепциями, которые произвели революцию не только в Интернете. Способ, например. указываются ресурсы (безгражданство) или способ кэширования, установлены хорошие шаблоны, которые просочились в реализации многих приложений. И HTTP 2 мог забрать, где 1.1 остановился. Надеюсь, что SPDY не будет принят с 1 по 1. Я не хочу этого говорить, но в этом случае Microsoft HTTP Speed ​​+ Mobility во многом больше HTTP-ey, чем Google PUSHy (и в случае unRESTy) SPDY.