Przez lata od czytania zmieniających się specyfikacji założyłem, że ostatecznie RFC 3986 ustaliło kodowanie UTF-8 dla sekwencji oktetu ucieczki. Oznacza to, że jeśli mój identyfikator URI ma %XX%YY%ZZ, mogę wziąć tę sekwencję zdekodowanych oktetów (dla dowolnego URI w części specyficznej dla schematu) i zinterpretować wynikowe bajty jako UTF-8, aby dowiedzieć się, jakie zamierzone były odkodowane informacje. W praktyce mogę nazwać JavaScript decodeURIComponent(), który automatycznie wykonuje to dekodowanie.Charset w danych URI
Następnie czytałem specyfikację dla data: identyfikatorów URI, RFC 2397, który zawiera argument charset, który (oczywiście) wskazuje zestaw znaków zakodowanych danych. Ale jak to działa? Jeśli mam kodowaną w dwóch oktetach sekwencję %XX%YY w moim identyfikatorze URI data:, to czy charset=iso-8859-1 wskazuje, że dwa dekodowane liczby ósemkowe powinny być interpretowane jako sekwencja UTF-8, ale jako dwa oddzielne znaki łacińskie (jak każdy bajt w ISO). -8859-1 reprezentuje postać)? RFC 2397 wydaje się wskazywać, jak to pokazuje przykład „greckiego [sic!] Znaków”:
data:text/plain;charset=iso-8859-7,%be%fg%be
Oznacza to jednak, że JavaScript decodeURIComponent() (co zakłada UTF-8 oktetów) nie mogą być stosowane do wyodrębniania ciąg znaków z identyfikatora URI danych, poprawny? Czy to oznacza, że muszę utworzyć własne dekodowanie dla identyfikatorów URI danych, jeśli zestaw znaków jest czymś poza UTF-8?
Co więcej, czy oznacza to, że RFC 2397 jest teraz w konflikcie z RFC 3986, co wydaje się wskazywać, że przyjęto kodowanie UTF-8? Czy też RFC 3986 odwołuje się tylko do "nowego schematu URI [s]", co oznacza, że schemat URI data: zostaje wtopiony i ma własną technikę określania znaczenia zakodowanych oktetów?
Moim zdaniem w tej chwili domyślam się, że data: odtwarza według własnych reguł i jeśli wskazuje na zestaw znaków inny niż UTF-8, będę musiał użyć czegoś innego niż decodeURIComponent() w JavaScript. Wszelkie zalecenia dotyczące metody zastępowania również byłyby mile widziane.