Über die Jahre nach dem Lesen der sich entwickelnden Spezifikationen hatte ich angenommen, dass RFC 3986 sich schließlich auf UTF-8 festgelegt hatte Kodierung für Escape-Oktett-Sequenzen. Das heißt, wenn mein URI %XX%YY%ZZ hat, kann ich diese Sequenz von decodierten Oktetts (für jeden URI im schemaspezifischen Teil) nehmen und die resultierenden Bytes als UTF-8 interpretieren, um herauszufinden, welche dekodierten Informationen gemeint waren. In der Praxis kann ich JavaScript decodeURIComponent() nennen, was diese Dekodierung automatisch für mich macht.
Dann lese ich die Spezifikation für data: URIs, RFC 2397 , die ein Argument charset enthält , die (natürlich) den Zeichensatz der codierten Daten anzeigt. Aber wie funktioniert das? Wenn ich eine 2-Oktett-codierte Sequenz %XX%YY in meinem data: URI habe, zeigt ein charset=iso-8859-1 an, dass die beiden dekodierten Oktette nicht als UTF-8-Sequenz interpretiert werden sollten, sondern als als zwei separate lateinische Zeichen (da jedes Byte in ISO-8859-1 ein Zeichen darstellt)? RFC 2397 scheint dies anzuzeigen, da es ein Beispiel für "griechische [sic] Zeichen" gibt:
Aber das bedeutet, dass JavaScript decodeURIComponent() (das UTF-8-codierte Oktetts annimmt) nicht verwendet werden kann, um eine Zeichenfolge aus einem Daten-URI zu extrahieren, richtig? Bedeutet das, dass ich meine eigene Dekodierung für Daten-URIs erstellen muss, wenn der Zeichensatz etwas neben UTF-8 ist?
Außerdem bedeutet das, dass RFC 2397 nun mit RFC 3986 in Konflikt steht, was darauf hindeutet, dass UTF-8 angenommen wird? Oder bezieht sich RFC 3986 nur auf "neue URI-Schemata [s]", was bedeutet, dass das Schema data: URI grandfathered ist und eine eigene Technik hat, um zu spezifizieren, was die codierten Oktette bedeuten?
Meine beste Schätzung im Moment ist, dass data: nach seinen eigenen Regeln spielt und wenn es einen anderen Zeichensatz als UTF-8 anzeigt, muss ich etwas anderes als decodeURIComponent() in JavaScript verwenden. Empfehlungen zu einer Ersatzmethode wären ebenfalls willkommen.
Denken Sie daran, dass das data: URI-Schema eine Ressource beschreibt, die man sich als eine Datei vorstellen kann, die aus einem undurchsichtigen Bytestream besteht, so als wäre es ein http: URI (derselbe Bytestrom, aber auf einem HTTP-Server gespeichert) oder ein ftp: URI (derselbe Bytestrom, aber auf einem FTP-Server gespeichert) oder ein file: URI (derselbe Bytestrom, aber in Ihrem lokalen Dateisystem gespeichert). Nur die an die Datei angehängten Metadaten geben dem Bytestrom die Bedeutung.
RFC 2397 gibt eine klare Spezifikation darüber, wie dieser Bytestrom in den URI selbst eingebettet werden soll (im Gegensatz zu anderen URI-Schemata, wo der URI Anweisungen gibt, wo der Bytestrom abgerufen werden soll, nicht was er enthält). Es könnte base64 sein, oder es könnte die prozentuale Kodierungsmethode sein, die im RFC angegeben ist. Base64 wird kompakter sein, wenn der Bytestream Man-Nicht-ASCII-Bytes enthält.
Der data: URI beschreibt auch seinen eigenen Inhaltstyp, der die beabsichtigte Interpretation des Bytestroms ergibt. In diesem Fall müssen Sie, da Sie text/plain;charset=iso-8859-7 verwendet haben, den korrekten ISO-8859-7-Text verwenden. Die Bytes werden definitiv nicht als UTF-8 oder irgendeine andere Zeichencodierung entschieden. Es wird mit der von Ihnen angegebenen Zeichencodierung eindeutig decodiert.
Tags und Links character-encoding utf-8 url-encoding rfc uri