다음 이전 차례

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 세계에서는 사용하지 않는다.


다음 이전 차례