Разрешают ли цитируемые параметры типа мультимедиа MIME экранировать кавычки? - PullRequest
4 голосов
/ 20 января 2020

Для типа носителя Inte rnet MIME ( RF C 6838 ) может указываться параметр ( RF C 2045 ). Например, следующее представляет значение foobar:

text/plain;test="foobar"

Но разрешено ли мне включать экранированную кавычку внутри параметра в кавычках? Следующее будет представлять значение foo"bar:

text/plain;test="foo\"bar"

Если так, то как насчет экранированного escape-символа? Следующее будет представлять значение foo\bar:

text/plain;test="foo\\bar"

А как насчет произвольно экранированных символов? Следующее будет представлять значение fooxbar, потому что escape-последовательность \x будет просто представлять x:

text/plain;test="foo\xbar"

И не менее важно, какой стандарт (ы) определяет это?

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

1 Ответ

1 голос
/ 24 января 2020

У меня пока нет полного ответа, но я знаю, что WhatWG сообщает , что значение параметра типа MIME должно содержать кодовые точки токена строки HTTP в кавычках . Хотя он предоставляет свои собственные определения, WhatWG ссылается на RF C 7230 § 3.2.6. Компоненты значения поля , что позволяет почти любое экранирование:

quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
obs-text       = %x80-FF
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

Однако он отмечает:

Отправителю НЕ СЛЕДУЕТ генерировать пару в кавычках, кроме при необходимости следует указывать DQUOTE и backsla sh октетов, встречающихся в этой строке.

Обратите также внимание, что RF C 5322 § 3.2.1. Процитированные символы также имеют некоторые правила. RF C 6838 упоминает типы носителей RF C 6532 § 3.2. Расширения синтаксиса к RF C 5322 , хотя не совсем ясно в контексте значений параметров.

...