진화하는 스펙을 읽은 지 몇 년이 지난 후에 나는 RFC 3986이 마침내 이스케이프 옥텟 시퀀스에 대해 UTF-8 인코딩으로 정착했다고 가정했었다. 즉, 내 URI가 %XX%YY%ZZ
인 경우 해당 디코딩 된 옥텟 시퀀스 (구성표 특정 부분의 모든 URI에 대해)를 가져 와서 결과 바이트를 UTF-8로 해석하여 디코딩 된 정보가 의도 된 바를 찾아 낼 수 있습니다. 실용적인면에서 필자는 자동으로이 디코딩을 수행하는 JavaScript decodeURIComponent()
을 호출 할 수 있습니다.데이터 세트의 문자 집합
data:
개의 URI 인 RFC 2397의 내용을 읽었습니다. 여기에는 charset
인수가 포함되어 있습니다. 자연히 인코딩 된 데이터의 문자 집합을 나타냅니다. 하지만 어떻게 작동합니까? 두 옥텟으로 인코딩 된 시퀀스 %XX%YY
이 내 data:
URI에있는 경우 charset=iso-8859-1
은 이 아닌이 UTF-8 시퀀스로 해석되어야 함을 나타내지 만 두 개의 별도 라틴 문자 (ISO의 각 바이트로 -8859-1은 문자를 나타냅니다)? RFC 2397는 "그리스어 [원문] 문자"의 예를 제공,이를 나타낼 것으로 보인다 :
data:text/plain;charset=iso-8859-7,%be%fg%be
를하지만이 (UTF-8 인코딩 된 옥텟을 가정) 자바 스크립트 decodeURIComponent()
추출하는 데 사용할 수 없습니다 것을 의미합니다 데이터 URI의 문자열이 맞습니까? 이것은 charset이 UTF-8 이외의 것이라면 데이터 URI에 대한 자체 디코딩을 만들어야한다는 것을 의미합니까?
또한 이것은 RFC 2397이 현재 RFC 3986과 충돌한다는 것을 의미합니까? 이는 UTF-8이 사용된다고 나타내는 것 같습니다. 아니면 RFC 3986은 data:
URI 스키마가 웅장하게 만들어지고 인코딩 된 옥텟이 의미하는 것을 지정하는 자체 기술을 가지고 있다는 것을 의미하는 "새로운 URI 스키마 [s]"만을 참조합니까?
현재 가장 좋은 추측은 data:
이 자체 규칙에 따라 재생되며 UTF-8 이외의 문자 집합을 나타내면 자바 스크립트에서 decodeURIComponent()
이외의 것을 사용해야 할 것입니다. 대체 방법에 대한 권장 사항도 환영 할 것입니다.