Кодировка в URI данных

За годы, прошедшие с ознакомления с меняющимися спецификациями, я предположил, что RFC 3986 окончательно определился с кодировкой UTF-8 для последовательностей escape-октетов. То есть, если мой URI имеет %XX%YY%ZZ, я могу взять эту последовательность декодированных октетов (для любого URI в части, относящейся к схеме) и интерпретировать полученные байты как UTF-8, чтобы узнать, какая была расшифрованная информация. На практике я могу вызвать JavaScript decodeURIComponent(), который автоматически выполняет это декодирование для меня.

Затем я прочитал спецификацию для data: URIs, RFC 2397, которая включает аргумент charset, который (естественно) указывает кодировку кодированных данных, Но как это работает? Если у меня есть 2-октетная кодированная последовательность %XX%YY в моем data: URI, то charset=iso-8859-1 указывает, что два декодированных слова не должны интерпретироваться как последовательность UTF-8, а как два отдельных латинских символа (как каждый байт в ISO-8859-1 представляет собой символ)? По-видимому, RFC 2397 указывает на это, поскольку он приводит пример "греческих [sic] символов":

data:text/plain;charset=iso-8859-7,%be%fg%be

Но это означает, что JavaScript decodeURIComponent() (который предполагает кодированные октеты с кодировкой UTF-8) не может использоваться для извлечения строки из URI данных, правильно? Означает ли это, что я должен создать собственное декодирование для URI данных, если кодировка - это нечто помимо UTF-8?

Кроме того, означает ли это, что RFC 2397 теперь находится в конфликте с RFC 3986, что, по-видимому, указывает на то, что UTF-8 предполагается? Или RFC 3986 ссылается только на "новую схему URI [s]", что означает, что схема URI data: получает grandfathered in и имеет свой собственный метод определения того, что означает кодированные октеты?

Мое лучшее предположение на данный момент состоит в том, что data: играет по своим собственным правилам, и если он указывает кодировку, отличную от UTF-8, мне придется использовать в JavaScript что-то отличное от decodeURIComponent(). Любые рекомендации по методу замены также приветствуются.

+8
источник поделиться
1 ответ

Помните, что схема URI data: описывает ресурс, который можно рассматривать как файл, который состоит из непрозрачного байта, как если бы это был URI http: (тот же самый поток, но сохраненный на HTTP-сервере) или ftp: URI (тот же самый поток, но сохраненный на FTP-сервере) или URI file: (тот же самый поток, но сохраненный в вашей локальной файловой системе). Только метаданные, прикрепленные к файлу, дают значение bytestream.

RFC 2397 дает четкую спецификацию о том, как этот байтовый поток должен быть встроен в сам URI (в отличие от других схем URI, где URI дает инструкции о том, где взять байтовый поток, а не то, что он содержит). Это может быть base64, или это может быть метод процентного кодирования, указанный в RFC. Base64 будет более компактным, если в байтовом потоке содержатся man файлы, отличные от ASCII-байтов.

URI data: также описывает свой собственный Content-Type, который дает предполагаемую интерпретацию байтового потока. В этом случае, поскольку вы использовали text/plain;charset=iso-8859-7, байты должны быть правильно закодированы в тексте ISO-8859-7. Байты определенно не будут определены как UTF-8 или любая другая кодировка символов. Он будет недвусмысленно декодироваться с использованием кодировки символов, которую вы указали.

+5
источник

Посмотрите другие вопросы по меткам или Задайте вопрос