Set di caratteri nell'URI dei dati

Question

Nel corso degli anni dalla lettura delle specifiche in evoluzione, avevo assunto che lo RFC 3986 si fosse finalmente risolto con la codifica UTF-8 per le sequenze dell'ottetto di escape. Cioè, se il mio URI ha %XX%YY%ZZ posso prendere quella sequenza di ottetti decodificati (per qualsiasi URI nella parte specifica dello schema) e interpretare i byte risultanti come UTF-8 per scoprire quali informazioni decodificate erano destinate. In termini pratici, posso chiamare JavaScript decodeURIComponent() che esegue automaticamente questa decodifica per me.

poi ho letto le specifiche per data: URI, RFC 2397, che include un argomento charset, che (ovviamente) indica il set di caratteri dei dati codificati. Ma come funziona? Se nella sequenza data: URI è presente una sequenza codificata a due ottetti, nell'indice data: viene indicato che i due ottetti decodificati devono essere non interpretati come una sequenza UTF-8, ma come due caratteri latini separati (come ogni byte in ISO -8859-1 rappresenta un personaggio)? RFC 2397 sembra indicare questo, in quanto fornisce un esempio di "[sic] caratteri greci":

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

Ma questo significa che JavaScript decodeURIComponent() (che assume ottetti codificati UTF-8) non può essere utilizzato per estrarre una stringa da un URI di dati, corretta? Questo significa che devo creare la mia decodifica per gli URI dei dati se il set di caratteri è qualcosa oltre all'UTF-8?

Inoltre, ciò significa che RFC 2397 è ora in conflitto con RFC 3986, che sembra indicare che UTF-8 è assunto? Oppure la RFC 3986 si riferisce solo a "nuovo schema URI [s]", il che significa che lo schema URI data: entra in stato di grandfather e ha la sua tecnica per specificare cosa significano gli ottetti codificati?

La mia ipotesi migliore al momento è che data: suona con le proprie regole e se indica un set di caratteri diverso da UTF-8, dovrò usare qualcosa di diverso da decodeURIComponent() in JavaScript. Sarebbe gradita qualsiasi raccomandazione su un metodo di sostituzione.

Answer 1

Ricordate che lo schema URI data: descrive una risorsa che può essere pensato come un file che è costituito da un bytestream opaca proprio come se si trattasse di un http: URI (lo stesso bytestream, ma memorizzati su un server HTTP) o un ftp: URI (lo stesso puntatore, ma memorizzato su un server FTP) o un URI file: (lo stesso puntatore, ma memorizzato sul filesystem locale). Solo i metadati allegati al file danno il significato di bytestream.

RFC 2397 fornisce una chiara specifica su come questa estensione deve essere incorporata nell'URI stesso (in contrasto con altri schemi di URI, in cui l'URI fornisce istruzioni su dove recuperare l'attestazione, non ciò che esso contiene). Potrebbe essere base64 o potrebbe essere il metodo di codifica percentuale fornito nella RFC. Base64 sarà più compatto se il documento a byte contiene byte non ASCII.

L'URI data: descrive anche il proprio Content-Type, che fornisce l'interpretazione prevista dell'antimest. In questo caso, dal momento che hai utilizzato text/plain;charset=iso-8859-7, i byte devono essere codificati correttamente nel testo ISO-8859-7. I byte saranno sicuramente non essere decisi come UTF-8 o qualsiasi altra codifica di caratteri. Sarà decifrato in modo univoco usando la codifica dei caratteri che hai specificato.