developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

UTF-8으로 XML 문서 인코딩하기

(힌트: 사이즈와는 관계 없음)

Elliotte Harold, 교수, Polytechnic University

Elliotte Rusty Harold는 뉴 올리언즈 태생이다. 원조 검프 스프 맛을 찾아 뉴 올리언즈를 자주 방문하지만, 현재 브룩클린 근처 프로스펙트 하이츠에서 아내 베스와 고양이 두 마리를 키우며 폴리테크닉 대학 전자계산학과 조교수로 자바와 객체 지향 프로그래밍을 강의하고 있다. 그가 운영하는 Cafe au Lait 사이트는 인터넷에서 가장 인기 있는 자바 사이트 중 하나가 되었고, 또 다른 사이트 Cafe con Leche 역시 가장 대중적인 XML 사이트 중 하나가 되었다. 올 봄에는 애디슨 웨슬리 출판사를 통해 Refactoring HTML을 출판할 예정이다.

요약： Unicode는 오늘날 이 지구상에 존재하는 모든 중요한 전산 문자 세트 중 으뜸이라 할 수 있다. UTF-8은 Unicode 문자 세트를 적절하게 바이너리 인코딩 한 것이다. 이 글은, 모든 XML 문서가 UTF-8에서만 독점적으로 생성되어야 한다고 주장한다. 보장할 수 있는 결과는 보다 강력한, 상호 운용성이 향상된 문서의 세계이다.

여기에 태그 달기!

기사 게재일： 2005 년 8 월 30 일
난이도： 초급
페이지뷰： 2640 회
의견：

Google의 사이트맵 서비스는 최근 XML 커뮤니티에 작은 반향을 일으켰다. 모든 사이트맵이 Unicode의 UTF-8 인코딩으로만 퍼블리시 될 것을 요구했던 것이다. Google은 UTF-16 같은 Unicode 인코딩 대안 조차도 허용하지 않았다. ISO-8859-1 같은 비 Unicode 인코딩은 더 말할 나위도 없다. 기술적으로, Google은 비순응 XML 파서를 사용하고 있다는 것을 의미한다. 왜냐하면 XML Recommendation에서는 "모든 XML 프로세서는 Unicode 3.1의 UTF-8과 UTF-16 인코딩을 허용해야 한다." 라고 명시되어 있기 때문이다. 하지만 이것이 실제로도 큰 문제인가?

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

보편성(Universality)은 UTF-8을 선택하는 가장 중요한 이유이다. UTF-8은 이 지구상에 존재하는 대부분의 스크립트를 처리할 수 있다. 약간의 차이가 있지만, 점점 그 차이도 없어지고 있고 채워져 가고 있다. 다루어 지지 않는 스크립트가 있다면 그것은 일반적으로 다른 문자 세트에서는 구현되지 않거나, 구현되었다 하더라도 XML에서는 사용할 수 없다. Latin-1 같은 1 바이트 문자 세트에 새겨진 폰트 핵(hack)으로 다루는 것이 최상이다. 이러한 소수의 스크립트를 지원하는 것도 Unicode가 거의 유일하다.

하지만 이것은 Unicode를 사용하는 것에 대한 논쟁에 불과하다. UTF-16 이나 다른 Unicode 인코딩 대신 왜 UTF-8을 선택하는가? 가장 단순한 이유는 광범위한 툴 지원이다. XML과 함께 사용하는 대부분의 주요 에디터는 UTF-8을 비롯하여 JEdit, BBEdit, Eclipse, emacs, 심지어 Notepad 까지 핸들한다. Unicode의 어떤 다른 인코딩도 XML과 비 XML 툴 간 그렇게 광범위한 툴 지원이 되는 것은 없다.

BBEdit과 Eclipse 같은 경우, UTF-8은 디폴트 문자 세트는 아니다. 이제는 디폴트가 변해야 할 때이다. 모든 둘은 디폴트 인코딩으로 UTF-8을 갖추어야 한다. 이렇게 되지 않는 한 국가간, 플랫폼간, 언어간 파일이 전송될 때 깨지게 되는 상호운용이 불가능한 파일로 인해 곤궁에 빠지게 될 것이다. 하지만 모든 프로그램들이 기본적으로 UTF-8을 선택한다면 디폴트를 변경하기 쉽다. 예를 들어, Eclipse의 경우, 그림 1의 "General/Editors" 선택 패널에서 모든 파일을 UTF-8로 지정할 수 있다. Eclipse는 MacRoman도 기본으로 하고자 하는 것도 눈치챘을 것이다. 하지만 이를 허용하면 Microsoft® Windows®이나 미국과 서유럽 지역이 아닌 곳에서 일하고 있는 프로그래머들로 전송될 때 파일이 컴파일 되지 않을 것이다.

Figure 1. Eclipse에서 디폴트 문자 세트 변경하기
Eclipse character set preferences

물론 UTF-8이 실행되려면, 파일을 교환하고자 하는 상대편 개발자들 역시 UTF-8을 사용하고 있어야 한다. MacRoman과는 달리 UTF-8은 몇몇 스크립트와 한 개의 주요 플랫폼에만 국한되지는 않는다. UTF-8은 모든 것에 잘 작동한다. 하지만 MacRoman, Latin-1, SJIS, 기타 국가별 기존 문자 세트는 그렇지 않다.

UTF-8은 멀티바이트 데이터를 받지 않는 툴과 작동이 더 잘된다. UTF-16 같은 Unicode 포맷은 수 많은 0 바이트를 포함하고 있다. 많은 툴들이 이 바이트를 파일의 끝 또는 특정 구분자로 해석한다. 예를 들어, UTF-16 데이터가 C 스트링으로 순순히 로딩되면 이 스트링은 첫 번째 ASCII 문자의 두 번째 바이트에서 잘라진다. UTF-8 파일은 실제로 NULL을 의미하는 NULL 만을 포함하고 있다. 물론, 다른 툴로 XML 문서를 처리해서는 안된다. 하지만 문서는 종종 레거시 시스템의 이상한 장소에서 끝나게 된다. 오래된 가죽에 새로운 와인을 둘 때의 결과를 어떤 누구도 이해할 수 없는 그런 장소에 말이다. UTF-8은 UTF-16 또는 다른 Unicode 인코딩 보다는 Unicode와 XML을 인식하지 못하는 시스템에서 문제를 덜 일으킨다.

위로

스팩

XML은 UTF-8을 전적으로 받아들인 첫 번째 표준이었다. 하지만 이것은 이 기류의 시작에 불과했다. 점점 더 표준 기구들은 UTF-8을 권장하고 있다. 예를 들어, 비 ASCII 문자를 포함하고 있는 URL은 꽤 오랫동안 웹 상에서 끈질긴 문제였다. PC 상에서 작동중인 비 ASCII 문자를 포함하고 있는 URL이 Mac 상에 로딩될 때 실패한다. 그 반대의 경우도 마찬가지다. 최근 Wide Web Consortium (W3C)과 Internet Engineering Task Force (IETF)가 모든 URL이 UTF-8로 인코딩 되는 것에 동의하면서 이 문제는 줄어들었다.

W3C와 IETF는 최근 UTF-8 선택하는 데 있어 보다 확고한 입장을 취하고 있다. The W3C Character Model for the World Wide Web 1.0: Fundamentals 에 따르면, "독자적인 문자 인코딩이 필요하면 문자 인코딩은 UTF-8, UTF-16, UTF-32 등이 가능하다. US-ASCII가 UTF-8과 호환되고(US-ASCII 스트링 역시 UTF-8 스트링과 호환된다. [RFC 3629] 참조), 따라서 UTF-8은 US-ASCII와의 호환성이 필요할 경우 적절한 선택이다." 라고 명시하고 있다. 실제로 US-ASCII와의 호환성은 유용하기 때문에 거의 필수 요소이다. W3C는, "API의 경우, UTF-16 또는 UTF-32가 보다 적합하다."라고 언급하고 있다. 이들 중 하나를 선택하는 이유에는 내부 프로세싱의 효율성과 다른 프로세스들과의 상호운용성도 있다.

내부 프로세싱의 효율성에 대한 주장은 믿을 수 있다. 예를 들어, 자바에서 스트링의 내부 표현은 UTF-16에 근거하는데, 이로서 스트링으로의 인덱싱이 더욱 빨라진다. 하지만 자바 코드는 이러한 내부 표현을 프로그램에 절대 드러내지 않는다. 대신, 외부 데이터 교환일 경우 java.io.Writer 가 사용되고 문자 세트가 명확히 지정된다. 이 경우 UTF-8이 더욱 선호된다.

IETF 는 보다 더 명확하다. The IETF Charset Policy [RFC 2277]:

프로토콜은 UTF-8 charset을 사용할 수 있어야 한다. 이것은 [10646] Annex R에서 정의된 대로, UTF-8 문자 인코딩 스키마와 함께 ISO 10646 코딩의 문자 세트로 구성되어 있다. (Amendment 2)

프로토콜은 다른 charset 또는 UTF-16 같은 ISO 10646용 문자 인코딩 스키마를 사용하는 방법을 지정해야 한다. 하지만 UTF-8을 사용하는 기능이 부족하기 때문에 정책 위반이다. 이 같은 위반에는 표준에 합류하기 전에 프로토콜 스팩 문서에서의 확실한 정의가 수반되어야 하고 가변성 문제가 다루어져야 한다. ([BCP9] section 9)

기존 프로토콜 또는 기존 데이터에서 데이터를 옮기는 프로토콜의 경우, 다른 charset의 지원 또는 UTF-8 외의 다른 디폴트를 사용하는 것이 필요하다. 이 또한 수락될 수 있지만 UTF-8 지원도 가능해야 한다.

주: 기존 프로토콜과 파일이 지원되려면 앞으로 UTF-8 외의 문자 세트와 인코딩을 수락해야 할 것이다. 모든 새로운 프로토콜, 애플리케이션, 문서는 UTF-8을 사용해야 한다.

위로

중국어, 일본어, 한국어

UTF-8이 압축 포맷이라고 오해하고 있다. 그렇지 않다. ASCII 범위의 문자는 UTF-8에서 절반 정도만 차지한다. 하지만 어떤 문자의 경우 UTF-8로 인코딩 되기 위해서는 50% 이상의 공간을 필요로 한다. 특히 중국어, 일본어, 한국어(CJK) 같은 표의문자가 그렇다.

심지어 UTF-8로 CJK XML을 인코딩 할 때 UTF-16과 비교한 실제 크기는 그렇게 크지 않다. 예를 들어, 중국어 XML 문서에는 <, >, &, =, ", ', 공간 같은 많은 ASCII 문자가 포함되어 있다. 이들 모두 UTF-16 보다 UTF-8에서 더 작다. 실제 압축과 확장 요소는 다양하지만 차이는 별로 없다.

마지막으로, 중국어와 일본어 같은 표의문자 스크립트가 Latin과 Cyrillic 같은 알파벳 스크립트와 비교할 때 문자가 더 적게 든다는 것을 주목하라. 이들 문자의 대부분이 한 문자 당 세 개 이상의 바이트를 사용하여 스크립트를 표현한다. 이것이 의미하는 바는 같은 단어와 문장을 나타낼 때 영어와 러시아어 같은 언어 보다 더 적은 문자를 사용하여 나타낼 수 있다는 것이다. 예를 들어, 일본어로 나무는 木 이다. (약간 나무와 생김이 비슷하다.) 이것은 UTF-8에서는 세 개의 바이트를 차지하는 반면 영어 단어 "tree" 는 네 개의 글자와 네 개의 바이트로 구성된다. 숲을 나타내는 일본어는 林이다. (나무 두 그루가 나란히 서 있는 것과 같다.) 이것 역시 UTF-8에서는 세 개의 바이트만 차지하는 반면 영어 "grove" 는 다섯 개의 글자로 구성되어 있고 다섯 개의 바이트가 필요하다. 일본어 森는 단 세 개의 바이트만 차지한다. 하지만 이에 상응하는 영어 단어 "forest" 는 여섯 바이트가 필요하다.

이제 XML을 zip 또는 gzip으로 압축하다. 압축된 UTF-8은 크기에서 UTF-16 압축과 비슷하다. 처음 크기는 상관이 없다. 처음에 어떤 것이 더 컸든지 간에 압축 알고리즘은 무엇이든 줄이기 마련이다.

위로

강건함

디자인 측면에서 볼 때, UTF-8은 이전에 디자인 된 다른 텍스트 인코딩 보다 강력하고 상호운용성도 뛰어나다. 우선, UTF-16과는 달리, UTF-8은 endian 문제가 없다. 큰 endian이든 작은 endian이든 UTF-8은 동일하다. UTF-8은 16 비트 단어가 아닌 8 비트 바이트의 관점에서 정의되기 때문이다. UTF-8은 바이트 순서에 대한 모호성이 없다.

UTF-8에서 더 중요한 특징은 stateless이다. UTF-8 스트림 또는 시퀀스의 각 바이트는 명백하다. UTF-8에서는 당신은 어디에 있는지를 항상 알 수 있다. 주어진 하나의 바이트로 이것이 싱글 바이트 문자인지, 2 바이트 문자의 첫 번째 바이트인지, 2 바이트 문자의 두 번째 바이트인지, 세 바이트 또는 네 바이트 문자의 몇 번째 바이트인지를 즉시 결정할 수 있다. UTF-16에서 "0x41" 바이트는 글자 "A"이다. 어떤 경우는 그렇고 또 어떤 경우는 그렇지 않다. 스트림의 어디에 위치해 있는지를 알 수 있도록 충분한 상태를 지속적으로 트래킹 해야 한다. 한 개의 바이트를 잃어버리면 거기에서부터 모든 데이터가 오염된다. UTF-8에서, 소실되거나 엉망이 된 바이트는 곧 명확해지고 나머지 데이터도 오염시키지 않는다.

UTF-8이 모든 목적에 다 이상적인 것은 아니다. 문서 내의 특정 인덱스에 랜덤 액세스를 해야 하는 애플리케이션의 경우, UCS2 또는 UTF-32 같은 고정된 너비의 인코딩을 사용할 때 더 빨라진다. (UTF-16은 변화하는 문자 인코딩이기 때문에 대용 쌍이 고려되어야 한다.) 하지만 XML 프로세싱은 그러한 애플리케이션이 아니다. XML 스팩은 XML 문서의 첫 번째 바이트에서 파서가 시작하고 끝날 때 까지 파싱을 계속해야 하고, 모든 기존 파서들도 이와 같이 작동하는 것을 필요로 한다. 보다 빠른 랜덤 액세스는 XML 프로세싱을 돕지 못한다. 데이터 베이스나 다른 시스템에서 다른 인코딩을 사용하더라도 적어도 XML에는 적용되지 않는다.

위로

요약

국제화가 점점 진행되는 요즘, 언어와 정치적 경계는 날마다 흐려지고 있고 지역에 의존하는 문자 세트는 더 이상 쓸모가 없다. Unicode는 지구 상의 많은 지역에 걸쳐 상호운용 되는 유일한 문자이다. UTF-8은 그러한 Unicode에 맞는 올바른 인코딩이다.