UTF-8을 사용한 XML 문서 인코딩에 대한 자세한 소개

Google의 사이트맵 서비스를 사용하려면 게시된 모든 사이트 지도 가 유니코드 UTF-8로 인코딩되어야 합니다. Google은 ISO-8859-1과 같은 비유니코드 인코딩은 물론 UTF-16과 같은 다른 유니코드 인코딩도 허용하지 않습니다. 기술적으로 이는 Google이 비표준 XML 파서를 사용하고 있음을 의미합니다. XML 권장사항에서는 "모든 XML 핸들러는 유니코드 3.1의 UTF-8 및 UTF-16 인코딩을 허용해야 합니다"라고 구체적으로 요구하고 있기 때문입니다. 정말 큰 문제야?

누구나 UTF-8을 사용할 수 있습니다

UTF-8을 선택하는 첫 번째이자 가장 강력한 이유는 보편성입니다. 현재 전 세계에서 사용되는 모든 스크립트를 처리할 수 있습니다. 아직 약간의 공백이 있지만 점점 덜 명확해지고 점차 채워지고 있습니다. 포함되지 않은 텍스트는 일반적으로 다른 문자 집합에서 구현되지 않으며 구현되어 있어도 XML에서 사용할 수 없습니다. 가장 좋은 경우 이러한 스크립트는 글꼴 차용을 통해 Latin-1과 같은 단일 바이트 문자 집합으로 전달됩니다. 이러한 희귀한 스크립트에 대한 실제 지원은 아마도 유니코드에서 먼저 나올 것이며 아마도 유니코드만이 이를 지원할 것입니다.

그러나 이는 유니코드를 사용하는 이유 중 하나일 뿐입니다. UTF-16이나 다른 유니코드 인코딩 대신 UTF-8을 선택하는 이유는 무엇입니까? 가장 즉각적인 이유 중 하나는 광범위한 도구 지원입니다. 기본적으로 JEdit, BBEdit, Eclipse, emacs, 심지어 Notepad를 포함하여 XML용으로 사용 가능한 모든 주요 편집기는 UTF-8을 처리할 수 있습니다. 다른 어떤 유니코드 인코딩도 XML 도구와 비XML 도구 중에서 이렇게 광범위한 도구를 지원하지 않습니다.

BBEdit 및 Eclipse와 같은 일부 편집기의 경우 UTF-8이 기본 문자 집합이 아닙니다. 이제 기본 설정을 변경해야 합니다. 모든 도구는 공장에서 배송될 때 기본 인코딩으로 UTF-8을 선택해야 합니다. 이것이 완료되지 않으면 파일이 국경, 플랫폼, 언어를 넘어 이동할 때 우리는 비상호운용성의 수렁에 빠지게 될 것입니다. 그러나 모든 프로그램이 UTF-8을 기본 인코딩으로 사용할 때까지는 기본 설정을 직접 변경하는 것이 쉽습니다. 예를 들어 Eclipse에서는 그림 1에 표시된 일반/편집기 환경 설정 패널을 사용하여 모든 파일이 UTF-8을 사용하도록 지정할 수 있습니다. Eclipse에서는 기본값이 MacRoman일 것으로 예상하지만 이 경우 Microsoft® Windows®를 사용하는 프로그래머나 미국 및 서유럽 이외의 컴퓨터에 전달하면 파일이 컴파일되지 않습니다.

그림 1. Eclipse 기본 문자 집합 변경

물론 UTF-8이 작동하려면 개발자가 교환하는 모든 파일도 UTF를 사용해야 합니다. -8, 하지만 그건 문제가 되지 않습니다. MacRoman과 달리 UTF-8은 몇 가지 스크립트나 플랫폼으로 제한되지 않습니다. 누구나 UTF-8을 사용할 수 있습니다. MacRoman, Latin-1, SJIS 및 기타 다양한 레거시 국가별 문자 세트는 이를 수행할 수 없습니다.

UTF-8은 멀티바이트 데이터를 지원하지 않는 도구에서도 잘 작동합니다. UTF-16과 같은 다른 유니코드 형식에는 0바이트가 많이 포함되는 경향이 있습니다. 많은 도구는 이러한 바이트를 파일 끝 또는 기타 특수 구분 기호로 해석하여 바람직하지 않고 예상치 못한 결과를 초래하는 경우가 많습니다. 예를 들어, UTF-16 데이터가 변경되지 않은 채 C String에 로드되는 경우 문자열은 첫 번째 ASCII 문자의 두 번째 바이트에서 잘릴 수 있습니다. UTF-8 파일에는 null이 실제로 표시되는 null만 포함됩니다. 물론 XML 문서를 처리하기 위해 이러한 순진한 도구를 선택해서는 안 됩니다. 그러나 레거시 시스템의 문서는 종종 이상한 위치에 놓이게 되며, 이러한 문자 시퀀스가 ​​단지 새 병에 담긴 오래된 와인일 뿐이라는 사실을 실제로 인식하거나 이해하는 사람은 아무도 없습니다. UTF-8은 유니코드 및 XML을 지원하지 않는 시스템에 대한 UTF-16 또는 기타 유니코드 인코딩보다 문제를 일으킬 가능성이 적습니다.

전문가들의 평가

XML은 UTF-8을 완벽하게 지원하는 최초의 주요 표준이지만 이는 시작에 불과합니다. 다양한 표준 조직에서는 점차 UTF-8을 권장하고 있습니다. 예를 들어, ASCII가 아닌 문자를 포함하는 URL은 웹에서 오랫동안 지속되어 온 문제입니다. PC에서 작동하는 비ASCII 문자가 포함된 URL은 Mac에서는 작동하지 않으며 그 반대의 경우도 마찬가지입니다. World Wide Web 컨소시엄(W3C)과 IETF(Internet Engineering Task Force)는 최근 모든 URL이 다른 인코딩이 아닌 UTF-8로 인코딩되어야 한다는 데 동의하여 이 문제를 해결했습니다.

W3C와 IETF는 UTF-8을 처음 사용할지, 마지막으로 사용할지, 가끔 사용할지에 대해 점점 더 까다로워지고 있습니다. World Wide Web 1.0용 W3C 문자 모델: 기본에서는 "문자 인코딩을 선택해야 하는 경우 UTF-8, UTF-16 또는 UTF-32여야 합니다. US-ASCII는 UTF-8( US-ASCII 문자열도 UTF-8 문자열입니다([RFC 3629] 참조). 따라서 US-ASCII와의 호환성이 필요한 경우 UTF-8이 매우 적합합니다. "사실 US-ASCII와의 호환성은 매우 중요합니다. 거의 필수. W3C는 "API의 경우 UTF-16 또는 UTF-32가 더 적합할 수 있습니다. 하나의 인코딩을 선택하는 이유에는 내부 처리 효율성 및 다른 프로세스와의 상호 운용성이 포함될 수 있습니다."라고 현명하게 설명합니다. >내부처리 효율성의 이유에 동의합니다. 예를 들어, Java™ 언어에서 문자열의 내부 표현은 UTF-16이므로 문자열 인덱싱이 더 빠릅니다. 그러나 Java 코드는 데이터를 교환하는 프로그램에 이 내부 표현을 노출하지 않습니다. 대신 외부 데이터 교환의 경우 java.io.Writer를 사용하여 문자 집합을 명시적으로 지정합니다. 선택할 때 UTF-8을 적극 권장합니다.

IETF는 더욱 명시적입니다. IETF 문자 세트 정책 [RFC 2277]에는 불확실성이 없는 언어에서

프로토콜은 ISO 10646 인코딩 세트와 UTF-8 문자로 구성된 UTF-8 문자 세트를 사용할 수 있어야 한다고 명시되어 있습니다. 인코딩 방법, 전체 텍스트는 [10646] Annex R(개정 2에서 발표됨)을 참조하세요.

또한 프로토콜은 UTF-16과 같은 다른 ISO 10646 문자 집합 및 문자 인코딩 체계를 사용하는 방법을 지정할 수 있지만 UTF-8을 사용할 수 없는 것은 이 정책을 위반하는 것입니다. 이 과정에서 변경 절차([BCP9] 섹션 9)를 거쳐 프로토콜 사양 문서에 명확하고 신뢰할 수 있는 이유를 제공해야 합니다.

기존 프로토콜 또는 기존 데이터 저장소에서 데이터를 전송하기 위한 프로토콜은 다른

데이터 세트

를 지원하거나 UTF-8 이외의 기본 인코딩을 사용해야 할 수도 있습니다. 이는 허용되지만 UTF-8을 지원할 수 있어야 합니다. 포인트: 레거시 프로토콜 및 파일을 지원하려면 당분간 UTF-8 이외의 문자 세트 및 인코딩을 허용해야 할 수도 있지만, 그럴 경우에는 매우 주의해야 합니다. 모든 새로운 프로토콜, 애플리케이션 및 문서는 UTF-8을 사용해야 합니다.

중국어, 일본어, 한국어

일반적인 오해는 UTF-8이 압축 형식이라는 것입니다. 이것은 사실이 아닙니다. UTF-8에서 ASCII 문자는 다른 유니코드 인코딩, 특히 UTF-16에 비해 공간의 절반만 차지합니다. 그러나 일부 문자, 특히 중국어, 일본어, 한국어(CJK)와 같은 상형 문자의 UTF-8 인코딩은 50% 더 많은 공간을 차지합니다.

그러나 CJK XML을 UTF-8로 인코딩하더라도 실제 크기는 UTF-16보다 작을 수 있습니다. 예를 들어 중국어 XML 문서에는 , &, =, ", ' 및 공백과 같은 많은 수의 ASCII 문자가 포함되어 있습니다. 이러한 문자의 UTF-8 인코딩은 UTF-16보다 작습니다. 특정 압축 /확장 인자는 문서에 따라 다르지만 어느 경우든 차이가 눈에 띄지 않을 것입니다

마지막으로 알파벳과 같은 문자에 비해 중국어, 일본어와 같은 상형 문자는 문자를 사용한다는 점을 언급할 가치가 있습니다. 라틴어 및 키릴 문자와 같이 문자 수가 너무 많기 때문에 이러한 언어를 완전히 표현하려면 문자당 3바이트 이상이 필요합니다. 즉, 영어나 러시아어의 동일한 단어나 문장에 비해 더 적은 수로 표현할 수 있습니다. 예를 들어, "tree"는 일본어로 "wood"로 표시되며(tree와 매우 유사) UTF-8에서는 3바이트가 필요하지만, 영어 단어 "tree"에는 4바이트가 필요합니다. 단어 "grove"는 "rim"(두 개의 나무가 서로 가까이 있음)입니다. UTF-8을 사용하여 인코딩하려면 3바이트가 필요한 반면, 영어 단어 "grove"에는 5개의 문자가 필요합니다. 여전히 3바이트가 필요하지만 해당 영어 단어 "forest"에는 6바이트가 필요합니다. 압축 후에는 UTF-8과 UTF-16의 크기가 비슷합니다. 인코딩에 관계없이 원본 크기가 클수록 압축 알고리즘에 의해 제거되는 중복성이 줄어듭니다.

견고함

실제 장점은 UTF-8입니다. UTF-8은 이전이나 이후에 고안된 다른 텍스트 인코딩보다 더 강력하고 해석하기 쉽습니다. 우선, UTF-8은 엔디안 문제가 없습니다. UTF-8은 16비트 단어가 아닌 8비트 바이트를 기반으로 하기 때문에 엔디안 및 리틀 엔디안입니다. UTF-8에는 엔디안 플래그 또는 기타 휴리스틱을 통해 해결해야 하는 엔디안 모호성이 없습니다.

UTF-8의 가장 중요한 기능 중 하나는 무국적입니다. UTF-8 스트림 또는 시퀀스의 모든 바이트는 명확합니다. UTF-8에서는 항상 위치를 알 수 있습니다. 즉, 바이트가 주어지면 그것이 단일 바이트 문자인지, 더블 바이트 문자의 첫 번째 바이트인지, 아니면 문자의 첫 번째 바이트인지 즉시 확인할 수 있습니다. 2바이트 문자 3바이트/4바이트 문자의 두 번째 바이트 또는 두 번째, 세 번째 또는 네 번째 바이트(물론 다른 가능성도 있지만 이해하실 수 있습니다). UTF-16에서는 "0x41" 바이트가 문자 "A"인지 확인하는 것이 불가능합니다. 그럴 때도 있고 그렇지 않을 때도 있습니다. 흐름의 위치를 ​​결정하려면 충분한 상태를 기록해야 합니다. 1바이트가 손실되면 이후의 모든 데이터를 사용할 수 없게 됩니다. UTF-8에서는 누락되거나 손상된 바이트를 쉽게 확인할 수 있으며 다른 데이터에 영향을 주지 않습니다.

UTF-8은 만병통치약이 아닙니다. 문서의 특정 위치에 대한 임의 액세스가 필요한 애플리케이션은 UCS2 또는 UTF-32와 같은 고정 너비 인코딩을 사용하여 더 빠르게 작동할 수 있습니다. (대체 쌍을 고려하면 UTF-16은 가변 길이 문자 인코딩입니다.) 그러나 XML 처리는 이 응용 프로그램 범주에 속하지 않습니다. XML 사양에서는 특히 파서가 XML 문서의 첫 번째 바이트부터 마지막 ​​바이트까지 파싱을 시작하도록 요구하고 있으며 기존의 모든 파서가 이를 수행합니다. 더 빠른 임의 액세스는 XML 처리에 도움이 되지 않으며 데이터베이스나 다른 시스템이 다른 인코딩을 사용하는 데에는 좋은 이유가 될 수 있지만 XML에는 적용되지 않습니다.

결론

점점 국제화되는 세계에서 언어와 정치적 경계는 모호해지고, 지역에 의존하는 문자 집합은 더 이상 적용되지 않습니다. 유니코드는 여러 지역에서 상호 운용할 수 있는 유일한 문자 집합입니다. UTF-8은 사용 가능한 최고의 유니코드 인코딩입니다.

레거시 ASCII 시스템과의 동급 최고의 호환성을 포함하여 광범위한 도구 지원.

취급이 쉽고 효율적입니다.

반부패.

플랫폼 독립적.

이제 문자 집합과 인코딩에 대한 논쟁을 멈추고 UTF-8을 선택하고 논쟁을 끝낼 때입니다.

위 내용은 UTF-8을 사용한 XML 문서 인코딩에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!