하늘빛 공방

한글 97에서 한글 워디안으로 변화.

2000년 무렵에 한글과컴퓨터 사가 많은 비난을 받았던  원인입니다. 달라진 어플리케이션, 달라진 파일 형식. 한글 97에 익숙한 사람에게 새로운 방식은 쉽게 받아들어지지 않았습니다.

하지만 한글 97이 편했음에도, 한글 워디안을 크게 반겼으며, 워디안을 쉽게 쓰기 위해 새로운 기능을 많이 연구해 보았죠.

수많은 새로운 기능 중에서도 ‘유니코드’를 지원한다는 것은, 다국어 문자와 언어 시스템에 많은 관심을 갖는 저에게는 큰 선물이었으니까요.

한글이 처음 윈도우로 등장하였을 때 부터, 한글은 Windows에서 제공하는 API나 툴킷을 사용하기 보다는, 필요한 것을 직접 구현하였습니다. 97 버전을 벗어난 워디안에서도 이러한 경향은계속 되었으며, UI와 유니코드 지원 부분이 모두 독자적인 코드로 동작하였습니다.

Windows 9x와 초창기의 Windows XP까지, Windows는 유니코드를 제대로 처리하지 못하였습니다. 독자적인 한글의 유니코드 처리 시스템은 윈도우즈에서 지원하지 않는 스크립트 등에 대해서도 지원하며, 한글의 글로벌 화를 위해 많은 노력을 기울였다고 생객합니다.

그리고 시간은 흘러흘러 2010을 앞두고 있는 지금. Microsoft는 자사의 유니코드 처리시스템 크게 향상 시켰으며, 많은 부분에서 한글보다 뛰어나게 처리해 주고 있습니다. 하지만 한글 2010 CBT는 여전히 자신만의 유니코드 처리 시스템을 고집하면서도, 스스로의 발전을 도모하지 않는 것 같스니다.

이건 한글과컴퓨터 사의 정책 문제일 수도 있습니다.

Q: 저장 다이얼로그에 다국어 문자를 붙어넣기하면 글자가 ?로 변경되어 저장할 수 없습니다.

A: 이전 버전에서 다국어 문자가 들어간 파일을 읽을 경우 문제가 생겨서, 다국어를 저장할 수 없도록 한 것입니다.(설계대로)

이제 2010년입니다. Windows의 기본 프로그램은 모두 유니코드 파일명을 정상적으로 처리하며, 최근에 제작된 많은 응용 프로그램도 유니코드 파일을 읽고 쓰는데 문제가 없습니다.

한글에서 유니코드 파일명을 입력할 수 없어도, 탐색기를 이용하면 유니코드가 들어가게 파일명을 바꿀 수가 있지요. 결국, 한글에서 저장 방식을 제한한다고 해결되는 문제가 아닙니다. 과거의 버전을 버리더라도 해결해야 문제는 해결해야하며, 과거의 문제는 과거 프로그램의 패치를 통해서 해결해야 할 것이라고 생각합니다.

또 다른 문제는 정렬에서 유니코드를 전혀 고려하지 않는다는 것입니다.

왼쪽은 간단한 단어들에 대해, 한글 2010에서 가나다 정렬을 한 것입니다.

간단히 살펴봐도 기호-로마자-기호-로마자-가나-한글(한자)-로마자로 매우 복잡하게 정렬되어 있습니다.

유니코드와 같이 한 개의 문자에 대해서 여러 자형(대문자 A와, 강세붙은 Á, 전각문자Ａ)이 존재하는 경우에는, 문자를 정렬할 때 이를 동일한 객체 또는 인접한 객체로 인식해야 합니다. 하지만 이러한 것은 한글이나, 가나 일부에만 적용되어 있을 뿐, 오히려 가장 흔히 사용되는 로마자에 대해서도 지원하지 않고 있습니다.

왼쪽의 결과를 보면, 대체적으로 유니코드의 코드 순서에 따라 정렬된 것으로 보이며, 일부 특수한 경우에만 사전을 사용한 것 같습니다. 정식 버전이 출시되기 전에는 정렬 사전을 더 추가해야 할 필요성이 있다고 생각합니다.

다음은 한글 자모의 문제입니다. 유니코드에서는 Hangul Jamo 문자 영역이 있으며, 이 문자 영역의 낱글자를 이용하여 한글 syllables를 표현할 수 있습니다. 한글에서도 Hangul Jamo의 문자를 입력하면 syllables가 출력되도록 되어있습니다. 하지만 글꼴 및 크기 표현에 있어서는 아직까지는 문제가 있습니다.

크기는 모든 글꼴에서 지정한 크기보다 크게 출력됩니다. 모양은 일부 글꼴에서만 적용되는데, 적용되는 글꼴의 수는 함초롱돋움 및 함초롱바탕 밖에 없습니다.

간단하게 한글 2010의 유니코드 지원에 대해 적어 보았습니다. 비록 아직까지는 문제가 많지만 한글 2010 버전에서는 이러한 문제가 해결되기를 바랍니다.

처음 유니코드에 대해 알았을 때에는 아직 시장이 충분히 성장하지 않았었고, 실제 유니코드를 사용하는 것도 매우 적었다. 하지만 최근에는 많은 웹사이트의 인코딩이 UTF-8이며, 모바일 디바이스에서도 이를 기본으로 지원해 주는 등 생활에 밀접하게 다가오게 되었다.

유니코드와 EUC-KR 인코딩이 혼재하면서 문서를 두 인코딩 사이에서 상호 변환하는 일도 많아졌다. 상호 변환에 있어서는 변환 전과 변환 후의 의미 상의 차이가 없거나 적어야 하며, 어느 곳에서 변환하든 동일한 변환 결과를 가져야 한다. 만약 이러한 보장이 없다면 문서의 내용을 잘못 읽거나, 특정 문자가 변환 중에 소실되는 문제를 야기하게 된다.

유니코드의 변환 문제에 대해서는 유니코드와 KS X 1001의 대응 문제 문서에서 논의한 적이 있다. 위에서 말한 두 가지 사항을 예를 들어 설명해 보려한다.

Windows에서는 ‘1-9 4분 붙임표(Hyphen)’를 ‘U+00AD ­ SOFT HYPHEN’으로 매핑한다. 위 링크의 설명에도 나와있듯 SOFT HYPHEN은 자리차짐 글자(화면에 표시되는 글자)가 아니다. 하이퍼네이션(긴 단어에서 줄바꿈이 필요할 때 단어의 중간에서 줄바꿈을 하고 하이픈으로 이어주는 것)이 필요할 때 그 위치를 알려주는 글자이며, 하이퍼네이션이 될 때만 자리차짐을 하게 된다. 아래의 그림을 보면 그 차이를 확실하게 볼 수 있다.

위의 Vista와 같이, 최종적으로는 전혀 의도하지 않았던 식으로 표시되는 것이다. Mac OS에서는 매핑으로 차이로 인해 SOFT HYPHEN으로 변환된 4분 붙임표를 EUC-KR에 없는 문자라고 해석하기 때문에, Windows에서 유니코드로 변환된 문서를 Mac OS에서 변환하게 된다면 변환 불가능 문자로 해석되어 그 값을 잃어버리게 된다.

현재 위와 같은 매핑 시스템의 문제를 해결할 수 있는 방법은 명확하지 않다. EUC-KR의 기초를 이루는 KS X 1001이나 유니코드의 또다른 갈래이며 국가표준으로 제정된 KS X ISO/IEC 10646 모두 두 표준 사이의 매핑 관계에 대해서는 서술하고 있지 않기 때문이다. 그리하여 Mac OS와 Windows, Linux 등의 운영체제는 과거에 작성하였던 매핑 관계를 고수하고 있으며 문제를 계속가지고 있는 것이다. 또한 기존 자료와의 호환성 문제도 있기 때문에 업체 스스로의 매핑 테이블의 변경은 기대하기 힘들다고 생각한다.

이와 같은 이유 때문에 국가 표준의 개정을 통한 변환이 있어야 한다고 생각한다. 한가지 방법으로는 두 표준의 부속서 또는 부록으로 매핑 관계를 기술하는 것이다. 간단한 방법이라고 볼 수 있지만, KS X 1001과 KS X ISO/IEC 10646 사이의 자형에 차이가 있는 경우에는 매핑 관계에 대한 애매함이 있고 추가적인 기술이 필요하기 때문에 오히려 복잡해 질 수도 있는 문제가 있다.

또다른 방법은 일본의 표준인 JIS X 0208의 것을 사용하는 것이다. 이 규격의 각 문자는 일본어로 통상 명칭을 가지고 있었다. JIS X 0208:1997 규격에서 각 문자에 대한 알파벳으로 구성된 이름을 추가하였으며 이를 통해 부호에 의존하지 않고도 문자를 식별할 수 있는 장치를 마련하였다.(예: ―, 대쉬(전각), EM DASH) 문자 이름은 ISO/IEC 10646에 근거하고, 이 이름을 통해 다른 문자 집합의 문자와 동일성을 판별할 수 있으므로 이는 유니코드와 JIS X 0208 사이의 변환에 근거가 될 수 있다.

KS X 1001:2004 규격은 이미 2004년 버전 부터 고유의 이름을 갖도록 정의하였으며 이에 따라 각 문자는 한국어 이름을 가지고 있다. 하지만 이러한 고유한 이름은 부호없이 문자를 식별할 수 있는 기준은 되지 못한다. 유니코드가 국제적으로 통용되는 문자코드이기 때문에 유니코드에 근거한 이름을 붙이게 된다면 부호없이 문자로 식별할 수 있는 장치가 될 수 있으며 상호간의 매핑에도 근거가 될 수 될 수 있을 것이다. 물론 한국어 이름을 버리자는 것은 아니다. 한국어 이름과 로마자 이름을 동시에 부여하여 서로 다른 목적으로 사용하면 된다고 본다.

표준규격이 바뀌더라도 이를 적용하지 않으면 의미가 없을 것이다. Vista의 경우에도 KS X 1001:2004에서 추가된 ㉾자에 대한 지원을 아직 하고 있지 않다. 맑은 고딕에 자형이 추가되어 있지만 이는 유니코드의 자형으로 추가된 것일 뿐, 이에 대한 EUC-KR 상의 부호값은 확인되지 않는다. 이는 JIS X 0213:2004에 대한 지원과 비교되는 것으로써 국가기관에서는 업체가 표준을 더 준수할 수 있도록 권고하고 지도해 나가야 한다고 생각한다.

AppLocale은 유니코드 기반의 Windows XP, 2003에서 레거시 응용프로그램의 언어를 검색하고 해당 언어 환경을 에뮬레이트하여, 시스템 로캘과 다른 로캘을 사용하는 프로그램을 실행하여 주는 어플리케이션입니다.

AppLocale을 설치하여 사용하면 MSI 패키지를 설치할 때 문자열이 깨지는 버그가 생깁니다. AppLocale 을 설치하고 나서 설치 프로그램의 한글이 깨지는 현상에서 이문제에 다루고 있습니다. 그리고 AppLocale을 마우스 오른쪽 버튼에 등록해서 쉽게 사용할수 있는 방법이 있는데, 그것은 Applocale 쉽게 사용하기을 보시면 될거 같네요.

여기에서 소개하려는 대체 프로그램은 pAppLocale과 sbAppLocale입니다.

pAppLocale은 AppLocale를 piaip님이 수정한 프로그램입니다. 구글 중영 번역 결과를 빌리면,

Microsoft AppLocale, famous switching language tool, but it has many problems, including after you installed MSI Installer will be the last set with the language run, and so on. I amended the AppLocale instead pAppLocale. Apart from that bug, also let you build a shortcut after the implementation of the program will not trouble himself dialogue window you.

MSI 인스톨러 문제라든지 이런저런 버그 수정 및 안내 다이얼로그 표시 안하도록 고친 것임을 알수 있지요.(그런데 MSI 인스톨러 문제는 해결이 안되더군요. 저 위의 방법으로 해결해 주세요.) 즉, 아래 다이얼로그가 안나온다는 소리인데, 한번 써보세요. 무지 편하답니다.

다운로드하려면 위 링크에 가서 pAppLocale로 검색하세요. 그러면 링크가 하나 나오는데 그걸 클릭해서 받으면 되요.

sbAppLocale는 AppLocale과는 다른 프로그램입니다. AppLocale이 해당 언어 환경을 에뮬레이트 해 주는것에 비해, 이 것은 API를 후킹하여 변환해 주기 때문이지요. AppLocale 정도의 호환성을 제공해주지는 않지만 커맨드 라인에서 실행할 수 있어 간단하게 사용하기 편하지요.

사용방법: sbapplocale [로캘 값] [실행파일명] [매개변수]

예를들어 ansinote.exe에서 text.txt파일을 일본어 모드로 읽고 싶다면, sbapplocale 1041 ansinote.exe text.txt 로 실행해 주면됩니다.

한글 자모?

한글은 첫글자, 가운데글자, 끝글자(줄여서 첫가끝글자라고 합니다)로 구성된 조합형 문자입니다. 하지만 한글을 완성형 문자라고도 볼 수 있습니다. 현대 한글에서는 첫글자 19자, 가운데글자 21자, 끝글자 28자의 조합만 사용되고, 이 조합으로는 11172자의 문자를 만들 수 있습니다. 각각의 문자는 다른 문자의 조합에 영향을 주지 않기 때문에, 서로 독립적이 되고, 각각의 문자에 서로다른 문자코드를 부여하면 완성형이 되버리는 것입니다.

초창기 컴퓨터에서 한글 사용에 대해 논의가 되었을 때, 첫가끝글자마다 값을 지정하여 그 값의 조합으로 문자를 매핑하는 조합형과, 완성된 문자에 임의의 코드값을 주는 완성형이 제시되었습니다. 완성형이 모든 한글을 표시하지 못한다는 이유로 재야에서는 조합형이 대세였지만, 국가정책과 문서호환이라는 부분이 강조되어 결국 완성형이 조합형을 누르게 되었죠. 이러한 국가표준과는 달리 최초 ISO 10646 논의에서 ‘한글은 조합형으로만 구현하며, 완성형은 KS X 1001(당시 KS C 5601)과의 호환을 위해 2350자만 넣는다’라고 합의가 됩니다. 이때 정한 조합용 한글 낱글자 영역이 한글 자모입니다.

그러나 프로그래밍의 난이도, 조합 데이터의 크기 등을 문제 삼아 일부 회원국/사에서 현대한글의 완성 글자 11,172자를 넣을 것을 강력히 주장하였고, 결국은 호환용 글자 2,350자가 빠진뒤, 11,172자가 한글 음절(Hangul Syllables) 영역이 추가되고, 한글 음절 영역만 사용되면서 한글 자모 영역은 잊혀져 버리고 되었죠. Microsoft에서도 XP까지 이 영역을 지원하지 않았는데, Vista에서는 조합을 지원하게 되었습니다.

한글 자모로 글 써보기

여기에서는 간단하게 한글 자모로 글을 써보겠습니다. “물론” 비스타에서만 가능하죠. 아직까지 한글 자모로 입력가능한 IME가 없기 때문에 문자표로 대신 입력합니다.
1. 문자표 실행 : [스타트 메뉴]-[실행]-[charmap]
2. 글꼴 설정 : 굴림, 맑은 고딕 등 윈도우즈 기본 한글 글꼴 이나 한컴바탕, 한컴돋움
3. 고급보기 체크
4. 문자 집합 설정 : 유니코드
5. 유니코드로 이동 값 입력 : 1100

위와 같이 하면 아래와 같은 창이 뜨게됩니다.

첫소리 글자, 가운데소리 글자, 끝소리 글자에서 하나씩 골라서 더블클릭해보세요. 그럼 복사할 문자 칸에 조합된 문자가 출력됩니다. 여기서 생성된 글자를 복사해서 다른 프로그램에서도 볼수 있습니다.

아래는 위와 같은방법으로 해서 쓴 글입니다. 만약 한글 자모 지원을 조합하지 못하는 OS나 브라우저를 쓴다면 아래의 글이 풀어져서 보일 것입니다.

드디어 윈도우즈에서 한글 자모 조합을 지원하네요.

한글 자모 조합을 지원하는 글꼴은?

한글 자모를 지원하는 모든 한글 글꼴이 지원하는 것은 아닙니다. 오픈타입 한글 스크립트 테이블을 포함한 글꼴만 가능합니다.
비스타에 포함된 글꼴 중에는 굴림, 굴림체, 돋움, 돋움체, 궁서, 궁서체, 바탕, 바탕체, 맑은 고딕이 이를 지원하며 윈도우즈 용 글꼴 중에는 한컴바탕과 한컴돋움이 이를 지원합니다. 물론 더 많은 글꼴이 이를 지원할 거라 생각하지만, 제가 가지고 있는 글꼴 중에서는 이게 전부이네요.

뒷이야기

사실 비스타에서 한글 자모를 할 수 있다는 사실이 비스타가 나온지 몇 개월이 되도록 언급조차 안되고 있다는 사실에 놀랐습니다. 제가 한글 자모 조합이 가능하다는 것을 알게된 것도, 마이크로 소프트 개발자 중 한 분인 Michael Kaplan님의 블로그였습니다. 이 걸 알게된 뒤에 구글, 네이버 등 검색엔진에서 찾아도 Michael Kaplan님의 글 외에는 관련글이 없더군요. 가장 의문인 것은 마이크로소프트 사가 무척 조용하다는 것입니다. 도움말 어디에도 언급이 되어 있지않고, MSDN의 콤플렉스 스크립트 관련 글에도 전혀 등장하지 않으니까요. 설마, “모든 개발을 ‘미국 마소’에서 한국 마소는 전혀 모르고 있었다.”라는 것은 아닐테죠?

이제 본격적으로 한글 자모 조합이 가능해진 이상 Hangul Syllables와 Hangul Jamo의 선호, 채움 문자, 정렬, 고어 표시 등에 대해서도 많은 논의가 되어야 한다고 생각하며, 이 글이 그런 논의에 불씨가 되었으면 하네요.

참고

Sorting It All Out : We’re off on the road to Korea! We certainly do get around… – 한글 자모 조합이 가능하다는 걸 알게된 곳입니다. 글꼴, 언어관련 글이 많이 있습니다.
Hangul OpenType Specification – 오픈타입에서의 한글 처리에 관한 마이크로소프트의 글 입니다.

1. 트랙백이란?

트랙백이란 특정한 글과 관계가 있는 글을 작성하였을 때, 그러한 사실을 알려주기 위한 시스템입니다. 기존 웹문서에서 링크는 단방향일 경우가 많았습니다. 즉, A란 글을 보고 자신의 생각을 정리해 B란 글을 써서 A로 링크할 수 있습니다. 하지만 A의 저자가 B 글을 보기 전까지는 A글에서 B글로의 링크가 되지 않아 정보 교환의 불편함이 생기게 되는 것이지요.

트랙백은 이러한 기존 체계와는 다른 것입니다. 만약 A글이 트랙백을 받을 수 있다면, B는 A글에 트랙백 핑(글의 제목, 요약, 주소 등의 정보를 가진 작은 단위)를 보내 A의 글에 B의 링크가 생기게 할 수 있습니다. 이러한 기능을 통해 글들의 상호 연동이 가능하게 되었습니다.

2. 트랙백의 인코딩

ㄱ. 발생

문자는 일련의 바이트로 구성되며, 이러한 바이트를 문자로 해석하는 방법을 인코딩(EUC-KR, UTF-8 등)이라고합니다. 같은 바이트라고 하더라도 인코딩에 따라 출력되는 문자가 달라지는 것이지요.

초창기의 트랙백 규격은 인코딩을 나타내는 방법을 지시하지 않았습니다. 이러한 이유로 트랙백을 받더라도, 자신의 블로그에서 사용하는 인코딩과 같지 않으면 깨져서 표시되는 문제가 발생하였습니다.

ㄴ. 경과

이러한 트랙백 인코딩 문제에 대해 해결하려는 움직임이 조금씩 생겨났습니다. 한국어를 나타내는데 사용되는 인코딩은 EUC-KR과 UTF-8이 대표적인데, 이 두 인코딩은 쉽게 구분할 수 있었던 점이 유리했습니다. 보내는 트랙백의 인코딩을 선택해여 보낸다거나, 받는 트랙백의 인코딩을 자동으로 판별해 변환해 주는 방법이 가장 많이 쓰였습니다.

ㄴ. 해결

트랙백 인코딩 문제는 TrackBack Technical Specification 1.2 에서 인코딩 지정 방식이 추가(http 규격에 따라 명확히?) 되면서 해결되었습니다.

To send a ping, the client sends an HTTP POST request to the TrackBack Ping URL. The client MUST send a Content-Type HTTP header, with the content type set to application/x-www-form-urlencoded. The client SHOULD include the character encoding of the content being sent (title, excerpt, and weblog name) in the charset attribute of the Content-Type header.

??핑을 보낼 때에는, 트랙백 핑 URL에 HTTP POST 요청을 합니다. 클라이언트는 컨텐츠 타입이 application/x-www-form-urlencoded인 Content-Type HTTP 헤더를 반드시 전송해야합니다. 클라이언트는 전송되는 데이터의 문자 인코딩을 Content-Type 헤더의 charset 요소에서 지정해야합니다.??

자세한 사항은 위의 사양서에서 보실 수 있습니다.

3. 주요 블로그 수정

ㄱ. 태터툴즈

a. 보내는 트랙백 수정

inc_function.php, 1411 줄.
fputs ($fp, "Content-type: application/x-www-form-urlencoded\r\n");
fputs ($fp, "Content-type: application/x-www-form-urlencoded; charset=자신의 인코딩\r\n");

b. 받는 트랙백 수정

rserver.php, 19 줄 [put_query(” 윗줄]에 다음 추가
eregi("charset=(.+)", $_SERVER["CONTENT_TYPE"], $charset);
$charset = $charset[1];
if($charset!="자신의 인코딩" && $charset!=NULL) {
if(function_exists(iconv)) {
$blog_name = iconv($charset, "자신의 인코딩", $blog_name);
$url = iconv($charset, "자신의 인코딩", $url);
$title = iconv($charset, "자신의 인코딩", $title);
} else if (function_exists(mb_convert_encoding)) {
$blog_name = mb_convert_encoding($blog_name, "자신의 인코딩", $charset);
$url = mb_convert_encoding($url, "자신의 인코딩", $charset);
$title = mb_convert_encoding($title, "자신의 인코딩", $charset);
} else {
echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">\n<response>\n<error>1</error>\n<message>Invalid Encoding</message>\n</response>";
exit;
}
}

[제대로 작동할지는 저도 몰라요 ㅜㅜ]

참고

▪전파발전소 – Trackback1.2
▪졸린 고양이님의 TrackBack Technical Specification 1.2
▪TrackBack Technical Specification 1.2