Тип носителя YAML?

Странно, Google для "yaml mime" дает рубиновую ссылку в качестве первого обращения с текстом / x-yaml и без упоминания application / x-yaml.

Это не правда довольно. Типы MIME, начинающиеся с text/, должны обрабатываться как ISO-8859-1, если явно не объявлен другой тип MIME (например, text/html; charset=utf-8). Типы MIME, начинающиеся с application/, обрабатываются как UTF-8, если явно не объявлен другой тип MIME. Например, text/x-yaml не может использовать символы UTF-8, в то время как text/x-yaml; charset=utf-8 и application/x-yaml могут. IIRC, это определено в RFC 3023.

@RyanParman Вы немного путаете набор символов и тип MIME. Вы правы, что text/* без явного параметра charset= считается ISO-8859-1, но вещи в application/* не обязательно являются текстовыми. (RFC, который вы связали, касается XML, не уверен, насколько он актуален.)

@RyanParman Неправда. tools.ietf.org/html/rfc6838#section-4.2.1 говорит: If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default.. Формального определения text/yaml и text/x-yaml не существует, поэтому по умолчанию используется UTF-8.

@ Танатос: Ты прав. Я это понимал, но не смог адекватно объяснить.

@aef: Я знаю, что RFC 3023 посвящен XML, но я понял, что все типы файлов в группе mime-типов «текст» неявно обрабатывались как ISO-8859-1. То же самое верно для text / plain и text / javascript. У меня сложилось впечатление, что это также применимо к text / yaml.

RFC 3023, включая обработку кодирования, был отменен в 2014 году tools.ietf.org/html/rfc7303#section-3. Правило по умолчанию для US-ASCII (примечание: не ISO-8859-1) для типов носителей text/* в RFC 2046 было отменено Regardless of what approach is chosen, all new text/* registrations MUST clearly specify how the charset is determined; relying on the US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer permitted. в tools.ietf.org/html/rfc6838#section-4.2.1 в январе 2013 года. Ни RFC 3023, ни RFC 7303 не говорят ничего общего о text/* AFAIK.

@RyanParman Итак, ваш вывод, вероятно, был тогда правильным, но вы ошибочно сослались на RFC 3023, а правило пришло из RFC 2046. Однако сегодня UTF-8 является стандартом по умолчанию для каждого типа носителя text/*, который не указывает что-то иное в своей регистрации IANA.

Он удобочитаем, но предназначен для передачи приложений ... XML находится в приложении

А также под текстом. Кажется, вам понадобятся и text / x-yaml, и application / x-yaml ... rfc-editor.org/rfc/rfc3023.txt

Как бы то ни было, это то, что понимает реализация Django TastyPie REST.

... но разве JSON тоже не читается человеком? Я думаю, было бы более последовательным называть application/yaml, как мы могли бы сказать application/json и applicaiton/xml.

Так что это будет application/vnd.yaml или text/vnd.yaml (текст кажется лучше)

Не совсем так. Единственное дерево подтипов, которое предназначено для использования без регистрации в IANA, - это x.. vnd. и prs. требуют регистрации. См. tools.ietf.org/html/rfc6838#section-3.2 и tools.ietf.org/html/rfc6838#section-3.3.

Похоже, это предложение никуда не делось по состоянию на январь 2018 года, и мои попытки связаться с автором остались без ответа.