UTF-8 and Unicode FAQ for Unix/Linux유닉스/리눅스 사용자를 위한 UTF-8 및 유니코드 관련 FAQMarkus Kuhn( Markus.Kuhn@cl.cam.ac.uk)16 March 2001 국봉관 역( kook@hanyang.co.kr) 2001년 3월 29일이 문서는 유닉스 혹은 리눅스 환경에서 UTF-8과 유니코드를 사용하는 방법에 관한 내용을 담고 있습니다. 번역 상의 실수 혹은 오타를 발견하신 분은 메일로 연락주시기 바랍니다. 1. UCS와 ISO 10646은 무엇인가?ISO 10646국제 표준은 Universal Character Set(UCS)를 정의하고 있다. UCS는 모든 다른 종류의 문자셋 표준(character set standards)의 상위에 존재하는 문자셋이다. 이것은 다른 문자셋과의 상호 호환성을 보증한다. 만약 어떤 텍스트 문자열을 UCS로 변환하고 다시 원래의 인코딩으로 변환할 경우 어떤 정보도 손실되지 않을 것이다. ISO 10646은 공식적으로 31비트 문자셋을 정의하고 있다. 그러나 지금까지 문자들은 이러한 큰 코드 공간(of this huge code space)중에서도 오직 처음에서부터 65534번째 위치(0x0000 부터 0xFFFD까지)까지에만 위치했었다. 이러한 UCS의 16비트 서브셋은 기본 다국어 평면 (Basic Multilingual Plane : BMP) 혹은 평면 0(Plane 0)라고 부른다. BMP 영역이 아닌 곳에 인코딩되는 문자들은 상형문자와 같은 고대 문자와 학술 기호 등 소수의 전문가들만이 사용하는 것이 거의 다이다. 현재 계획은 앞으로 다른 문자들이 더해진다고 하더라도 0x000000 부터 0x10FFFF까지의 21비트의 백만이 넘는 코드 공간 이상이 필요하지는 않으리라고 생각하고 있다. ISO 10646-1 기준은 1993년에 최초로 제안됐으며, 문자의 구조와 BMP 영역의 내용을 정의하고 있다. BMP 영역의 외부에 인코딩되는 문자들을 정의하고 있는 두번째 파트인 ISO 10646-2는 준비 중에 있으나, 그것이 완성되기까지는 수년이 걸릴지도 모른다. 끊임없이 새로운 문자들이 BMP 영역에 포함되고 있지만, 현재 존재하고 있는 문자들은 결코 변하지 않을 것이며 안정성을 확보하고 있다. UCS는 각각의 문자에 코드 번호 뿐만 아니라 공식 명칭도 할당하고 있다. UCS 혹은 유니코드 값은 "U+"를 앞에 붙인 16진수로 표시하며, 일례로 "라틴 대문자 A"는 U+0041로 표시된다. UCS 문자 U+0000 부터 U+007F는 US-ASCII(ISO 646 IRV)와 동일하며, 나아가 U+0000 부터 U+00FF까지의 범위는 ISO 8859-1(Latin-1)와 같다. U+E000에서부터 U+F8FF까지의 범위와 BMP 영역 외부의 거대한 영역은 개인적인 용도를 위해 보존된다. UCS 표준의 완전한 명칭은 다음과 같다. International Standard ISO/IEC 10646-1, Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Second edition, International Organization for Standardization, Geneva, 2000-09-15. 이것은 PDF 파일로 저장된 CD-ROM 세트로 80 스위스프랑( 54 유로화, 45 미국달러, 32 영국파운드)에 ISO로부터 온라인으로 주문 할 수 있다. 2. 결합 문자(Combining Characters)란 무엇인가?UCS에서 몇몇 code point들은 결합 문자(combining characters)에 할당되었 다. 이것들은 타자기에서 공간을 차지하지 않는 액센트 키와 같다. 결합 문자는 그 자 체로는 하나의 완전한 문자가 아니다. 그것은 앞서는 문자에 더하는 액센트거나 혹은 구분 마크이다. 이런식으로, 어떤 문자에 어떤 액센트를 놓는 것이 가능하다. 일반적인 언어의 철자법에서 사용하는 문자처럼 가장 중요한 액센트를 가진 문자들은 옛 문자 셋을 가진 구 버전과의 호환성을 확보하기 위해서 UCS에서 그들 자신만의 코드를 갖는다. 미리 만들어진 문자(precomposed characters)라고 알려진 액센트를 가진 문자들은 자신만의 코드 위치를 갖지만, 또한 결합 문자에 뒤따르는 한쌍의 다른 문자로써 나타낼 수 있다. 미리 만들어진 문자들은 어떠한 결합 문자도 갖지 않는 ISO 8859와 같은 옛 방식의 인코딩과의 호환성을 위해서 UCS에서 사용 가능하다. 결합문자의 메카니즘은 어떤 문자에 액센트나 다른 구분 기호를 붙이는 것을 허락하는데, 이 것은 특히 기본 문자와 한가지 혹은 몇가지의 구분 기호와의 결합이 필요한 수학 방정 식과 국제 표음 알파벳과 같은 과학 표기법을 위해서 중요하다. 결합문자는 그들이 수정하는 문자를 따른다. 예를 들면, 독일 umlaut 문자 Ä는 미리 만들어진 UCS 코드 U+00C4로 나타내거나 대안적으로 "결합 부음 부호"(combin ing diaeresis)의 뒤를 잇는 일반적인 "라틴 대문자 A"의 결합으로 나타낼 수 있는데, U+0041 U+0308와 같다. 몇몇의 결합 문자는 다수의 액센트를 위에 놓거나 기본 문자의 위아래 모두에 결합 마크를 더 할 필요가 있을 때 적용할 수 있다. 타이 문자를 예 로 들면, 하나의 기본 문자 위에 결합 문자가 최대 2개까지 필요하다. 3. UCS 구현 레벨(UCS implementation levels)은 무엇인가?모든 시스템들이 결합 문자와 같은 UCS의 모든 진보된 메카니즘을 지원하리라고 기 대할 수 없다. 그러므로, ISO 10646은 다음의 세가지 구현 레벨을 명시하고 있다.
4. UCS는 국제 기준으로 채택되었는가?대답은 예이다. 수많은 국가들이 1993년에 ISO 10646-1:1993을 국가적으로 채택할 것을 공표했으며 때로는 예전에 국가에서 구현한 여러가지 사항과 기준에 대한 상호 참고 조항에 부가적인 조항을 붙인 후에 공표했다.
5. 유니코드란 무엇인가?역사적으로, 단일 통합시킨 문자셋을 만들려는 두개의 독립적인 시도가 있었다. 하 나는 국제 표준 기구(ISO)의 ISO 10646 프로젝트였으며, 다른 하나는 다중 언어 소프트웨어 제조사들의(초기에는 미국회사가 대부분이었 던) 컨소시움으로 구성된 유니코드 프로젝트였다. 운 좋게도, 두 프로젝트에 참여했던 참가회사들 모두 1991년경에 두개의 서로 다른 통합 문자셋은 세계가 원하는 바가 아니라는 것을 깨달았다. 그들은 함께 노력했으며 단일한 코드 테이블을 만들기 위해 함께 작업했다. 양 프로젝트 모두 여전히 존재하며 그들 각자의 기준을 독립적으로 공표한다. 그러나 유니코드 컨소시움과 ISO/IEC JTC1/SC2는 호환가능한 유니코드와 ISO 10646 기준의 코드 테이블을 유지하기로 합의했다. 그리고 그들은 더욱 발전적인 확장 기능을 위해 면밀히 협력하고 있다. 유니코드 1.1은 과거 ISO 10646-1:1993에 대응했고, 유니코드 3.0은 현재 ISO 10646-1:2000에 대응한다. 유니코드 표준은 몇몇 일반적인 책처럼 amazon.com으로부터 약 50 달러에 주문할 수 있다.
The Unicode Consortium: The Unicode Standard, Version 3.0, Reading, MA, Addison-Wesley Developers Press, 2000, ISBN 0-201-61633-5. 텍스트 프로세싱과 문자셋을 가지고 자주 작업을 한다면, 여러분들은 반드시 한 카 피를 구입해야만 한다. 6. 유니코드와 ISO 10646 사이의 차이점은 무엇인가?유니코드 컨소시움이 공표한 유니코드 표준은 실제로 구현 레벨 3에서 기본 다국어 평면(BMP)을 포함한다. 두 표준 공히 모든 문자들은 같은 위치를 가지며 같은 명칭을 사용한다. 유니코드 표준은 부가적으로 몇몇 문자와 관련된 훨씬 많은 언어 체계를 정의하고 있으며 일반적으로 양질의 인쇄 출판 시스템 구현을 위한 더 나은 참고 자료가 된다. 유니코드는 예를 들어 라틴어와 유태어를 혼합하는 양 방향 텍스트를 취급하므로써, 몇몇 언어의 프리젠테이션 양식을 렌더링하기 위한 알고리즘과 문자열 비교를 위한 알 고리즘 및 그 외 많은 것을 명시하고 있다. 다른 한편 ISO 10646 표준은 잘 알려진 ISO 8859 표준과 비교했을 때 간단한 문자셋 테이블 그 이상은 아니다. 이것은 표준과 관련된 몇몇 기술들을 명시하고, 몇몇 인 코딩 대안들을 정의하며, ISO 6429와 ISO 2022와 같은 다른 ISO 표준과 관련된 UCS를 사용하는 방법에 관한 세부 사항을 포함한다. ISO 표준과 밀접하게 관련된 다른 것들 도 있다. 예를 들면, UCS 문자열의 정렬에 관한 ISO 14651이 있다. ISO 10646-1 표준의 훌륭한 특징으로는 그것이 다섯가지 다른 스타일로 변형시켜 한중일 국가의 glyph 예를 제공한다는 것이다. 반면 유니코드 표준은 한중일 국가의 한자를 단지 중국 식으 로만 보여준다. 7. UTF-8은 무엇인가?무엇보다 먼저 UCS와 유니코드는 단지 정수를 문자에 할당하는 코드 테이블일 뿐이 라는 것이다. 그러한 문자 혹은 문자 각각의 정수 값의 시퀀스가 어떻게 바이트 시퀀스로 나타날 수 있는 지에 대한 몇 가지 대안들이 존재한다. 대단히 이해하기 쉬운 두 개의 인코딩은 유니코드 텍스트를 2 혹은 4바이트 시퀀스의 시퀀스(sequences of either 2 or 4 bytes sequences) 로써 저장한다. 이러한 용어에 관한 공식적인 명칭은 각 각 UCS-2와 UCS-4이다. 다른 방법으로 명시되지 않는다면, 가장 중요한 바이트가 이들의 첫번째로 온다(Bigendian convention). ASCII 또는 Latin-1 파일은 모든 ASCII 바이트의 앞에 0x00 바이트를 삽입하므로써, UCS-2 파일로 변환시킬 수 있다. UCS-4 파일을 원한다면, 모든 ASCII 바이트 앞에 그 대신에 세개의 0x00 바이트를 삽입해야만 한다. 유닉스 환경에서 UCS-2(또는 UCS-4)를 사용하는 것은 매우 심각한 문제점을 불러온다. 이러한 인코딩을 가진 문자열들은 파일명과 C 라이브러리 함수 파라미터에서 특별한 의미를 갖는 '\0' 혹은 '/'와 같이 매우 광범위한 문자 바이트를 부분적으로 포함할 수 있다. 이에 더해, 대다수의 유닉스 툴들은 ASCII 파일을 예상하며, 큰 수정이 없이는 16비트 단어들을 문자로 읽을 수 없다. 이러한 이유 때문에 UCS-2는 파일명과 텍스트 파일 및 환경 변수 등에 적합한 유니코드의 외부 인코딩(suitable external encoding of Unicode)이 아니다. ISO 10646-1 의 Annex R과 RFC 2279상에 정의된 UTF-8 인코딩은 이러한 문제점들이 없다. 이것은 유닉스 스타일의 운영 체제하에서 유니코드를 사용하기 위한 의심할 여지없이 좋은 방법이다. UTF-8은 다음의 성질을 갖고 있다:
다음의 바이트 시퀀스는 한 문자를 나타내기 위해 사용한다. 사용되는 시퀀스는 그 문자의 유니코드 번호에 따라 달라진다.
xxx비트의 위치는 이진 표기법에 의해 문자 코드 번호의 비트들로 채워진다. 오른쪽의 x비트는 별로 중요하지 않다. 그 문자의 코드 번호를 나타내는 오직 가장 짧은 멀티바이트 시퀀스만 사용할 수 있다. 멀티바이트 시퀀스에서 첫 번째 바이트의 왼쪽 1비트의 수는 전체 시퀀스에서의 바이트 수와 같다는 점에 주의하라. 예: "유니코드 문자
11000010 10101001 = 0xC2 0xA9 그리고 문자
11100010 10001001 10100000 = 0xE2 0x89 0xA0 이러한 인코딩의 공식 명칭과 정확한 표기는 UTF-8이며, UTF는 UCS Transformation Format을 의미한다. utf8혹은 UTF_8과 같은 다른 방법으로 UTF-8을 문서에 쓰지마라. 물론 인코딩 자체를 참조하지 않고 변수명에 참조할 경우에는괜찮다. UTF-8의 디코딩 처리 순서에 있어서 중요한 점은 다음과 같다: 보안상의 이유 때문에, UTF-8 디코더는 한 문자를 인코딩하기 위해서 필요 이상으로 긴 UTF-8 시퀀스를 받아들여서는 안 된다. 예를 들어 U+000A(라인 피드) 문자는 오직 0x0A 형식으로 UTF-8 스트림으로부터 받아들여야만 하며, 다음의 다섯가지와 같이 과도하게 긴(overlong) 형식으로 받아들여서는 안된다.
0xc0 0x8A 0xe0 0x80 0x8A 0xf0 0x80 0x80 0x8A 0xf8 0x80 0x80 0x80 0x8A 0xfc 0x80 0x80 0x80 0x80 0x8A 가장 짧은 인코딩을 찾기 위한 UTF-8 서브스트링 테스트를 무시하기 어떤 과도하게 긴 UTF-8 시퀀스를 남용할 수 있다. 모든 과도하게 긴 형식의 UTF-8 시퀀스는 다음의 바이트 패턴 중 한 가지로 시작한다.
정상적인 UTF-8 혹은 UCS-4 데이터상에서 코드 위치 U+FFFE와 U+FFFF 뿐만 아니라 코드 위치 U+D800 부터 U+DFFF(UTF-16 대용)까지는 사용해서는 안 된다. UTF-8 디코더는 이러한 것들을 안전성을 이유로, 잘못된 형식으로 혹은 너무 긴 시퀀스로 취급해야 만 한다. Markus Kuhn의 UTF-8 decoder stress test file은 잘못된 형식을 갖는 과도하게 긴 UTF-8 시퀀스의 체계적인 모음을 포함하고 있으며 디코더의 강력함을 증명해준다. 8. 유니코드를 지원하는 프로그래밍 언어는 무엇인가?1993년경 이후에 개발된 최근의 프로그래밍 언어들은 이미 유니코드/ISO 10646-1 문자들을 위한 특별한 데이터 형을 가지고 있다. 이것은 Ada95의 경우 Wide_Character이며 자바의 경우 Char이다. ISO C는 또한 멀티바이트 인코딩과 와이드 문자(wide character)를 취급하기 위한
메커니즘을 명시하고 있으며,
Amendment 1 to ISO C가 1994년 9월에 발행되었을 때 더욱 더 많은 것들이 추가되었다. 이러한 편리한 기능은 주로 여러가지 동아시아 문자들을 인코딩하기 위해서 설계되었고 UCS를 취급하기 위해서 필요한 것보다 훨씬 더 복잡해졌다. UTF-8은 ISO C 표준이 하나의 멀티바이트 문자열과 9. 리눅스에서 유니코드를 어떻게 사용하는가?UTF-8이 발표되기 전에는 다른 지역에 살고 있는 리눅스 유저들은 여러가지 ASCII 확장 문자를 사용하였다. 유럽에서는 ISO 8859-1과 ISO 8859-2를, 그리스에서는 ISO 8859-7을, 러시아에서는 KOI-8을, 일본에서는 EUC와 Shift-JIS를 가장 널리 사용하였다. 이로 인하여 파일을 교환하는 것이 어려웠고, 어플리케이션 소프트웨어를 제작하기 위해서는 이러한 인코딩들 사이의 차이점을 걱정해야만 했다. 유니코드는 결국에는 이러한 모든 인코딩들을 대신할 것이며, UTF-8 형식이 주를 이룰 것이다. UTF-8은 아래와 같은 경우에 사용될 것이다.
UTF-8 모드에서 xterm이나 리눅스 콘솔 드라이버와 같은 터미널 에뮬레이터는 대응하는 UTF-8 시퀀스로 모든 키입력을 전달하며, 키입력을 포그라운드 프로세서의 표준 입력으로 보낸다. 비슷한 방식으로 프로세서의 표준 출력을 터미널 에뮬레이터로 보내고 그곳에서 출력을 UTF-8 디코더로 처리하고 16비트 폰트를 사용하여 디스플레이한다. 경고음을 갖는 완전한 유니코드 기능은 복잡한 다중-언어 워드-프로세싱 패키지에 사용할 것으로 예상할 수 있다. 리눅스는 틀림없이 ASCII 문자를 대신하기 위한 폭 넓은 기반 위에서 사용될 것이며, 다른 8비트 문자셋은 훨씬 단순해질 것이다. 리눅스의 터미널 에뮬레이터와 명령 라인 도구들은 처음 단계에서 바로 UTF-8로 전환할 수 있을 것이다. 이것은 ISO 10646-1으로 구현한 레벨 1이 (어떠한 결합 문자도 사용하지 않고) 사용됨을 의미하며, 어떠한 프로세싱 지원도 필요로 하지 않는 라틴어, 그리스어, 키릴어 및 많은 과학 기호와 같은 서체(script)들만 지원됨을 의미한다. 이러한 레벨에서 UCS 지원은 ISO 8859 지원에 비교할 만 하며 유일한 중요한 차이점은 현재 유용한 수많은 다른 종료의 문자들이 있으며, 문자들은 멀티바이트 시퀀스로 나타낼 수 있다는 것이다. 리눅스에서 결국 결합 문자가 지원되겠지만 미리 만들어진(precomposed) 문자들이 유용한 결합 문자 시퀀스보다 더욱 좋은 선택이 되어야만 한다. 더 명백하게 말하자면, 리눅스상에서 유니코드로 만들어진 텍스트를 인코딩하는 더 좋은 방법은 Unicode Technical Report #15에서 정의한 표준 형식 C (Normalization Form C)가 되어야만 한다. 영향력있는 POSIX 비호환 PC 운영체제 판매 회사 중 하나는(여기서 이름을 밝히지는 않겠다) 어떤 파일에서, 사용되는 인코딩과 바이트 순서를 식별하기 위해서 모든 유니코드 파일이 폭이 없는 노브레이크 스페이스 문자(ZERO WIDTH NOBREAK SPACE: U+FEFF)로 시작하게 하자고 제안했는데, 이러한 규칙에 따르면 어떤 파일에서 사용되는 인코딩과 바이트 순서(byte-order)를 식별하기 위해서 폭이 없는 노브레이크 스페이스 문자는 signature 혹은 "바이트-순서 마크(byte-order mark: BOM)"로써 참조할 수 있 다. 리눅스는 BOM이나 signature를 전혀 사용하지 않는다. BOM이나 signature의 사용은 수없이 많이 존재하고 있는 ASCII-파일 문법 규칙을 깨뜨릴 것이다. POSIX 시스템에서, 선택한 로케일은 어떤 프로세스의 입출력 파일에서 필요로 하는 인코딩을 미리 확인한다. 또한 signature "UTF-8N" 파일 없이 UTF-8 파일들을 호출 하기 위해서 그것을 제안했었다. 그러나 이러한 비 표준적인 용어는 보통 POSIX 세계에서는 사용하지 않는다. 10. 소프트웨어를 어떻게 수정해야만 하는가?UTF-8 지원을 위한 두 가지 접근 방법이 있다. 이것을 소프트 및 하드 변환이라 부르기로 하겠다. 소프트 변환에서 데이터는 UTF-8 형식으로 어디서나 보존되며 단지 매우 적은 수의 소프트웨어만 변화시킬 필요가 있다. 하드 변환에서 프로그램이 읽어들이는 UTF-8 데이터는 폭이 큰(wide) 문자 배열로 변환 될 것이며, 또한 애플리케이션 내부의 어느 곳에서도 처리될 것이다. 대부분의 애플리케이션들은 단지 소프트 변환만으로도 잘 동작한다.
소프트 변환은 유닉스 상에서 UTF-8을 받아들일 수 있게 하는 것이다. 예를
들면, 바이트 수를 계산하여 한 문자열 안의 문자 수를 결정하는 모든 프로그램을
위해서 약간의 수정이 필요할 것이다. UTF-8 모드에서, 프로그램들은
0x80부터 0xBF 범위 사이의 어떤 바이트 수도 계산해서는 안된다. 왜냐하면
이러한 바이트 수는 연속 바이트(continuation bytes)이며 소유하고 있는
문자는 아니기 때문이다. UTF-8과 함께 C언어의 예를 들어, 리눅스 커널 또한 소프트 변환만으로도 잘 동작할 수 있으며, UTF-8을 완벽하게 지원하기 위한 아주 약간의 수정만 필요하다. 문자열(예를 들어 파일명, 환경 변수 등)을 취급하는 대부분의 커널 함수들은 영향을 받지 않 는다. 다음과 같은 경우에 수정이 필요할 수 있다.
11. 유니코드와 UTF-8을 위한 C의 지원GNU glibc 2.2부터 살펴보면, 현재 사용하는 로케일과 상관없이, 예를 들면 아래와 같이 쓸 수 있다.
wprintf(L"Schone Gruße!\n"); 그런 뒤에 소프트웨어는 이러한 텍스트를 사용자가 환경 변수 12. UTF-8 모드는 어떻게 활성화되어야 하는가?여러분이 사용하는 애플리케이션이 8비트 문자셋(ISO 8859-*, KOI-8 등) 과 UTF-8 모두를 지원한다면 그것이 UTF-8 모드를 사용한다고 가정할 수 있 는 지 없는지를 몇 가지 방법으로 알아내야만 한다. 바라건대, 몇 년 안에 모든 사람들이 오직 UTF-8만을 사용하고 있을 것이며, 여러분들은 그것을 기본값으로 만들 수 있을 것이다. 그러나 고전적인 8비트 셋과 UTF-8 모두 가 틀림없이 지원되기 전까지는 아니다. 현재 사용되는 애플리케이션들은 그들 각각의 UTF-8 모드를 활성화시키 기 위해 전체적으로 다른 명령 라인 스위치들을 사용한다. 예를 들면:
특별한 명령 라인 옵션이나 모든 애플리케이션을 위해 모든 설정 메카니즘 을 기억하는 것은 몹시 지루한 일이다. 그러므로 몇 가지 표준 사항을 급히 만들 필요가 있다. 13. UTF-8을 지원하는 X-term 버전은 어떻게 구하는가?(
Thomas Dickey가 관리하는
XFree86 4.0 혹은 보다 높은
버전에서 사용하는
xterm 버전은 이미 UTF-8 지원을 포함하고 있다. 만약 당신이 XFree86
4.0을 사용하지 않는다면, 대안으로써
가장 최신의 xterm 개발 버전을 따로 다운로드할 수
있으며 여러분이 직접 " xterm의 입출력 모드를 UTF-8로 변환시키기 위해서는 명령 라인 옵션 14. xterm은 얼마나 많은 유니코드를 지원하는가?XFree86 4.0.1에 포함된 Xterm은 현재 고정 문자 폭을 가지며 왼쪽에서 오른쪽 방향으로 써야하는 ISO 10646-1의 레벨 1만을 지원한다. 다시 말하 면, 터미널의 의미 연결 체계(terminal semantic)가 이제 UTF-8을 디코딩할 수 있고 16비트 문자에 액세스 할 수 있다는 것을 제외하면, 터미널의 의 미 연결 체계는 ISO 8859-1의 경우와 기본적으로 같다. 가장 최신의 xterm 개발 버전은 이에 두 가지 새로운 함수들( Robert Brady가 제공)을 추가한다.
선택된 일반 문자가 스페이스가 없거나(nonspacing) 둘러싸고 있는(enclosing) 결합 문자들( 예를 들면, 유니코드 데이터베이스안에 일반적인 카테고리 코드 Mn 이나 Me를 가지고 있는 문자들) 또한 현재 사용 가능하며 이것은 기본 -문자 glyph(base-character glyph)을 두 개의 결합 문자 glyph까지 단지 겹쳐쓰므로써(논리 연산자 OR-ing) 구현할 수 있다. 이것은 기본 라인 아래 에 액센트를 받아들일 수 있게 하고, 작은 문자 위에 액센트를 받아들일 수 있게 한다. 예를 들면 겹쳐쓰기와 함께 사용하기 위해서 특별히 설계된 태 국 폰트에 대해서도 또한 잘 동작한다. 그러나 특별히 "고정되고" 집단화된 폰트와 같은 어떤 폰트 안에서 키가 큰 문자 위에 액센트를 결합하는 것은 완전히 만족스럽지 않을 지도 모른다. 그러므로 미리 만들어진(precompose d) 문자들을 사용 가능한 경우에는 그것이 더 나은 결과를 낳을 것이다. 텍스트 모드 애플리케이션 프로그래머들이 주의해야 할 점: xterm의 출력은 한중일어권의 한자와 결합 문자를 위한 지원으로써 보다 는 비례 문자처럼 반응할 것이다. 왜냐하면 라틴/그리스/키릴 등의 문자는 하나의 세로열 위치를 필요로 하는 반면, 한중일어권의 한자는 2개의 문자 를 필요로 하며 결합 문자는 하나도 필요로 하지 않기 때문이다. 오픈 소스 그룹의 단일 유닉스 사양은 하나의 문자가 얼마나 많은 세로열을 차지하고 있 는지를 애플리케이션이 테스트 할 수 있도록 하는 두 개의 C 함수 wcwidth()와 wcswidth() 를 명시하고 있다.
#include <wchar.h> int wcwidth(wchar_t wc); int wcswidth(const wchar_t *pwcs, size_t n); Markus Kuhn 이 비 상용(free)으로 배포하는 wcwidth() 함수는 C 라이브러리가 아직 적합한 함수를 제공하지 않는 플랫폼의 애플리케이션에 의해 사용될 수 있 다. xterm은 앞으로 다가올 미래에 더욱 복잡한 완전한 유니코드 렌더링 엔 진에서 당신이 기대할 지도 모를 다음의 기능들을 아마도 지원하지 않을 것 이다.
그러므로 유태어와 아랍어 사용자들은 유태어와 아랍 문자열을 터미널로 보내기 전에 문자열의 방향을 반전시키고 왼쪽을 채우는 애플리케이션 프 로그램을 사용해야만 한다. 다시 말해, 양방향 프로세싱은 xterm에 의해서 가 아니라 애플리케이션에 의해서 이루어져야만 한다. 유태어 및 아랍어와 관련된 상황은 미리 만들어진 glyph과 프리젠테이션 양식의 유효성에 있어 서 적어도 ISO 8859 이후 개선되고 있다. 지금으로써는 양방향 지원이 정말 로 xterm에 내장될 것인지 이것이 얼마나 정확하게 작동할 것인지 명확하지 않다. ISO 6429 = ECMA-48과 유니코드 bidi 알고리즘 모두 대안적인 시작 포인트(starting point) 를 제공한다. E CMA Technical Report TR/53을 보도록 하라. 만약 당신이 애플리케이션에서 양방향 텍스트 출력을 지원할 계획이라면 , 유니코드 Bidi 알고리즘을 비 상용(free)으로 구현한 Dov Grobgeld의 FriBidi 혹은 Mark Leisher의 PretBidi 알고리즘을 보라. 최근에 비록 Robert B rady가 bidi 지원을 위한 몇몇 초기 실험적인 패치를 발표하긴 했지만 xterm은 현재 아랍어, 한글 자모 및 인도 텍스트 포맷팅 알고리즘을 지원하 지 않는다. VT100 애뮬레이터에서 이러한 것들을 지원하는 것이 알맞은지 > 혹은 바람직한지 여전히 불명확하다. 애플리케이션들은 아랍어와 한글을 포 맷하는 알고리즘을 쉽게 애플리케이션 스스로 적용할 수 있다. 왜냐하면 xt erm이 애플리케이션으로 하여금 모든 필요한 프리젠테이션 양식을 출력하는 것을 허용하기 때문이다. 인도 서체에 관해서 X 폰트 메카니즘은 필수적인 연결선(ligature)을 대체할 또 다른 형태의 연결선을 위한 인코딩을 지금> 으로써는 전혀 지원하지 않고 있다. 그래서 제공할만 한 xterm이 전혀 없다 . 인도어 출력이 필요한 애플리케이션은 xterm과 같은 VT100 에뮬레이터 대 신에 Pango와 같은 적절한 유니코드 X11 렌더링 라이브러리를 사용하는 것이 더욱 좋다. 15. ISO-10646의 X11용 폰트는 어디서 구할 수 있는가?지난 몇년 동안 꽤 많은 수의 유니코드 폰트들이 X11용으로 사용 가능하게 되었으며, 사용 가능한 폰트의 수는 빠른 속도로 증가하고 있다.
유니코드 X11용 폰트의 명칭은
여러분들은 *-ISO10646-1 폰트에서 ASCII 문자의 인용 부호 형태가 표준 라인 안 에 인용 부호를 배치하고 다른 플랫폼에서도 실행하기 위해서 약간 바뀌었 다는 것을 알아 차릴 수 있을 것이다. 16. UTF-8 터미널 에뮬레이터와 관련된 이슈는 무엇인가?VT100 터미널 에뮬레이터들은 다른 문자셋들 사이를 전환하기 위해서 ISO 2022 (= ECMA-35) ESC 시퀀스를 받아들인다. UTF-8은 ISO 2022의 관점에서 보면 "다른 코딩 시스템(other coding system)"이다 (ECMA 35의 섹션 15.4를 보라). UTF-8은 ISO 2022 SS2/SS3/G0/G1/ G2/G3이 속하는 세계의 외부에 있다. 그러므로 만약 ISO 2022에서 UTF-8로 전환하면, 모든 SS2/SS3/G0/G1/G2/G3 문은 UTF-8을 벗어나 다시 ISO 2022로 돌아가기 전까지는 의미를 잃게 된다. UTF-8은 국적이 없는 인코딩이므로, 스스로 종결시키는(self-terminating) 짧은 길이의 바이트를 갖는 시퀀스( short byte sequence)는 전환하는 문장과는 독립적으로 어떤 문자가 의미가 있는지를 완벽하게 판정한다. ISO 10646-1 안의 G0와 G1은 ISO 8859-1의 그것들과 같다. 그리고 G2/G3는 ISO 10646 내에 존재하지 않는다. 왜냐하면 모든 문자는 고정된 위치를 가지며 어떤한 변경도 일어나지 않기 때문이다 . 우연히 바이너리 파일을 터미널에 덤프한 후에 터미널이 이상한 그래픽- 문자 모드로 전환된 채 남아있는 것은 UTF-8에서는 가능하지 않다. 이것은 UTF-8 모드에 있는 어떤 터미널을 ISO 2022 모드 일때보다 훨씬 더 강력하 게 동작하도록 한다. 그러므로 터미널이 우연히 ISO 2022 모드로 돌아갈 수 없도록 그것을 UTF-8 모드로 고정시켜 놓는 것이 효과적이다. ISO 2022 표준은 ISO 2022 모드에서 벗어나기 위한 이스케이프 문자 %의 시퀀스 범위를 명시하고 있다(다른 코딩 시스템 지정, DOCS). 그리고 그러 한 수많은 시퀀스들은 UTF-8을 위해서 ISO 2375 문자 코드 셋 국제 등록부(I nternational Register of Coded Character Sets)의 섹션 2.8에 등록되 었다.
터미널 에뮬레이터가 UTF-8 모드에 있는 동안에 G2/G3로 전환시키는 이
스케이프 시퀀스와 같은 모든 ISO 2022 이스케이프 시퀀스는 무시된다. UTF
-8 모드에서 동작하는 터미널 에뮬레이터 상의 유일한 ISO 2022 시퀀스는,
UTF-8에서 ISO 2022 체계로 다시 전환시키는 비록 UTF-8 모드가 0x80에서 0x9F까지의 범위를 갖는 바이트 공간을 사 용하지만, 여전히 CSI와 같은 C1 제어 문자들을 사용하는 것을 허용한다. UTF-8 모드에 있는 터미널 에뮬레이터는 어떤 제어 문자를 해석하기 전에 UTF-8 디코더를 입력되는 바이트 스트림에 적용해야만 한다 는 것을 이해하는 것이 중요하다. C1 문자들은 U+007F를 넘는 다른 문자들 처럼 UTF-8 모드로 디코딩된다. 17. UTF-8이 가능한 지금 사용 중인 애플리케이션은 어떤 것이 있는가?
18. UTF-8을 지원하기 위해서 사용가능한 패치는 무엇인가?
19. 유니코드를 다루는 사용가능한 비 상용(free) 라이브러리는 있는가?
20. UTF-8을 지원하기 위해 어떤 패키지가 현재 개발 중인가?
21. 솔라리스 상에서 UTF-8을 위한 지원은 어떻게 동작하는가?Solaris 2.8버전부터 그 이후로 UTF-8은 적어도 부분적으로 지원된다. UTF-8을 사 용하기 위해서는 UTF-8 로케일 중 하나를 설정하라. 예를 들면 다음과 같이 C 쉘에서 입력한다.
setenv LANG en_US.UTF-8 현재 UTF-8 텍스트를 입력 및 출력하기 위해서 더 많은 정보를 원한다면, en_US.UTF-8 로케일 지원 웹 페이지의 Sun's Overview를 읽어보라. 22. 포스트 스크립트 glyph 명칭(Postscript glyph names)>은 어떻게 UCS 코드와 관련되어 있는가?Adobe사의 Unicode and Glyph Names 가이드를 읽어보라. 23. 잘 정의된 UCS subset은 있는가?40000개의 문자를 가지는 유니코드를 완벽하게 구현하는 것은 거대한 프로젝트이다 . 그러나 전과 같이 단지 수백 또는 수천 문자를 구현하는 것과 유니코드화를 거친 단 순한 하나의 인코딩속에서 모든 필요한 문자에 접근하는 단순함을 즐기는 것도 종종 중요하다(특히 유럽 시장을 위해서). 수많은 다른 UCS 서브셋들은 이미 확립되었다.
Markus Kuhn의 유니셋(uniset) Perl 스크립트는 구현한 프로그램이 제대로 동작하는 지를 체크하기를 원하거나 새로운 프로그램을 만들고 싶어하는 사람들을 위하여 UCS 서브셋 위에 편리한 산술 계산 셋(set)을 사용하는 것을 허용하고 있다. 24. X11 R6.4 스펙과 유니코드에 어떤 문제점이 있는가?X11 R6.4 릴리즈(1998)는 X 컨소시움이 개발한 X11 윈도우 시스템 표준에 맞는 샘플 프로그램의 최신 버전이다. 대부분의 현재의 X11 표준과 샘플 프로그램은 유닉스 환경에서의 유니코드에 대한 광범위한 관심을 일찍부터 불러일으키고 있다.
이러한 이슈들을 연구하는 작업이 진행 중인가? 모르겠다. 나는 몇 일에 걸쳐 X 컨 소시움을 공식적으로 계승한 단체이자 X11 표준과 샘플 구현의 관리자 역할을 하는 Op engroup인 X.Org에 접촉하려 시도했지만, 그들로부터 아직 쓸모 있는 어떠한 대답도 얻지 못했다(X.Org의 한 멤버인 XFree86에도 접촉했지만, 역시 대답을 얻지 못했다). 25. 이런 문제에 관한 좋은 메일링 리스트는 있는가?반드시 unicode@unicode.org 메일링 리스트에 가입해야만 한다. 이것이 표준 작 성자와 많은 다른 도사들의 의견을 듣기 위한 최선의 방법이다. 기부금을 내고자 한다 면, unicode-request@ unicode.org에 "subscribe"라는 제목과 함께 "subscribe YOUR@EMAIL.ADDRESS unicode" 라는 내용으로 메시지를 보내면 된다. 또한 GNU/Linux 시스템에서 일반적으로 사용하는 애플리케이션을 위한 더욱 향상된 UTF-8 지원책을 연구하기 위해서 쓰이는 linux-utf8@nl.linux.org 메일 링 리스트가 있다. 기부금을 내고자 한다면, "subscribe linux-utf8"이라는 한 줄의 내용을 적어 majordomo@nl.linux. org로 메시지를 보내라. 또한 linux-utf8 archive를 다운받을 수 있다. Xlib와 X 서버에서의 유니코드 지원에 관한 적절한 메일링 리스트는 fonts@xfree86.org와 i18n@xfree86.org가 있다. 26. 더욱 상세한 참고 자료
나는 이 문서에 새로운 내용을 매우 자주 추가할 것이다. 그러므로 규칙적으로 이 문서를 체크하거나 당신에게 이메일로 통지해 주는 Netminder를 이용하여 문서의 변화를 체크하라. 더욱 향상된 UTF-8 지원을 위한 freeware community에서의 광고 뿐만 아니라 제안은 매우 환영한다. 리눅스에서 UTF-8을 사용하는 것은 매우 낯선 일이다. 그러므로 다음 몇 달 후의 이 문서에 많은 진전이 있을 것이다. Ulrich Drepper, Bruno Haible, Robert Brady, Shuhei Amakawa와 가치 있는 비평을 해준 다른 많은 이들과 지원을 해준 SuSE GmbH, Nürnberg에게 특별한 고마움을 표한다.
|
Today is a good day to bribe a high ranking public official.    
|
