KS 완성형 코드체계에 대한 평가글 하나
Kim Sung-bom
제게 압축파일이 남아 있길래 뒤져 봤더니 파일 날짜가 1991년이니..벌써
8년 전의 이야기입니다. 그 때만 해도 여러 도스용 프로그램에서 조합형
한글코드를 사용하곤 했었는데..
그 '다른안시' 프로그램을 만드신 하형진님이 프로그램과 함께 배포하셨던
문서입니다. KS 완성형 코드체계에 대한 적나라한 비판글이군요. 이미 물
건너간 이야기이긴 합니다만, 그래도 오랜만에 읽어보니 재미있습니다.
그 당시에는 상당히 공감을 했었는데..
적혀 있는 연락처라고 해야 KETEL ID와 기숙사 주소 뿐이라 (그 당시만 해도
e-mail이..-.-) 어찌 연락을 취해 볼 방도가 없어서, 원저자의 허락을 받지
못하고 올리는 것을 양해해 주시길..
%% 아, 오랜만에 HWP 1.52를 써 봤더니 감회가 새롭습니다. :)
%% 아래 문서가 그 포맷으로 되어 있었거든요.
------------------------------------------------------------------------
KS 완성형은 ....
새 집에서 Robo Beg 올림 (이히. 이사했어요!)
저는 이 방면에 전문가는 아니지만, 컴퓨터를 사용하면서 몸으로 직접 느낀
바 있어 조금 잡담을 시작하려고 합니다.
현재 컴퓨터에서 사용되고 있는 각종 코드에 점수를 매겨 보면 어떤 결과가
나올까요?
우선 표준 ASCII 코드부터 시작합시다. 이 코드는 일반적인 영문장을 나타
내기에 필요한 대소 알파벱, 문장부호, 숫자, 기본적인 연산기호 등을 모두
포함하고 있읍니다. 그 이외에 사용되는 특수기호는 '~', '@', '#', '%',
'^', '&', '|', '\' 정도가 고작인데, 이것들은 각종 언어에서 메타문자의 기
능을 톡톡히 해 내고 있죠. 한마디로 불필요한 군더더기는 하나도 없읍니다.
점수는 당연히 만점!
우리는 IBM-PC를 사용하고 있으니까 이번에는 IBM의 확장 ASCII 코드를 살
펴볼까요? 이 코드에는 약간 불필요하게 느껴지는 그림문자들이 포함되어 있
지만, 우선 이 문자들은 일반적인 제어 문자의 영역에 있기 때문에 정상적인
방법으로는 사용이 불가능하고, 둘째, 그럼에도 불구하고 각종 유틸리티의 화
면 구성에 유용하게 사용되고 있지요. 즉 코드 영역을 낭비하지는 않습니다.
80h ~ 0afh 영역에는 라틴 계열의 언어에서 사용되는 알파벱들이 자리잡고 있
는데, 이것은 같은 계통의 언어들을 표시하기 위해서는 어쩔 수 없었을 것입
니다. (800.com의 설명을 읽어보면 잘 알 수 있어요. PC 자체의 문자만으로
이탈리아어를 모두 표현할 수 있다는 것이 처음에는 무척 신기했지요. 게다가
제 2 외국어로 대부분 스페인어를 배우고 있는 미국 사정으로는 이러한 문자
들이 필요할 겁니다.) 박스문자 영역은 어떤가요? 아마 PC에서 알파벱 다음으
로 많이 사용되는 코드 영역일 것입니다. 나머지 영역에는 자주 사용되는 그
리스 문자, 연산자 등이 있는데, 약간 지저분하게 보입니다. 실제로 PC에서는
표준 ASCII 영역과 박스문자 영역을 제외하면 거의 사용되고 있지 않습니다.
점수는 후하게 주면 80점 정도가 될까요?
이제는 자랑스러운 한국의 표준코드 KS 완성형을 살펴보도록 합시다. 우선
점수부터 말하죠. 당연히 0점! (마이너스로 내려갈 것을 걱정해서 처음부터
하한선을 0점으로 잡았요. 우리나라 체면도 있으니까......) KS 완성형은 한
문자가 0a1h ~ 0fdh 사이의 선두코드, 0a1h ~ 0feh 사이의 후속 코드로 이루
어져 있으니까 각 영역은 선두코드로 나타내도록 합시다. 0a1h 영역에는 IBM
확장 ASCII 코드의 찌꺼기가 소복히 모여 있는데, 일단 이 영역은 눈 감고
넘어가지요. 0a2h 영역에는 유치원 그림책을 만들 때나 사용될 만한 각종 도
형들이 늘어서 있읍니다. (전화기가 두대나 있고, 약간의 지도기호들, 어처구
니 없는 영문 약어들 (No. Co. TM a.m. p.m. Tel, 이러한 약어들은 당연히 영
문자로 입력해야 되는 것 아닌가요? 누가 이런 기호를 특수문자까지 사용해
가면서 입력할까요?)) 0a3h 영역에는 ASCII 문자들의 전각문자가 들어차 있네
요. 코드를 낭비하고 싶어 안달이 난 모양입니다. 0a4h 영역에는 한글 자모들
이 단독으로 모여 있는데, 이건 개떡같은 완성형에서는 별 수 없는 노릇입니
다만 조합도 되지 않는 고어 자모들은 왜 넣어 놓았을까요? 0a5h 영역에는 시
계 만들 때 사용될 만한 로마숫자(이걸 영문자로 입력하면 손이 부르트나
요?), 정수론 책을 쓸 때나 사용될 그리스문자들이 전부 모여 있네요. 0a6h
영역의 박스문자들은 정말 가관입니다. 단선, 복선으로 구성될 수 있는 박스
문자의 모든 조합을 포함하고 있는데, 이건 TG 특수문자의 간결한 박스문자들
과는 아주 대조적이지요. 0a7h 영역은 완전한 쓰레기입니다. MW, kV, Pa 등의
단위 기호를 영문자로 입력해야 하는 것은 너무나 당연한 일일 것입니다. (마
이크로 접두사는 차라리 080h ~ 0a0h 영역에 반각문자로 정의하는 쪽이 낫지
않을까요? 이런 점으로 볼 때 확장 ASCII 코드는 확실히 좋은 코드입니다.)
0a8h, 0a9h 영역은 아예 쓸모가 없는 문자들이므로 논하지도 맙시다. 0aah,
0abh의 히라가나와 카타카나에 이르면 변명도 못 할 겁니다. 이게 KS 완성형
인가요? 유네스코에서 제정할 만한 아시아 표준 코드지. (한자, 한글, 가나만
보면. 그리스어, 러시아어까지 있는 것을 보면 전세계 표준 코드로도 전혀 손
색이 없죠. 모르스 부호에다 각종 도량형, 그림문자들까지 포함된 것으로 봐
서 가히 전세계 표준 부호라 할 수 있을 겁니다.) 0ach영역에는 제정 당시에
한.소관계를 미리 예견했는지는 몰라도 러시아 알파벱이 모조리 놓여 있군요.
한글영역에 대해서는 별로 할 말도 없읍니다. 엄청난 용역비를 들여서
99.9% 빈도까지의 한글통계조사를 해 주신 표준연구소 관계자 여러분께 진심
으로 감사드리며, 아울러 이 통계자료는 dkby방식의 삼보조합형을 만들 때 아
주 요긴하게 사용되었음을 알려 드립니다.
이젠 한글영역의 2배가 넘는, 전체 코드 영역의 절반을 차치하는 한자쪽을
보도록 합시다. 상용한자도 천 몇백자밖에 안 되는데 왜 이렇게 많은 영역을
차지하는지 혹 궁금해 하신 적은 없나요? 모르시는 분들을 위해서 해답을 알
려 드리죠. 같은 한자라도 발음이 여러 개일 경우에는 발음별로 각각 한 코드
씩을 잡아먹도록 제작했기 때문입니다. (가령 '樂'자를 예로 들면 '악', '락
', '요' 세 글자와 '락'이 두음으로 발음될 때의 '낙'까지 합쳐서 코드 4개를
차지합니다.) 도대체 뭣때문에 두음법칙까지 고려해 가며 코드를 낭비했을까
요? (덕분에 '한글' 같은 워드프로세서에서 한글:한자 변환기능을 구현하기는
무척 손쉽게 되었죠.) 한글의 어원을 밝히기 위해서 한자를 발음대로 다 넣은
것은 가상한 일입니다만, 정작 중요한 한글은 전체 조합 가능한 글자의 1/5도
안되는 글자밖에 표시할 수 없다는 것은 넌센스입니다.
이제 평가를 시작할까요? 이건 완전한 쓰레기 코드입니다. 코드를 만들 때
고려해야할 기초적인 사항들조차 염두에 두지 않은 코드입니다. ('정보교환용
' 코드에는 꼭 필요한 '알짜'만 포함시킨다는 것은 상식적인 일입니다.) 정말
누구 말처럼 KS 완성형의 제작자들은 컴퓨터와 워드프로세서를 완전히 혼동하
고 있읍니다. (그렇다고 KS 완성형으로 워드프로세서를 만들면 좋을까요? 천
만에요! 아마 '글'의 수십분지 일에도 미치지 못할 것입니다.)
(참고: 본의아니게 제작자님들에게 직접 모독을 가하게 되어 무척 죄송하게
생각합니다. 하지만 이러한 평가는 모두 결과만을 놓고 한 것이며, 둘째로 국
민 세금으로 이따위 코드를 만들어 낸 사람들은 욕 먹어도 쌉니다.)
유감스러운 것은 이러한 KS 완성형이 무지막지한 정부의 압력에 의해 (무식
한 놈들이 힘은 세 가지고~) '통신용 코드'라는 가면을 쓰고 점점 더 확산되
고 있다는 사실입니다. (KETEL의 김형태 시삽님도 이 때는 욕 좀 먹어야 해
요. 게다가 신문사에서는 완성형만으로는 기사를 작성하기가 어려울 텐테
요...)
더욱 중요한 것은 (제게) 여러분이 잠시나마 애용할 다른안시가 통신용 한
글 프로그램으로 전락해 버린다는 것입니다. 제가 이 프로그램을 만든 동기는
일반 영문 프로그램에서도 한글을 편리하게 사용할 수 있도록 하기 위해서이
지, 결코 완성형을 확산시키기 위해서 만든 것은 아닙니다. (버젼 0.02까지는
도깨비 코드와 삼보조합형만을 프로그램 내에서 지원했죠. 이젠 이율배반처럼
보이지 않나요? 현재의 다른안시는 완성형코드를 아주 '편리'하게 사용할 수
있도록 박스문자까지 살려 주는데요.) 다른 지조있는 한글 프로그램들과 달리
다른안시에서 KS 완성형을 지원하는 까닭은 사용자들이 불편하지 않도록 하기
위해서입니다. (이점에 있어서는 황태욱씨와 의견이 같습니다. 고래싸움에 새
우등이 터질 수는 없죠.)
제가 여러분에게 당부하고 싶은 것은, 절대로 일반적인 목적으로 KS 완성형
을 사용하지 말라는 것입니다. KS 완성형은 어디까지나 '통신용 코드'이지 PC
내에서의 정보처리용 코드가 아닙니다. 또한 통신상에서는 절대로 특수문자나
한자를 사용하지 맙시다. 이것은 KS 완성형의 사용기반이 튼튼해 지는 것을
부채칠하는 결과를 초래할 뿐입니다. 한가지 다행스러운 일은 표준 연구소에
서 기존 KS 완성형의 장점은 전부 죽이고 단점만을 대폭 강화한 새로운 졸작
완성형을 발표했다는 것입니다. 어차피 PC에서는 사용되지도 못할 이 코드를
관례대로 정부는 강력하게 밀 것이고, 다시 표준 코드문제가 대두되어 사용자
들을 혼란시키다가 결국 조합형 코드가 사용자 사이에 표준으로 굳어지겠죠.
이렇게 되면 정부에서 아무리 '입김'을 넣어 봐야 별 소용이 없을 것입니다.
저는 현재 조합형으로 가장 널리 사용되고 있는 삼보조합형을 표준 코드로 적
극 권장하고 있읍니다. 이 코드는 현재의 텍스트환경인 도스 뿐만 아니라 앞
으로 다가올 구이 환경에서도 사용될 수 있을 만한 자격이 있읍니다. (맥의
한글토크를 보세요. 구이하고는 전혀 상관도 없는 완성형을 한글코드로 사용
하는 꼬락서니를...... 그런데 한글 윈도우즈도 완성형만을 지원한다고 하니
PC 사용자들도 똑같은 운명에 처해질지 모릅니다. 그러나 일반 사용자들은 이
러한 문제에 너무나도 관심을 가지고 있지 않아요.)
이제 잡담은 그만 둘까요?
------------------------------------------------------------------------
--
김승범
conan
그리고서 8년이 지나 완성형이 완전히 장악해 버렸군요.
...
Kim Sung-bom
>
> 재미있네요.
> 그리고서 8년이 지나 완성형이 완전히 장악해 버렸군요.
> ...
결정적인 요인은 아무래도 한글윈도우겠지요.
각각의 프로그램에서 조합형으로 처리하던 한글을, OS가 완성형으로 바꾸어
떠맡으면서 개별 응용프로그램들은 좋든 싫든 완성형 한글을 써야
했으니까요.
(한글 처리를 OS가 맡게 됨으로써 응용프로그램 개발자들이 따로따로 한글
처리에 신경을 쓸 필요가 없게 되었다는 점은 분명 좋은 일이었습니다만.)
간혹 아래아한글(HWP)같은 반항아(?)가 있기도 했지요. 하지만 누구나 쉽게
할 수 있는 선택은 분명 아니었고요. 한컴 정도의 기업이니 가능했겠죠.
완성형과 조합형, 어느 쪽이든 장점과 단점이 있어서 논란도 많았지만,
가장 아쉬운 것은 그렇게 한글 코드가 한쪽으로 기울어지게 된 과정이,
컴퓨터 사용자들과 프로그래머들의 합의 또는 국가적인 검토에 기반한
정책에 기인한 것이 아니라 외국의 한 소프트웨어 회사(MS)의 힘에
전적으로 기인했다는 것입니다. 우리는 우리의 주장도 별로 제대로
펼치지 못하고 있다가 MS의 힘에 끌려다녀야 했습니다.
그렇게 시작된 완성형의 시대는 지금까지도 이어지고 있죠.
언제쯤이면 유니코드가 완성형을 몰아내고 보편적으로 사용될 수 있을지
아직 모르겠습니다만..
--
김승범
YongJoo Lee
사용된다는 내용을 읽은적 있습니다. MicroSoft에서 각국마다 (한국, 일본,
중국, 등등) 다른 버전을 만드는 비용을 줄이기위해서 unicode를 사용한다고요.
Kim Sung-bom <musi...@bawi.org> wrote in message
news:3795EB8E...@bawi.org...
> conan wrote:
> >
> > 재미있네요.
> > 그리고서 8년이 지나 완성형이 완전히 장악해 버렸군요.
> > ...
>
Young Gul Park
YongJoo Lee <yongj...@hotmail.com> wrote in message
news:7nbo9g$1igg$1...@hub.org...
> 완성 / 조합형에 대해서 잘 모르지만, unicode가 다음 (windows 2000)부터
> 사용된다는 내용을 읽은적 있습니다. MicroSoft에서 각국마다 (한국, 일본,
> 중국, 등등) 다른 버전을 만드는 비용을 줄이기위해서 unicode를 사용한다고요.
Unicode는 NT4에서도 사용되었습니다. 심지어 unicode 지원은 Win9x 버전에도
있었습니다. 다만 외부적으로는 통합 완성형(CP 949?)을 썼지요. (왜 그랬는지는
저도 모르겠습니다.)
Windows 2000과 NT4와 다른 점이라면 Win2K는 worldwide single binary로
만들어져 있습니다. 그러므로 OS 자체적으로는 차이가 없습니다. 한글
프로그램을 영문 Win2k에서 쓸 수 있는 것은 물론이고 굳이 한글을 쓰기 위해
한글 Windows를 쓰지 않아도 될 것입니다.
--
/- Young Gul Park (MS Beta/283450)
- Homepage/iya <URL:http://www.sit.wisc.edu/~ygpark/>
Jungshik Shin
: 그 '다른안시' 프로그램을 만드신 하형진님이 프로그램과 함께 배포하셨던
: 문서입니다. KS 완성형 코드체계에 대한 적나라한 비판글이군요. 이미 물
: 건너간 이야기이긴 합니다만, 그래도 오랜만에 읽어보니 재미있습니다.
: 그 당시에는 상당히 공감을 했었는데..
물 건너갔을 뿐 아니라 저자의 ISO-2022에 대한 "무지"(지금 이 그룹을
읽지도 않는 저자에게 이런 말을 해서 무척 죄송하지만, 이렇게 얘기할 수
밖에 없습니다. 특히 C1 영역을 침범해 쓰고 있는 IBM의 어떤 code page에
대한 평가 등을 보면)를 적나라하게 드러내고 있군요 :-) 단, 그 당시에는
저도 저자와 똑같거나 더 심하게 무지했다는 것을 밝혀 둡니다. (따라서,
저도 이미 10년 가까이 묵은 글을 놓고 저자를 욕할 수 있는 처지가
아닙니다. 이런 옛 글을 들쳐내 올리신 김승범 님 잘못이 큽니다 :-)) 더
이상 길게 답을 달지 않는 이유는 이런 류의 글에 대해서 이미 오래 전에 이
뉴스 그룹에서 몇 차례 쓴 적이 있기 때문입니다. (Dejanews 등에서
han.comp.hangul에 제가 쓴 글을 찾아 보세요) 그래도 아주 조금만 씁니다.
한글을 컴퓨터에서 어떻게 표현하는 것이 좋으냐는 이 글의 저자가
생각하는 것처럼 그렇게 간단하지도 않고, 그 저자가 옹호하는 KS X
1001:1997(KS C 5601-1992) 부록 3의 모태라고 볼 수도 있는 삼보 조합형과
같은 방식이 절대적으로 좋다고 할 수도 없습니다. 한자를 전혀 쓰지 않고 살
수 있었다면 Thai 표준이 Thai 글자를 표기하는 것과 비슷한 방식(80년대
중반 Unix에서 쓰던 n-byte 조합과 비슷)을 쓸 수도 있었겠지요. 하지만, ,
우리 문자 생활에서 한자를 완전히 배제할 수 없는 현실적 제약은 한글 처리
문제를 더 어렵게 만듭니다. 또, 한글만이 제기하는 어려움도 있습니다.
'가나다'는 세 글자로 다뤄야 합니까? 여섯 글자(자모를 따로 세어서)로
다뤄야 합니까? 보통 답은 전자겠지요. 하지만, 누군가 어떤
이가 여섯자라고 누군가 외국인의 말을 빌어서 얘기하자면 '한글은 무척
과학적이라고 생각할 수도 있지만, 바로 그 점 때문에 우리를 무척이나 골치
아프게 하는 표기 방법'입니다.
또 한가지 MS가 미워도 MS가 잘못이 아닌 것을 MS 잘못으로 돌려서도
곤란합니다. KS X 1001:1997 (KS C 5601-1987/1992)이 널리 쓰이는데
MS-Windows가 일정 역할을 했을지 몰라도 그렇다고 MS-Windows *때문*에 KS X
1001이 절대적인 지위를 차지했다고 하는 것은 문제가 있습니다.(단, 이
문장이 암시하듯이 그것이 널리 쓰인 것이 꼭 나쁜 것만은 아니었습니다)
이미 한글 MS-Windows가 나올 무렵에는 인터넷(과 Unix) 등 때문에라도
ISO-2022 체제에 들어 맞지 않는 삼보 조합형 등은 거의 쓸 수 없거나
쓰더라도 상당히 복잡한 문제를 일으킬 상황이었습니다.
MS의 잘못이라고 할 수 있는 것은 KS X 1001 해설 3에서 언급하고 있는
8byte seq.를 써서 모든 한글 음절을 표현할 수 있는 방법이 있고, 그것을
충분히 MS-Windows 95 도입 시점에 적용할 기술이 있었음에도 불구하고-
그들이 아랍어, 히브리어, 타이어 윈도우에서 보여 준 바와 같이- 한글을
중국 Hanzi나 일본 kanji+kana와 똑같은 방식으로 "편하게" 처리하려고
Windows-949를 채택한 것입니다.
: 적혀 있는 연락처라고 해야 KETEL ID와 기숙사 주소 뿐이라 (그 당시만 해도
: e-mail이..-.-) 어찌 연락을 취해 볼 방도가 없어서, 원저자의 허락을 받지
이 글을 처음 쓴 것은 아마 1989년이나 1990년 초인 것 같군요. 저자는
1990년 후반이나 1991년에는 거의 확실히 Internet email 주소가 있었을
것입니다 :-)
신정식
Kang, Kyung-soo
>
> ...또, 한글만이 제기하는 어려움도 있습니다.
> '가나다'는 세 글자로 다뤄야 합니까? 여섯 글자(자모를 따로 세어서)로
> 다뤄야 합니까? 보통 답은 전자겠지요. 하지만, 누군가 어떤
> 이가 여섯자라고 누군가 외국인의 말을 빌어서 얘기하자면 '한글은 무척
> 과학적이라고 생각할 수도 있지만, 바로 그 점 때문에 우리를 무척이나 골치
> 아프게 하는 표기 방법'입니다.
이 음절/음운 방식의 갈등은 우선 글꼴 개발을 어렵게 만들기에, 컴퓨터가
나오기 이전부터 많은 국어학자들이 '풀어쓰기'의 가능성을 모색한 바 있습니
다. 일찍이 한힌샘 주시경도 그 가능성을 생각했으며, 외솔 최현배는 옥중에서
'한글 풀어쓰기 알파벳'을 필생의 과업으로 고안해 냈습니다.
특히 컴퓨터와 관련지어, '한글 풀어쓰기'의 가능성이 코드의 관점에서, 또
글꼴 디자인의 관점에서 몇몇 제안들이 제기되었어요. 김정수 박사(한양대)는
한글 풀어쓰기에 꽤 마지막까지 매달리다가, 최근에는 이런 이야기를 안하는
데 비추어 보면, 아마 거의 포기하지 않았나 싶군요.
어쨌든 그렇다고 하여 한글이 '과학적'인 글자가 아니라고 말할 수는 없지
만, 컴퓨터에서 표현해 내기가 '골치 아픈' 것은 사실입니다.
> 이미 한글 MS-Windows가 나올 무렵에는 인터넷(과 Unix) 등 때문에라도
> ISO-2022 체제에 들어 맞지 않는 삼보 조합형 등은 거의 쓸 수 없거나
> 쓰더라도 상당히 복잡한 문제를 일으킬 상황이었습니다.
예를 들어, MS-Windows 자체적으로는 2바이트 조합형을 쓰고(PC들이 WIN/NT
에 물려 있는 것까지 포함하여), 외부와 교신할 때는 KS완성형으로 변환해서
쓰는 방식은 '치명적'인 기술적 난점 때문에 고려할 수 없다...고 말할 수 있
습니까, 없습니까?
만약 '치명적'인 난점이 아니라면, 이 길은 충분히 고려됐어야 마땅했다고
볼뿐더러, 꼭 그 길로 갔어야 했다고 생각합니다. 만약 '치명적'인 난점이라
고 한다면, 아랍/히브리/타이 사람들은 어떻게 하여 조합형을 계속 쓰고 있는
지... 의문입니다.
제가 기억하기로는, MS사가 2바이트 조합형을 채택하지 않은 근거로 든 것
은, (무슨 기술적인 난점 때문이라기보다) 기존의 KS완성형 데이터를 변환하
는 데 필요 이상의 비용이 든다는 것이었습니다(왜냐하면 나중에는 또 유니코
드로 변환해야 하기 때문에).
어쨌든 지금은 유니코드를 놓고 고려해야 할 시점이기에, (물론, 인터넷 편
지까지 UTF-8으로 간다고는 거의 생각하지 않습니다), 다 지나간 이야기이긴
하지만, 이런 역사적 경과는 훗날을 위해서도 다시 한번 차분히 음미할 만하
다고 봅니다. 칸트의 격언을 빌리자면, 국어학이 없는 컴퓨터는 눈이 멀었고,
컴퓨터가 없는 국어학은 공허해지게 마련입니다.
--
강경수
kang...@chollian.net
꼭 들를 뉴스그룹 <news:han.answers> <news:han.test>
Kim Sung-bom
> : 문서입니다. KS 완성형 코드체계에 대한 적나라한 비판글이군요. 이미 물
> : 건너간 이야기이긴 합니다만, 그래도 오랜만에 읽어보니 재미있습니다.
> : 그 당시에는 상당히 공감을 했었는데..
>
> 읽지도 않는 저자에게 이런 말을 해서 무척 죄송하지만, 이렇게 얘기할 수
> 밖에 없습니다. 특히 C1 영역을 침범해 쓰고 있는 IBM의 어떤 code page에
> 대한 평가 등을 보면)를 적나라하게 드러내고 있군요 :-) 단, 그 당시에는
> 저도 저자와 똑같거나 더 심하게 무지했다는 것을 밝혀 둡니다. (따라서,
> 저도 이미 10년 가까이 묵은 글을 놓고 저자를 욕할 수 있는 처지가
> 아닙니다. 이런 옛 글을 들쳐내 올리신 김승범 님 잘못이 큽니다 :-)) 더
> 이상 길게 답을 달지 않는 이유는 이런 류의 글에 대해서 이미 오래 전에 이
> 뉴스 그룹에서 몇 차례 쓴 적이 있기 때문입니다. (Dejanews 등에서
> han.comp.hangul에 제가 쓴 글을 찾아 보세요) 그래도 아주 조금만 씁니다.
>
음. 한글 코드를 조합형/완성형 중 어느 것으로 하느냐, 어떤 글자에 어떤
코드값을 배정하느냐, 이런 것도 중요한 문제이지만, 제가 특히 공감했던
것 중에 하나는 현재의 KS 완성형에는 쓸데 없는 글자가 필요 없이 너무
많이 들어가 있다는 점이었습니다. (제가 인용한 원문에도 그에 대한 비판이
상당 부분을 차지하고 있죠?)
그렇게 글자를 많이 집어넣어 놓고도, 정작 han.sci.math 등에서 조금만
수식을 표현하려고 해도, 종종 '아, 이러이러한 딱 몇 글자만 더 있었어도
좋았을 텐데'라고 생각하며 어려움을 겪게 하는 점이 불만스러웠습니다.
(길다란 적분 기호의 위끝과 아래끝 기호는 심지어는 1바이트 코드 체계인
IBM Extented ASCII에도 있습니다. -.-;)
그리고, 삼보 조합형이 어떤 점에서 ISO-2022라는 체제에 들어맞지 않고
복잡한 문제를 일으키는지 좀더 말씀해 주실 수 없으시겠습니까?
비슷한 얘기를 여기저기서 듣기는 했는데.. 궁금해서 그럽니다.
> 이 글을 처음 쓴 것은 아마 1989년이나 1990년 초인 것 같군요. 저자는
> 1990년 후반이나 1991년에는 거의 확실히 Internet email 주소가 있었을
> 것입니다 :-)
파일 날짜는 모두 1991년 8월로 되어 있군요. 아무튼.. ^^
--
김승범
박종대
> 그리고, 삼보 조합형이 어떤 점에서 ISO-2022라는 체제에 들어맞지 않고
> 복잡한 문제를 일으키는지 좀더 말씀해 주실 수 없으시겠습니까?
> 비슷한 얘기를 여기저기서 듣기는 했는데.. 궁금해서 그럽니다.
0x80~0x9F 사이의 영역에 있는 글자(?)들도 0x00~0x1F 사이에 있는 글자(??)처럼
제어코드입니다.
조합형으로 "가"라는 글자는 0x8861로 표현됩니다. 이 중에서 0x88이라는 code는
Tab Set(HTS)란 제어코드이기도 하고요. "나"의 첫 글자는 "0x90"으로
Device Control String(DCS)에 해당합니다.
> 파일 날짜는 모두 1991년 8월로 되어 있군요. 아무튼.. ^^
원저자의 E-mail 주소는 전에 알려드렸죠?
--
박종대
-- ' C-language Edition
#define cdpark /* KAIST, CSDept, Theory of Computation Lab. */
#include <signature.h> /* the Hitchhiker's Guide to the Internet?? */
Jungshik Shin
: Jungshik Shin wrote:
:>
:> 물 건너갔을 뿐 아니라 저자의 ISO-2022에 대한 "무지"(지금 이 그룹을
:> 읽지도 않는 저자에게 이런 말을 해서 무척 죄송하지만, 이렇게 얘기할 수
:> 밖에 없습니다. 특히 C1 영역을 침범해 쓰고 있는 IBM의 어떤 code page에
:> 대한 평가 등을 보면)를 적나라하게 드러내고 있군요 :-) 단, 그 당시에는
: (길다란 적분 기호의 위끝과 아래끝 기호는 심지어는 1바이트 코드 체계인
: IBM Extented ASCII에도 있습니다. -.-;)
원래 답장에서도 썼듯이 이른바 'IBM Extended ASCII'(ASCII는 ASCII 하나
밖에 없습니다. Extended ASCII니 뭐니 하는 것은 다 이상한 얘기입니다)
역시 ISO-2022의 C1 영역을 침범하고 있습니다.
참, Unicode에도 *아직*은 말씀하신 적분 기호 위 아래 부분은 없을
것입니다. MathML 때문에 그런 것을 넣어야 하느냐 말아야 하느냐 논란을
벌이고 있는 것으로 미루어 본 것이므로 틀릴 수 있습니다.
:> 뉴스 그룹에서 몇 차례 쓴 적이 있기 때문입니다. (Dejanews 등에서
:> han.comp.hangul에 제가 쓴 글을 찾아 보세요) 그래도 아주 조금만 씁니다.
....
: 그리고, 삼보 조합형이 어떤 점에서 ISO-2022라는 체제에 들어맞지 않고
: 복잡한 문제를 일으키는지 좀더 말씀해 주실 수 없으시겠습니까?
: 비슷한 얘기를 여기저기서 듣기는 했는데.. 궁금해서 그럽니다.
박종대 님 답변 혹은 Dejanews 검색 :-)
Kang, Kyung-soo
>
> Kim Sung-bom <musi...@bawi.org> wrote:
>
> > 그리고, 삼보 조합형이 어떤 점에서 ISO-2022라는 체제에 들어맞지 않고
> > 복잡한 문제를 일으키는지 좀더 말씀해 주실 수 없으시겠습니까?
> > 비슷한 얘기를 여기저기서 듣기는 했는데.. 궁금해서 그럽니다.
>
>
> 조합형으로 "가"라는 글자는 0x8861로 표현됩니다. 이 중에서 0x88이라는
> code는 Tab Set(HTS)란 제어코드이기도 하고요. "나"의 첫 글자는 "0x90"
> 으로 Device Control String(DCS)에 해당합니다.
2바이트 조합형은, 뜻을 좁혀 말할 때는 '조합형'이라고 부르기가 곤란합니
다. 왜냐하면 '조합형'이라는 용어를 엄밀하게 쓸 때는, 한 음운당 몇 바이트
식으로 배정되어야 하기 때문이에요. 'ASCII 호환'을 고려한다면, 한글 한 음
운당 2바이트, 한 음절당 적어도 6바이트로 조합하여 쓰는 방식이 참된 '조합
형'입니다.
2바이트 조합형은 말하자면 '편법'입니다. 맨 처음 비트는 '영/한'을 나타내
고, 나머지 15비트를 한 음운당 5비트(32코드점)씩 초성-중성-종성에 배정합니
다. 따라서 코드점의 여유가 없기 때문에, 제어/메타 코드 영역에까지 글자를
배정할 수밖에 없으며, 국제 규약을 어기게 마련입니다.
그러므로 여러 플랫폼이 얽혀 있달지, 국제간의 네트워크가 이어져 있는 곳
에서는 이 2바이트 조합형은 고려할 수 없습니다. 적어도 인터넷 같은 데서는
쓸 수 없다는 이야깁니다.
유니코드 2.*에는, 현대 한글 음절 1만 1,172자 모두가 한 군데에 모여 있
습니다. 이렇게 순서대로 1만 1,172 음절을 배열했기 때문에, 간단한 계산에
따라 초성-중성-종성 음소들을 뽑아낼 수 있습니다. 다시 말해, (불완전한 음
절을 제쳐놓는다면) 사실상 2바이트 조합형과 다를 바 없습니다.
사정이 이렇게 좋아지게 된 건, 한자를 더 집어넣자는 중국/대만/일본 등의
요구를 뭉개고 한국 손을 들어준 빌 게이츠의 공헌이라 할 수 있어요. 그 이
유가 MS사의 기업적인 이해관계에 있든 아니든 간에, 이 유니코드의 1만 1,172
음절로써, 적어도 현대 한글에 한해서는, 이를테면 기업 환경, 옛말을 쓸 필요
가 없는 개인 환경에서는, 한글 코드 문제가 해결됐다고 봐도 됩니다.
남은 문제는, 옛말을 고려할 필요가 있는 환경에서는 어떻게 처리하느냐...
하는 것입니다. 물론, 이때는 한글 자모를 끌어써서 조합형으로 처리해야 하겠
지요.
박종대
Unicode에 없는 걸 함부로 말하긴 힘듭니다.
U+2320 Top half integrral
U+2321 Botom half integrral
그냥 있을만한 건 다 있다고 보면...
Jungshik Shin
: Jungshik Shin <js...@pantheon.yale.edu> wrote:
:> 참, Unicode에도 *아직*은 말씀하신 적분 기호 위 아래 부분은 없을
:> 것입니다.
: Unicode에 없는 걸 함부로 말하긴 힘듭니다.
: U+2320 Top half integrral
: U+2321 Botom half integrral
이런.... 책을 반납해 버려서 웹에서 찾기가 귀찮아 안 찾았더니 이런
문제가 있군요...
: 그냥 있을만한 건 다 있다고 보면...
그렇게 보고 싶지만......:-) MathML에서 상당수의 수학 관련 기호를
사용자 정의 영역에 두었습니다. Unicode와 ISO-10646에 하루속히 넣어야
하지만, 시간이 걸리는 것은 어쩔 수 없습니다. 그리고, 아직도 넣어야
할 글자는 많이 남아 있습니다. (한자만 해도 한참 모자라고...)
신정식
gahi_man
unicode의 글제체(폰트)는 어떻게 제공하나요?
엄청난 크기에, 일관성있는 지원이 가능한지...
굴림체로 프랑스어, 러시아어, 잠비아어, 태국어, 아랍어 모두 지원해야
하나요?
궁체는 ??
Kang, Kyung-soo
>
> Unicode/UTF-8 등을 개발한 이유는 진정한 다국어 처리를 위한 것입니다.
> 물론 어느 정도 충실한 한글 처리를 위한 좋은 기반도 제공합니다. 현재
> 가능한 방법으로 가장 합리적입니다.
>
> 앞으로 EUC-KR 대신 UTF-8을 charset로 붙이고 포스팅할 그날이 오기를...
이를테면, 한글 유즈넷에서 글쓸 때 "charset=UTF-8"을 붙일 날이 언제쯤 올
것인가? 지금의 현안은 아니지만, 제 예상으로는, 내다볼 수 있는 기간 안에는
그런 날이 오기 힘들 걸로 봅니다.
그 근거를 간단히 적으면 대충 다음과 같습니다 :
(1) 일단, EUC-KR과 UTF-8이 뒤섞여 사용된다고 봐야 합니다. 이런 전제하에
서, 어떤 메시지의 charset이 EUC-KR인지, UTF-8인지 합리적으로 확인할 만한
방법이 없습니다. MIME charset을 안 붙이거나, 붙이더라도 잘못 붙일 가능성
이 적지 않기 때문입니다.
(2) 이렇게 되면, 글을 읽는 사용자는 EUC-KR과 UTF-8 인코딩 사이를 왔다갔
다하면서 봐야 하기 때문에 엄청 짜증나겠지요.
특히 목록 창에서는, EUC-KR과 UTF-8이 뒤섞여 있기 때문에, 그야말로 뒤죽박
죽이 됩니다. 설사 뉴스 프로그램이 발전하여 머리글의 charset을 EUC-KR,
UTF-8식으로 각각 따로 보여줄 수 있다손 치더라도(이런 기능이 왜 필요한지...
조차 의문이긴 합니다만), (1)번의 근거에 따라 그 머리글이 EUC-KR인지 UTF-8
인지 확인할 만한 방법이 없으므로, 결국은 뒤죽박죽이 될 것입니다.
혹시라도 뉴스 프로그램이
첫째, EUC-KR, 한국어로 된 UTF-8 두 가지를 모두 '한국어(자동)'로 자동 인
식해 내고,
둘째, 머리글을 각 charset에 따라 자동적으로, 또 따로따로 보여줄 수 있으
며,
셋째, 위의 두 가지 기능이 주요 플랫폼에서, 주요 나라에서, 주요 프로그램
에서 모두 가능하다, 다시 말하면 매우 일반화되었다
는 세 가지 전제하에서라면, 한글 유즈넷에서 UTF-8을 쓸 날이 좀더 빨리 올 것
입니다.
이와 달리 한글 웹 페이지에서는, 지금 당장이라도 UTF-8을 쓸 수 있습니다.
다만, (한자를 쓸 경우에는) CJK 한자가 어느 나라 한자인지를 꼭 표시해 주는
게 권장됩니다. (이런 목적으로 쓰이는 MIME 머리글이 뭔지는 모르겠지만, 이를
테면 "Content-Language=ko")
왜냐하면 한자는 중국/대만/일본/한국에서 각각 글자꼴도 다르고, 쓰이는 맥락
도 다르기 때문이며, 경우에 따라서는 유니코드의 예비 영역에 자기 나라에서만
정해 놓은 한자를 더러 쓸 수 있기 때문입니다.
Sungwon Cho
news:cuXgL9a3#GA....@news.thrunet.com...
: unicode의 글제체(폰트)는 어떻게 제공하나요?
"Font Linking"이라는 기술이 있습니다. 해당하는 언어의 폰트로 표시하는
것이라고 이해하시면 됩니다. Internet Explorer, MS Office, Win2K 등에서
사용하고 있습니다.
Internet Explorer가 UTF-8로 인코딩한 페이지를 표시할 때 한글이면 한글,
영문 알파벳이면 알파벳 식으로 알아서 해당하는 언어의 폰트로 처리해줍니다.
Netscape인 경우 Unicode를 직접 지원해주는 NT가 아니면 이를 제대로 표시
해주지 못합니다. (사용자가 직접 폰트 설정을 바꾸어 주어야 합니다.)
MS Typography <http://www.microsoft.com/typography/default.asp>에서
Font properties extension를 다운로드하여 설치하시면 Windows에 들어있는
각 TrueType 폰트가 Unicode (ISO 10646-2) 중 어떤 영역을 지원하는지 알
수 있습니다. 아니면... NT인 경우 Unicode 문자표가 기본으로 들어 있으므로
그것을 통해 직접 확인할 수도 있습니다. (이 thread에서 언급하는 글자들도
물론 찾아볼 수 있습니다.)
특히 Tahoma 서체가 가장 다양한 영역을 지원하는 편입니다. 히브리어나
아랍어도 지원합니다. Office2K에 들어있는 서체로 상당히 다양한 언어를
지원하는 것이 있는데, 지금 생각나지 않는군요...
여하튼 한 종류의 서체로 Unicode의 모든 영역을 지원해줄 필요는 없습니다.
해당 폰트에서 지원하지 않는 영역은 기술적으로 처리할 수 있습니다.
--
Sungwon Cho, Andrew
// Internet Explorer Tips <http://members.iworld.net/aster/>
// The <news:han.comp.www.browsers> Internet Explorer FAQ
Sungwon Cho
news:7noqpb$295$1...@photon.hgs.yale.edu...
: YongJoo Lee <yongj...@hotmail.com> wrote in message
: news:7nbo9g$1igg$1...@hub.org...
: > 완성 / 조합형에 대해서 잘 모르지만, unicode가 다음 (windows 2000)부터
: > 사용된다는 내용을 읽은적 있습니다. MicroSoft에서 각국마다 (한국, 일본,
: > 중국, 등등) 다른 버전을 만드는 비용을 줄이기위해서 unicode를 사용한다고요.
: Unicode는 NT4에서도 사용되었습니다. 심지어 unicode 지원은 Win9x 버전에도
: 있었습니다. 다만 외부적으로는 통합 완성형(CP 949?)을 썼지요. (왜 그랬는지는
: 저도 모르겠습니다.)
: Windows 2000과 NT4와 다른 점이라면 Win2K는 worldwide single binary로
: 만들어져 있습니다. 그러므로 OS 자체적으로는 차이가 없습니다. 한글
: 프로그램을 영문 Win2k에서 쓸 수 있는 것은 물론이고 굳이 한글을 쓰기 위해
: 한글 Windows를 쓰지 않아도 될 것입니다.
덧붙이자면...
Windows 2000 Professional은 3가지 버전으로 나올 것입니다. 3가지 모두
60 여개 언어를 자유롭게 입출력할 수 있습니다.
- Windows 2000 Professional English Version
- Fully-localized language editions of Windows 2000 Professional
- Windows 2000 Professional MultiLanguage Version
Fully-localized language edition은 현재 NT4와 같이 한국어, 일본어,
프랑스어 버전 등으로 각각 따로 나오는 것이며 메뉴와 도움말 등을 전부
로컬화한 것입니다.
MultiLanguage Version은 IE5에서 이미 선보인 것처럼 메뉴, 도움말,
박스 등 사용자 인터페이스를 필요에 따라 바꿀 수 있는 기능을 제공합니다.
간단한 사용자 설정 조정으로 영어, 한국어, 일본어 NT 등으로 곧바로 바꿀
수 있습니다.
이와 같이 로컬화 버전을 만드는 비용이 줄이기 위해서 Unicode(NT는 오래
전부터 지원했습니다.)와 다국어 IME를 기본으로 지원하고 사용하는 것이
아닙니다. 그러한 이야기는 근거없는 소문에 지나지 않습니다.
조합형/완성형 이야기가 타임 캡슐처럼 등장했는데, 조합형은 완성형 확장에
지나지 않습니다. 도토리나 상수리나 그게 그것이지요. :-)
Unicode/UTF-8 등을 개발한 이유는 진정한 다국어 처리를 위한 것입니다.
물론 어느 정도 충실한 한글 처리를 위한 좋은 기반도 제공합니다. 현재
가능한 방법으로 가장 합리적입니다.
앞으로 EUC-KR 대신 UTF-8을 charset로 붙이고 포스팅할 그날이 오기를...
--
Jungshik Shin
: Jungshik Shin 작성:
:>
:> ...또, 한글만이 제기하는 어려움도 있습니다.
:> '가나다'는 세 글자로 다뤄야 합니까? 여섯 글자(자모를 따로 세어서)로
:> 다뤄야 합니까? 보통 답은 전자겠지요. 하지만, 누군가 어떤
:> 이가 여섯자라고 누군가 외국인의 말을 빌어서 얘기하자면 '한글은 무척
:> 과학적이라고 생각할 수도 있지만, 바로 그 점 때문에 우리를 무척이나 골치
:> 아프게 하는 표기 방법'입니다.
: 이 음절/음운 방식의 갈등은 우선 글꼴 개발을 어렵게 만들기에, 컴퓨터가
: 나오기 이전부터 많은 국어학자들이 '풀어쓰기'의 가능성을 모색한 바 있습니
: 다. 일찍이 한힌샘 주시경도 그 가능성을 생각했으며, 외솔 최현배는 옥중에서
: '한글 풀어쓰기 알파벳'을 필생의 과업으로 고안해 냈습니다.
외솔에 대한 얘기는 저도 가끔 했지요 :-) 하지만, 풀어 쓰기를 하면
한글이 가지는 장점 하나를 포기해야 합니다(그것이 컴퓨터에서 구현을 골치
아프게 하는 것이기도 하지만요). 그 장점은 보는 각도에 따른 가독성의
편차가 작다는 것입니다. 로마자로 쓰인 책을 거꾸로 들고 읽는 것과
한글로 쓰인 책을 거꾸로 읽는 것은 가독성에서 큰 차이가 있지요(그것이
얼마나 중요한지는 ........) 어쨌든, 풀어 쓰기를 했으면 여러 가지로
편했을 수도 있다는 생각은 저도 자주 합니다... 아, 한글, 한글, 한글
............
:> 이미 한글 MS-Windows가 나올 무렵에는 인터넷(과 Unix) 등 때문에라도
:> ISO-2022 체제에 들어 맞지 않는 삼보 조합형 등은 거의 쓸 수 없거나
:> 쓰더라도 상당히 복잡한 문제를 일으킬 상황이었습니다.
: 예를 들어, MS-Windows 자체적으로는 2바이트 조합형을 쓰고(PC들이 WIN/NT
: 에 물려 있는 것까지 포함하여), 외부와 교신할 때는 KS완성형으로 변환해서
: 쓰는 방식은 '치명적'인 기술적 난점 때문에 고려할 수 없다...고 말할 수 있
: 습니까, 없습니까?
그렇게 할 수*도* 있었지요. 하지만, 그래야 했다고 말하기는 힘들군요.
그러느니 차라리 KS X 1001:1997 해설 3의 방법이 낫다고 생각합니다.
님이 말씀하신 경우가 일본의 경우이지요. MS-DOS/MS-Windows/MacOS는
Shift-JIS (ISO-2022 위반)을 쓰고 Unix는 EUC-JP를 쓰며 인터넷에서는
ISO-2022-JP를 주로 씁니다.
: 만약 '치명적'인 난점이 아니라면, 이 길은 충분히 고려됐어야 마땅했다고
: 볼뿐더러, 꼭 그 길로 갔어야 했다고 생각합니다. 만약 '치명적'인 난점이라
: 고 한다면, 아랍/히브리/타이 사람들은 어떻게 하여 조합형을 계속 쓰고 있는
: 지... 의문입니다.
'조합형'이란 단어를 어떤 뜻으로 쓰고 계신지 잘 모르겠군요.
아랍/히브리/타이어를 위한 글자셋 가운데 널리 쓰이는 것은 이른바
삼보/상용 조합형과는 달리 ISO-2022를 전혀 위반하지 않습니다.
(ISO-2022의 Gx 1byte 공간은 94자로 이들 표기 체제의 낱자를 모두 담는데
별 부족함이 없습니다. 만일 2byte 공간을 쓴다면 94x94로 더욱 넓고요.)
'조합형'을 어떤 표기 체제의 이전 표현에서 화면이나 종이에 그 표기 체제를
표시하기 위한 glyph를 만드는 과정이 US-ASCII만을 쓰는 경우의 rendering
system이나 *한글* MS-Windows가 현재 쓰는 방식인 1:1 대응이 아닐 수도
있고 모든 가능한 조합에 대한 glyph를 미리 가지고 있는 대신 유한한 수의
glyph로부터 동적으로 조합한다는 의미로 쓰셨다면 그런 의미의 '조합형'은
아랍/히브리/타이/인도의 여러 스크립트를 컴퓨터에서 구현할 때 씁니다.
(과거의 MS-DOS용 한글 라이브러리 상당수도 이런 방식을 썼고, Unix/X11을
위한 대표적인 한글 터미널 에뮬레이터인 한텀에서도 씁니다). 하지만, 이런
'rendering' 방식과 어떤 글자의 이진 표현 방식과는 직접적 관련이
없습니다. 이른바 '완성형'을 쓰면서도 이런 rendering 방식을 쓸 수도 있고,
이른바 '상용 조합형'을 쓰면서도 이런 rendering 방식을 쓸 수도 있습니다.
또 그 반대의 경우도 가능합니다.
신정식
Young Gul Park
Sungwon Cho <as...@nuri.net> wrote in message
news:7o71oh$poj$1...@news.nuri.net...
...
> 특히 Tahoma 서체가 가장 다양한 영역을 지원하는 편입니다. 히브리어나
> 아랍어도 지원합니다. Office2K에 들어있는 서체로 상당히 다양한 언어를
> 지원하는 것이 있는데, 지금 생각나지 않는군요...
Arial Unicode MS. 24 메가 바이트로 아주 거대한 글꼴입니다. :)
--
iya!
<URL:http://www.sit.wisc.edu/~ygpark>
Celebrate the 150th anniversary of the University of Wisconsin-Madison
<URL:http://www.uw150.wisc.edu/>
Kang, Kyung-soo
>
> In <37A3D16D...@chollian.net>, Kang, Kyung-soo wrote:
> : Jungshik Shin 작성:
> :>
> :> ...또, 한글만이 제기하는 어려움도 있습니다.
> :> '가나다'는 세 글자로 다뤄야 합니까? 여섯 글자(자모를 따로 세어서)로
> :> 다뤄야 합니까? 보통 답은 전자겠지요. 하지만, 누군가 어떤
> :> 이가 여섯자라고 누군가 외국인의 말을 빌어서 얘기하자면 '한글은 무척
> :> 과학적이라고 생각할 수도 있지만, 바로 그 점 때문에 우리를 무척이나 골치
> :> 아프게 하는 표기 방법'입니다.
>
> : 이 음절/음운 방식의 갈등은 우선 글꼴 개발을 어렵게 만들기에, 컴퓨터가
> : 나오기 이전부터 많은 국어학자들이 '풀어쓰기'의 가능성을 모색한 바 있습니
> : 다. 일찍이 한힌샘 주시경도 그 가능성을 생각했으며, 외솔 최현배는 옥중에서
> : '한글 풀어쓰기 알파벳'을 필생의 과업으로 고안해 냈습니다.
>
> 외솔에 대한 얘기는 저도 가끔 했지요 :-) 하지만, 풀어 쓰기를 하면
> 한글이 가지는 장점 하나를 포기해야 합니다(그것이 컴퓨터에서 구현을 골치
> 아프게 하는 것이기도 하지만요). 그 장점은 보는 각도에 따른 가독성의
> 편차가 작다는 것입니다. 로마자로 쓰인 책을 거꾸로 들고 읽는 것과
> 한글로 쓰인 책을 거꾸로 읽는 것은 가독성에서 큰 차이가 있지요(그것이
> 얼마나 중요한지는 ........) 어쨌든, 풀어 쓰기를 했으면 여러 가지로
> 편했을 수도 있다는 생각은 저도 자주 합니다... 아, 한글, 한글, 한글
'음절'로 모아쓰기를 하는 장점은 단순한 가독성 이상으로서, 우리말의 이른
바 '음절 감각'을 이루는 본질적인 요소입니다. 이를테면 풀어쓰기를 꽤 힘있
게 주장했던 김정수 박사조차도, 일반인의 글자살이를 풀어쓰기로 해체하자고
는 이야기하지 않았습니다. 이 문제는, 국어학자들 사이에서는 거의 상식처럼
인정되는데, 적어도 일반인의 글자살이를 풀어쓰기로 바꾸자...는 주장은 사실
상 불가능합니다.
다만, 풀어쓰기 문제를 고려할 필요가 있는 건, '특수한' 목적의 글자살이
에 응용할 수도 있고, 우리의 음운 감각을 돌이켜 볼 필요가 있기 때문이에요.
> :> 이미 한글 MS-Windows가 나올 무렵에는 인터넷(과 Unix) 등 때문에라도
> :> ISO-2022 체제에 들어 맞지 않는 삼보 조합형 등은 거의 쓸 수 없거나
> :> 쓰더라도 상당히 복잡한 문제를 일으킬 상황이었습니다.
>
> : 예를 들어, MS-Windows 자체적으로는 2바이트 조합형을 쓰고(PC들이 WIN/NT
> : 에 물려 있는 것까지 포함하여), 외부와 교신할 때는 KS완성형으로 변환해서
> : 쓰는 방식은 '치명적'인 기술적 난점 때문에 고려할 수 없다...고 말할 수 있
> : 습니까, 없습니까?
>
> 그렇게 할 수*도* 있었지요. 하지만, 그래야 했다고 말하기는 힘들군요.
> 그러느니 차라리 KS X 1001:1997 해설 3의 방법이 낫다고 생각합니다.
> 님이 말씀하신 경우가 일본의 경우이지요. MS-DOS/MS-Windows/MacOS는
> Shift-JIS (ISO-2022 위반)을 쓰고 Unix는 EUC-JP를 쓰며 인터넷에서는
> ISO-2022-JP를 주로 씁니다.
이 문제는 길게 이야기할 성질이 아니지만, 어쨌든 처음부터 '현실적'인 접근
을 해보겠습니다.
이를테면 1994-5년의 시점에서(한글 WIN95를 개발할 시점에서), 한국 MS가 과
연 2바이트 조합형을 고려할 필요가 있었을까? 저는 그럴 필요가 없었다고 봅니
다. 제가 염두에 뒀던 건, 1980년대 말-1990년대 초의 PC 상황이었습니다.
(UNIX나 통신상에서는 ISO-2022를 위반하는 2바이트 조합형을 쓰기 곤란하겠
지만, PC에서는 가능할 것입니다.)
그리고 신정식 님이 이야기하는 "KS X 1001:1997 해설 3의 방법"이라는 것이
완성형에 없는 음절을 "채움 + 초성 + 중성 + 종성"식의 8바이트로 나타내는 걸
가리킵니까? 그리고 그걸 윈도95 내부적으로 채택할 필요가 있었다...는 것이
신정식 님의 의견입니까?
만약 그렇다면, 또 제가 만약 MS사 간부라면, 그 의견에 동의하기가 힘듭니다.
왜냐하면 이런 방식은 통신상에서 현대 한글을 어떻게든 표현해 내야 한다...는
목적에는 합당할지 모르겠지만, 윈도 내부적으로는 코드 체계가 매우 비효율적이
기 때문입니다. 무엇보다도 음절들이 2바이트/8바이트로 들쭉날쭉하기에, 음소들
을 추출해 내기조차 불편해지지 않습니까?
이보다는 차라리 윈도 내부에서는 확장 완성형이 더 효율적입니다(물론, 이 확
장완성형이란 건 가나다 순도 없고, ISO-2022 규약을 어기게 마련이지만). 어쨌든
확장완성형은 음절들이 모두 2바이트를 따르기 때문에, 글자 변환표를 달고 다니
면 기술적으로는 문제가 해결됩니다.
> '조합형'이란 단어를 어떤 뜻으로 쓰고 계신지 잘 모르겠군요.
> 아랍/히브리/타이어를 위한 글자셋 가운데 널리 쓰이는 것은 이른바
> 삼보/상용 조합형과는 달리 ISO-2022를 전혀 위반하지 않습니다.
> (ISO-2022의 Gx 1byte 공간은 94자로 이들 표기 체제의 낱자를 모두 담는데
> 별 부족함이 없습니다. 만일 2byte 공간을 쓴다면 94x94로 더욱 넓고요.)
> '조합형'을 어떤 표기 체제의 이전 표현에서 화면이나 종이에 그 표기 체제를
> 표시하기 위한 glyph를 만드는 과정이 US-ASCII만을 쓰는 경우의 rendering
> system이나 *한글* MS-Windows가 현재 쓰는 방식인 1:1 대응이 아닐 수도
> 있고 모든 가능한 조합에 대한 glyph를 미리 가지고 있는 대신 유한한 수의
> glyph로부터 동적으로 조합한다는 의미로 쓰셨다면 그런 의미의 '조합형'은
> 아랍/히브리/타이/인도의 여러 스크립트를 컴퓨터에서 구현할 때 씁니다.
> (과거의 MS-DOS용 한글 라이브러리 상당수도 이런 방식을 썼고, Unix/X11을
> 위한 대표적인 한글 터미널 에뮬레이터인 한텀에서도 씁니다). 하지만, 이런
> 'rendering' 방식과 어떤 글자의 이진 표현 방식과는 직접적 관련이
> 없습니다. 이른바 '완성형'을 쓰면서도 이런 rendering 방식을 쓸 수도 있고,
> 이른바 '상용 조합형'을 쓰면서도 이런 rendering 방식을 쓸 수도 있습니다.
> 또 그 반대의 경우도 가능합니다.
'조합형'을 '코드'와 관련해서만 쓰는 게 제 용어법이고, 글자를 실제로 어
떻게 표현해 내느냐... 하는 기술적인 문제는 이 주제에서는 고려할 필요가 없
다고 봅니다. 코드 체계는 완성형이지만 글자 표현 방법은 '조립식'(조합형이
라는 용어와의 혼동을 피하기 위해)으로 쓰거나, 그 반대의 경우는 어느 것이
나 기술적으로 가능하지 않습니까?
'조합형' 코드란, 코드값이 '음절'이 아니라 '음운'에, 더 나아가서는 '바이
트 단위로' 주어지는 걸 가리킵니다. (따라서 저 개인적으로는, ISO-2022를 벗
어나는 2바이트 조합형을 그다지 옹호할 생각이 없습니다.)
여기에서, ISO-2022를 따르는 '3바이트 조합형'이 왜 심각하게 고려되지 않
았는지, 또 지금도 고려되지 않는지... 무척 의문입니다. 이게 국제적으로는
보기 드물거나 볼 수 없을지도 모르는데, 왜냐하면 초성-중성-종성의 세 갈래
로 음운을 나누는 글자는, (살아 있는 글자 체계 가운데는) 아마 한글 이외에
는 없을 것이기 때문입니다. (죽은 글자로는, 원나라의 파스파 문자가 3벌식
음운 체계를 가졌습니다.)
ISO-2022를 따르면, 한 바이트당 94 코드점을 쓸 수 있습니다. 이 가운데
2비트(32코드점)는 초성/중성/종성/특수목적을 가리키는 데 배정하면, 나머
지 62 코드점을 쓸 수 있기 때문에, 중요한 옛 음운이나 한자/특수기호까지
포함시키는 게 일도 아닐 것입니다.
(실제로 첫가끝 자모에 들어가 있는 상당수의 초성-중성 음운들은 중국 한
자음을 음역할 때나 쓰는 '특수한' 자모로서, 일반적인 옛 자모로 인정하기가
힘듭니다.)
이런 3바이트 조합형이 기술적으로 어떤 장애를 가져다 주는가...는 알 바
아니겠으나, 적어도 기술적인 관점에서 '쓸 수 없을' 만큼 나쁘지는 않겠지
... 하는 게 제 소박한 의견입니다.
그 밖에도, Escape-Sequence 같은 걸 이용하는 특별한 방법은 제가 알지
못하므로, 그냥 건너뛰겠습니다.
어쨌든 제 이야기의 초점은, '조합형' 코드라면 모름지기 (음절이 아니라)
음운에, 그것도 '바이트 단위로' 코드값이 매겨져야 한다...는 것입니다.
만약 음절에 코드값을 매기려면, 조합 가능한 음절을 모두 모아서 '조합의
규칙'을 만들어야 하겠지요. 이런 점에서, 유니코드 2.*에 들어가 있는 1만
1,172 음절은 (불완전한 음절을 제외한다면) 사실상 2바이트 조합형으로 봐도
되겠습니다.
Kang, Kyung-soo
>
> 여기에서, ISO-2022를 따르는 '3바이트 조합형'이 왜 심각하게 고려되지 않
> 았는지, 또 지금도 고려되지 않는지... 무척 의문입니다. 이게 국제적으로는
> 보기 드물거나 볼 수 없을지도 모르는데, 왜냐하면 초성-중성-종성의 세 갈래
> 로 음운을 나누는 글자는, (살아 있는 글자 체계 가운데는) 아마 한글 이외에
> 는 없을 것이기 때문입니다. (죽은 글자로는, 원나라의 파스파 문자가 3벌식
> 음운 체계를 가졌습니다.)
> ISO-2022를 따르면, 한 바이트당 94 코드점을 쓸 수 있습니다. 이 가운데
> 2비트(32코드점)는 초성/중성/종성/특수목적을 가리키는 데 배정하면, 나머
> 지 62 코드점을 쓸 수 있기 때문에, 중요한 옛 음운이나 한자/특수기호까지
> 포함시키는 게 일도 아닐 것입니다.
> (실제로 첫가끝 자모에 들어가 있는 상당수의 초성-중성 음운들은 중국 한
> 자음을 음역할 때나 쓰는 '특수한' 자모로서, 일반적인 옛 자모로 인정하기가
> 힘듭니다.)
> 이런 3바이트 조합형이 기술적으로 어떤 장애를 가져다 주는가...는 알 바
> 아니겠으나, 적어도 기술적인 관점에서 '쓸 수 없을' 만큼 나쁘지는 않겠지
> ... 하는 게 제 소박한 의견입니다.
으잉? 2비트면 64코드점이 빠져나가, 94 - 64 = 30 코드점밖에 안 되는군요.
그러면 3바이트당 2만 7천 코드점인데, 현대 한글 1만 1,172 자와 KS한자/특수
기호 6천 개쯤을 빼면 1만 코드점이 그래도 남는군요. 코드점 자체는 여유가
있는 편이겠지요.
여기서 2비트를 빼놓은 건, 초성-중성-종성-특수목적 여부를 한눈에 알아볼
수 있지 않을까... 여겨서인데요. 다른 방법으로도, 이를테면 초성-중성-종성
의 코드점 위치를 달리하여 표시할 수 있겠지요. (이쪽이 더 나은가요?)
요컨대, 3바이트 조합형을 고려해 보면 어떨까...는 제안을 하고 싶습니다.
Kang, Kyung-soo
>
> 여기에서, ISO-2022를 따르는 '3바이트 조합형'이 왜 심각하게 고려되지 않
> 았는지, 또 지금도 고려되지 않는지... 무척 의문입니다. 이게 국제적으로는
> 보기 드물거나 볼 수 없을지도 모르는데, 왜냐하면 초성-중성-종성의 세 갈래
> 로 음운을 나누는 글자는, (살아 있는 글자 체계 가운데는) 아마 한글 이외에
> 는 없을 것이기 때문입니다. (죽은 글자로는, 원나라의 파스파 문자가 3벌식
> 음운 체계를 가졌습니다.)
> ISO-2022를 따르면, 한 바이트당 94 코드점을 쓸 수 있습니다. 이 가운데
> 2비트(32코드점)는 초성/중성/종성/특수목적을 가리키는 데 배정하면, 나머
> 지 62 코드점을 쓸 수 있기 때문에, 중요한 옛 음운이나 한자/특수기호까지
> 포함시키는 게 일도 아닐 것입니다.
> (실제로 첫가끝 자모에 들어가 있는 상당수의 초성-중성 음운들은 중국 한
> 자음을 음역할 때나 쓰는 '특수한' 자모로서, 일반적인 옛 자모로 인정하기가
> 힘듭니다.)
> 이런 3바이트 조합형이 기술적으로 어떤 장애를 가져다 주는가...는 알 바
> 아니겠으나, 적어도 기술적인 관점에서 '쓸 수 없을' 만큼 나쁘지는 않겠지
> ... 하는 게 제 소박한 의견입니다.
아하, 초성-중성-종성 각각에 2비트를 할당할 여유가 없지요? (코드값에서 나
타내 주고 싶은 욕심만 내세우니까, 이상하게 삼천포로 빠졌습니다.)
그렇다면 코드점은 그냥 94개씩 쓰기로 하고, 한글을 시작하고 끝낼 때는 제
어기호를 꼭 쓰도록 하는 게 효율적입니까? 아니면 그게 생략될 경우에는, 한글
이 시작되는 곳까지 MSB를 검색하여 초성-중성-종성을 알아내는 식이 됩니까?
생각보다는 복잡해지겠습니다.
그 기술적인 내용이야 어떻든, 요컨대 3바이트 조합형을 고려해 보면 어떨까
... 하는 게 제 소박한 제안입니다.
gahi_man
Kang, Kyung-soo 이(가) <37A84538...@chollian.net> 메시지에서
작성하였습니다...
>Jungshik Shin wrote:
>
> 이 문제는 길게 이야기할 성질이 아니지만, 어쨌든 처음부터 '현실적'인
접근
>을 해보겠습니다.
> 이를테면 1994-5년의 시점에서(한글 WIN95를 개발할 시점에서), 한국 MS가
과
>연 2바이트 조합형을 고려할 필요가 있었을까? 저는 그럴 필요가 없었다고
봅니
>다. 제가 염두에 뒀던 건, 1980년대 말-1990년대 초의 PC 상황이었습니다.
> (UNIX나 통신상에서는 ISO-2022를 위반하는 2바이트 조합형을 쓰기
곤란하겠
>지만, PC에서는 가능할 것입니다.)
실제로 완성형 코드 문제가 얘기된 것은 ksc5601를 처음에 만들 때였고,
이전에는 컴퓨터 한글관련된 것은 AppleII와 CPM용 시장과 시스템에 연결되어
사용하는 터미날 시장으로 양분되어 있었지요. (그리고 Line Printer용
한글처리도 한 몫이었지만)
좌우간 양쪽 선호한 것은 테이타 크기와 화면에서 차지하는 자리가 같은
같은 2바이트용 한글이었습니다. 가장 큰이유는 각종 스프트웨어가 영문
형태로 80컬럼/줄로 제공되고 있었기 때문이지요.
이 때 복제품 시장에서는 도깨비 한글이라는 것이 제일 흔히 사용되었고,
Host에 연결된 2바이트 조합형 한글이 표준이었죠.
이후 아시는 바와 같이 통신상의 제약(MSB가 set된 control-char)등을 문제로
정부가 강력하게 완성형 제계를 갖고 나왔고(주관: 표준연구소) 반발하는
한글학계와 기존 사업자를 무마용으로 N바이트 조합형, 2바이트 조합형을
함께 혀용하되, 통신용으로는 국제 규약에 맞는 완성형을 써라고 못박았죠.
업체에서는 고생스럽게 한글입력->조합형->완성형을 가지고 갈 이유가 없기
때문에 완성형이 표준으로 굳어졌고, 거의 모든 자료가 완성형으로 만들어
졌지요.
강경수님의 의견과 같이 win95에서 조합형을 쓴다는 것은 '한글학자'가
아닌담에야 그런 모험을 할 이유가 없었지요.
> 그리고 신정식 님이 이야기하는 "KS X 1001:1997 해설 3의 방법"이라는
것이
>완성형에 없는 음절을 "채움 + 초성 + 중성 + 종성"식의 8바이트로 나타내는
걸
>가리킵니까? 그리고 그걸 윈도95 내부적으로 채택할 필요가 있었다...는
것이
>신정식 님의 의견입니까?
> 만약 그렇다면, 또 제가 만약 MS사 간부라면, 그 의견에 동의하기가
힘듭니다.
>왜냐하면 이런 방식은 통신상에서 현대 한글을 어떻게든 표현해 내야
한다...는
>목적에는 합당할지 모르겠지만, 윈도 내부적으로는 코드 체계가 매우
비효율적이
>기 때문입니다. 무엇보다도 음절들이 2바이트/8바이트로 들쭉날쭉하기에,
음소들
>을 추출해 내기조차 불편해지지 않습니까?
> 이보다는 차라리 윈도 내부에서는 확장 완성형이 더 효율적입니다(물론,
이 확
>장완성형이란 건 가나다 순도 없고, ISO-2022 규약을 어기게 마련이지만).
어쨌든
>확장완성형은 음절들이 모두 2바이트를 따르기 때문에, 글자 변환표를 달고
다니
>면 기술적으로는 문제가 해결됩니다.
'가나다 순이 없다'면 소트 문제는 어떻게 해결하지요.
저도 내부적으로는 2바이트조합형에 빈자리에 한자등을 채워서 사용하는 것이
개입적으로는 바람직 하다고 생각하는데 소트에 대한 해결책이 필요하죠.
> '조합형'을 '코드'와 관련해서만 쓰는 게 제 용어법이고, 글자를 실제로
어
>떻게 표현해 내느냐... 하는 기술적인 문제는 이 주제에서는 고려할 필요가
없
>다고 봅니다. 코드 체계는 완성형이지만 글자 표현 방법은
'조립식'(조합형이
>라는 용어와의 혼동을 피하기 위해)으로 쓰거나, 그 반대의 경우는 어느
것이
>나 기술적으로 가능하지 않습니까?
> '조합형' 코드란, 코드값이 '음절'이 아니라 '음운'에, 더 나아가서는
'바이
>트 단위로' 주어지는 걸 가리킵니다. (따라서 저 개인적으로는, ISO-2022를
벗
>어나는 2바이트 조합형을 그다지 옹호할 생각이 없습니다.)
다른 얘기일지도 모르는데.. 현재 8Bit 아스키에서 각각 32개씩 Control
Code로 사용하고 있는 64개 문자중 많은 것이 사용되고 있지 않은데, 이것은
정비하지 않나요? ISO에서 32이 내로 줄여서 7Bit ASCII안에 들어가게 한다면
얼마나 좋을까요. 너무 바라는 거겠지요.
> 여기에서, ISO-2022를 따르는 '3바이트 조합형'이 왜 심각하게 고려되지
않
>았는지, 또 지금도 고려되지 않는지... 무척 의문입니다. 이게 국제적으로는
>보기 드물거나 볼 수 없을지도 모르는데, 왜냐하면 초성-중성-종성의 세
갈래
>로 음운을 나누는 글자는, (살아 있는 글자 체계 가운데는) 아마 한글
이외에
>는 없을 것이기 때문입니다. (죽은 글자로는, 원나라의 파스파 문자가 3벌식
>음운 체계를 가졌습니다.)
> ISO-2022를 따르면, 한 바이트당 94 코드점을 쓸 수 있습니다. 이 가운데
>2비트(32코드점)는 초성/중성/종성/특수목적을 가리키는 데 배정하면, 나머
>지 62 코드점을 쓸 수 있기 때문에, 중요한 옛 음운이나 한자/특수기호까지
>포함시키는 게 일도 아닐 것입니다.
> (실제로 첫가끝 자모에 들어가 있는 상당수의 초성-중성 음운들은 중국 한
>자음을 음역할 때나 쓰는 '특수한' 자모로서, 일반적인 옛 자모로
인정하기가
>힘듭니다.)
> 이런 3바이트 조합형이 기술적으로 어떤 장애를 가져다 주는가...는 알 바
>아니겠으나, 적어도 기술적인 관점에서 '쓸 수 없을' 만큼 나쁘지는 않겠지
>... 하는 게 제 소박한 의견입니다.
> 그 밖에도, Escape-Sequence 같은 걸 이용하는 특별한 방법은 제가 알지
>못하므로, 그냥 건너뛰겠습니다.
한영 구분은 SI/SO을 사용하나요? 그렇다면 항상 3바이트이라면
한글,특수문자 구분만 있어도 되겠네요.
현재에는 디스크와 메모리 가격이 엄청나게 싸져서(^^;)그렇지 전에는 말도
안되는 소리였지요. 2바이트에비해 50%의 데이타 량이 늘어나니깐요.
7비트인지 8비트였는지 확실치 않지만 ksc5601 첫 버전에서는 3바이트 한글을
지원 했던 것으로 기억됩니다.
> 어쨌든 제 이야기의 초점은, '조합형' 코드라면 모름지기 (음절이 아니라)
>음운에, 그것도 '바이트 단위로' 코드값이 매겨져야 한다...는 것입니다.
> 만약 음절에 코드값을 매기려면, 조합 가능한 음절을 모두 모아서 '조합의
>규칙'을 만들어야 하겠지요. 이런 점에서, 유니코드 2.*에 들어가 있는 1만
>1,172 음절은 (불완전한 음절을 제외한다면) 사실상 2바이트 조합형으로
봐도
>되겠습니다.
조합형/조립형 구분을 잘 모르겠군요. 이렇게 구분한다면 '완성형'이란
표현은 없어지나요?
gahi_man
작성하였습니다...
>"Font Linking"이라는 기술이 있습니다. 해당하는 언어의 폰트로 표시하는
>것이라고 이해하시면 됩니다. Internet Explorer, MS Office, Win2K 등에서
>사용하고 있습니다.
>
>Internet Explorer가 UTF-8로 인코딩한 페이지를 표시할 때 한글이면 한글,
>영문 알파벳이면 알파벳 식으로 알아서 해당하는 언어의 폰트로
처리해줍니다.
>Netscape인 경우 Unicode를 직접 지원해주는 NT가 아니면 이를 제대로 표시
>해주지 못합니다. (사용자가 직접 폰트 설정을 바꾸어 주어야 합니다.)
>
>MS Typography <http://www.microsoft.com/typography/default.asp>에서
>Font properties extension를 다운로드하여 설치하시면 Windows에 들어있는
>각 TrueType 폰트가 Unicode (ISO 10646-2) 중 어떤 영역을 지원하는지 알
>수 있습니다. 아니면... NT인 경우 Unicode 문자표가 기본으로 들어
있으므로
>그것을 통해 직접 확인할 수도 있습니다. (이 thread에서 언급하는
글자들도
>물론 찾아볼 수 있습니다.)
>
>아랍어도 지원합니다. Office2K에 들어있는 서체로 상당히 다양한 언어를
>지원하는 것이 있는데, 지금 생각나지 않는군요...
>
>해당 폰트에서 지원하지 않는 영역은 기술적으로 처리할 수 있습니다.
코드테이블 별로 정해져 있는 국가코드에 맞는 폰트를 사용한다는
말씀이군요. 그럼 해결이 되겠네요. 국가코드별로 폰트가 지정된 테이블만
있으면 되겠군요.
또 다른 얘기입니다. 윈2000에서는 다양한 국가의 문자를 입력을 용이하게 할
수 있는 방안도 마련되어 있겠군요. NT에서 이미 지원하고 있다니...
한글입력기가 가끔 이상한 현상을 일으키는 것도 해결될른지...
Kang, Kyung-soo
> > (UNIX나 통신상에서는 ISO-2022를 위반하는 2바이트 조합형을 쓰기
> > 곤란하겠지만, PC에서는 가능할 것입니다.)
>
한글 코드는 되도록 '한글학자'의 의견을 받아들여야만 뒤탈이 없습니
다. KS완성형처럼 터무니없는 방식을 채택했기 때문에, 확장 완성형이니
8바이트 음절이니... 하는 편법이 나오는 게 아닙니까?
표준은 약간 장기적인 시야를 가지는 게 좋을 것입니다(지금 당장은
다소 버거운 느낌이 들지라도).
> > 이보다는 차라리 윈도 내부에서는 확장 완성형이 더 효율적입니다
> > (물론, 이 확장 완성형이란 건 가나다 순도 없고, ISO-2022 규약을
> > 어기게 마련이지만). 어쨌든 확장 완성형은 음절들이 모두 2바이트를
> > 따르기 때문에, 글자 변환표를 달고 다니면 기술적으로는 문제가 해
> > 결됩니다.
>
> '가나다 순이 없다'면 소트 문제는 어떻게 해결하지요.
> 저도 내부적으로는 2바이트조합형에 빈자리에 한자등을 채워서 사용하는
> 것이 개인적으로는 바람직 하다고 생각하는데 소트에 대한 해결책이 필
> 요하죠.
확장 완성형을 쓰는 한글 WIN95/98 등은 '글자 변환표'를 줄곧 달고 다
니겠지요.
지금 시점에서는, (역사란 돌이킬 수 없으므로), 2바이트 조합형은 사실
상 잊어버려야 할 것입니다.
> 다른 얘기일지도 모르는데.. 현재 8Bit 아스키에서 각각 32개씩 Control
> Code로 사용하고 있는 64개 문자중 많은 것이 사용되고 있지 않은데, 이
> 것은 정비하지 않나요? ISO에서 32이 내로 줄여서 7Bit ASCII안에 들어가
> 게 한다면 얼마나 좋을까요. 너무 바라는 거겠지요.
그런 게 이른바 Windows Code Page 아닙니까? ISO-8859-1에서 32개의 제어
코드 영역에까지 글자를 배정하여 Windows-1252가 되는 것이지요.
> > 이런 3바이트 조합형이 기술적으로 어떤 장애를 가져다 주는가...는 알
> >바 아니겠으나, 적어도 기술적인 관점에서 '쓸 수 없을' 만큼 나쁘지는
> >않겠지... 하는 게 제 소박한 의견입니다.
>
> 한영 구분은 SI/SO을 사용하나요? 그렇다면 항상 3바이트이라면
> 한글,특수문자 구분만 있어도 되겠네요.
> 현재에는 디스크와 메모리 가격이 엄청나게 싸져서(^^;)그렇지 전에는 말도
> 안되는 소리였지요. 2바이트에 비해 50%의 데이타 량이 늘어나니깐요.
> 7비트인지 8비트였는지 확실치 않지만 ksc5601 첫 버전에서는 3바이트 한글
> 을 지원했던 것으로 기억됩니다.
"데이타 량이 늘어나는" 것은 반대 이유가 되지 못합니다. 왜냐하면 그건
늘 '상대적인' 개념이기 때문에요. (이런 편의주의적인 발상이 한글 코드 문
제를 이처럼 얽히게 만들지 않았나요?)
이를테면 제 이름 '강경수'를 영어로 쓰면 'Kang, Kyung-soo'가 되는데,
당연히 영어처럼 음운 단위로 처리해야지 음절에다가 '코드값'을 주자...는
발상 자체가 터무니없는 것입니다.
다만, 조합 가능한 음절을 모두 모아서 '조합의 규칙'을 만들면, 무척 효
율적인 완성형 코드 체계가 됩니다. 이를테면 유니코드의 1만 1,172 음절은
충분히 쓸 만하다고도 남으며, 사실상 2바이트 조합형으로 봐도 됩니다.
KSC 5601-1974는 한글 자모를 그냥 모아놓은 것으로서, 제가 이야기하는
3바이트 조합형과는 다를 것입니다.
gahi_man
작성하였습니다...
> KSC 5601-1974는 한글 자모를 그냥 모아놓은 것으로서, 제가 이야기하는
>3바이트 조합형과는 다를 것입니다.
74년도 것은 조합형 뿐이었고, 80년대 초반에 버전(?)은 초중종성에
한바이트씩 배정한 코드가 있었던 것으로 기억됩니다. 하위 5bit에 코드
배정을 했죠.
KIST(KAIST 전신) 부속 전산센다에서 되니/안되니하며 떠들던 생각이 납니다.
Jungshik Shin
: Kang, Kyung-soo 이(가) <37A8FB6B...@chollian.net> 메시지에서
: 작성하였습니다...
:> KSC 5601-1974는 한글 자모를 그냥 모아놓은 것으로서, 제가 이야기하는
:>3바이트 조합형과는 다를 것입니다.
: 74년도 것은 조합형 뿐이었고, 80년대 초반에 버전(?)은 초중종성에
: 한바이트씩 배정한 코드가 있었던 것으로 기억됩니다. 하위 5bit에 코드
: 배정을 했죠.
예, 그것이 80년대에 Unix에서 쓴 방법입니다. SI와 SO를(영어든 한글이든
모두 MSB가 0이므로 구별하기 위해) 써서 한글과 영어를 전환한 것도
맞습니다. n-byte 한글이라고 불렀지요. 그것을 쓴 한글 '워드 프로세서'를
SSM-16(M68000을 cpu로 쓴)에서 돌아가는 V7 Unix에서 쓴 적이 있습니다.
: KIST(KAIST 전신) 부속 전산센다에서 되니/안되니하며 떠들던 생각이 납니다.
KIST는 KAIST의 전신이 아니고 70년대 초에 생긴 학교인 KAIS(KAIST
전신)보다 *먼저* 60년대 말에 생긴(미 존슨 행정부의 원조??로) 이공계
전문 연구소입니다. 현재 연구소인 KIST와 대학인 KAIST는 완전히 독립적인
아무런 상관도 없는 기관입니다. KIST 부속 전산 센터(?)는 KIST 부설
시스템 공학 연구소(SERI)가 되었다가 현재는 정보 통신부로 소속을 옮겨서
ETRI(전자 통신 연구소) 부설이 되었습니다.
신정식
Kang, Kyung-soo
>
> Sungwon Cho 작성:
> >
> > Unicode/UTF-8 등을 개발한 이유는 진정한 다국어 처리를 위한 것입니다.
> > 물론 어느 정도 충실한 한글 처리를 위한 좋은 기반도 제공합니다. 현재
> > 가능한 방법으로 가장 합리적입니다.
> >
> > 앞으로 EUC-KR 대신 UTF-8을 charset로 붙이고 포스팅할 그날이 오기를...
>
> 것인가? 지금의 현안은 아니지만, 제 예상으로는, 내다볼 수 있는 기간 안에는
> 그런 날이 오기 힘들 걸로 봅니다.
>
> 첫째, EUC-KR, 한국어로 된 UTF-8 두 가지를 모두 '한국어(자동)'로 자동 인
> 식해 내고,
> 둘째, 머리글을 각 charset에 따라 자동적으로, 또 따로따로 보여줄 수 있으
> 며,
> 셋째, 위의 두 가지 기능이 주요 플랫폼에서, 주요 나라에서, 주요 프로그램
> 에서 모두 가능하다, 다시 말하면 매우 일반화되었다
> 는 세 가지 전제하에서라면, 한글 유즈넷에서 UTF-8을 쓸 날이 좀더 빨리 올 것
> 입니다.
>
> 이와 달리 한글 웹 페이지에서는, 지금 당장이라도 UTF-8을 쓸 수 있습니다.
> 다만, (한자를 쓸 경우에는) CJK 한자가 어느 나라 한자인지를 꼭 표시해 주는
> 게 권장됩니다. (이런 목적으로 쓰이는 MIME 머리글이 뭔지는 모르겠지만, 이를
> 테면 "Content-Language=ko")
> 왜냐하면 한자는 중국/대만/일본/한국에서 각각 글자꼴도 다르고, 쓰이는 맥락
> 도 다르기 때문이며, 경우에 따라서는 유니코드의 예비 영역에 자기 나라에서만
> 정해 놓은 한자를 더러 쓸 수 있기 때문입니다.
유니코드에 대해 일반적으로 중요하게 고려해야 할 측면은, 'ASCII 호환' 방식
을 벗어난다...는 점입니다. 다시 말하면, ISO-2022 규약과 전혀 다른 체계로서,
서로 호환이 안 된다...는 이야깁니다.
이게 어떤 제약을 이룰지...를 두 가지 중요한 글자 체계, 곧 서유럽어와 CJK
한자로써 간단히 예를 들겠어요.
(1) 서유럽어를 위해 쓰는 글자 세트는 ISO-8859-1(또는 Windows-1252)인데,
프랑스어/독일어/스페인어/포르투갈어/이탈리아어 등 사실상 컴퓨터/인터넷을 지
배하는 글자 세트입니다. 이 ISO-8859-1(또는 Windows-1252)은 1바이트로써 모
든 게 끝나 버리는 간단명료한 체계로서, 이를테면 러시아어/그리스어 같은 특수
알파벳이 필요할 경우에는 응용 프로그램 수준에서 얼마든지 확장 코드표로 지원
해 주기 때문에, 대부분의 서양인들은 이 체계를 굳이 벗어날 필요성을 느끼지
못합니다.
이 ISO-8859-1(또는 Windows-1252)과 유니코드는 서로 호환이 안 된다...는 게
중요한 걸림돌이 됩니다. 게다가 똑같이 유니코드를 쓰더라도, 그냥 2바이트 단
위로 인코딩하는 UCS-2와, 1바이트 단위로 복잡하게 인코딩하는 UTF-8은 서로 다
른 인코딩입니다. 따라서 일반 서양인들로서는, 1바이트로써 모든 게 간단명료하
게 끝나 버리는 현재의 체계를 벗어나 UCS-2/UTF-8을 왜 쓸 필요가 있는지...가
의문일 것입니다.
이 의문에 대해서는, MS가 앞으로 어떤 시장 전략을 쓸지...가 매우 중요한 관
건이 되겠지요. 다시 말하면 ISO-8859-1(또는 Windows-1252)과 UCS-2/UTF-8 사이
의 호환성 문제가 일반 사용자한테 전혀 걸리적거리지 않게끔 할 자신이 있다면
유니코드로 건너갈 것이고, 그럴 자신이 없다면 현재의 1바이트 체계를 그대로
유지할 것입니다.
(2) 유니코드에는 2만여 자의 CJK 한자가 들어가 있어요. 이 CJK 한자는, 나라
마다 글자 모양이 다르고 쓰이는 맥락이 다르더라도 의미상으로 똑같은 글자로
볼 수 있으면, 그걸 한 글자로 취급합니다. 그러다 보니까, 중국/대만/일본에서
과연 현재의 자국 글자 세트를 벗어나 이 CJK 한자로 건너갈 필요가 있을까...
는 저로서는 상당한 의문입니다.
서유럽어와 CJK 한자의 경우와는 정반대로, 한글 코드의 관점에서는 유니코드
가 엄청 좋기 때문에, 한국인들로서는 당연히 유니코드로 건너갈 필요가 있습니
다. 여기에서 혼동하지 말아야 할 점이 바로 위의 두 가지 예증인데, 곧 서유럽
어/CJK 한자의 관점에서는 유니코드가 꼭 좋은 상황을 만들지 않는다...는 걸
잊어서는 곤란하겠지요.
(기존 데이터를 변형시키는 데는 으레 천문학적인 비용이 들게 마련이지만,
그건 결정적인 제약으로 보지 않기 때문에 굳이 다루지 않습니다.)
이 때문에, 워드 프로세서/스프레드 시트/데이터베이스 등 일반 응용 프로그
램의 차원과, 인터넷의 차원을 구분할 필요가 있습니다. 다시 말하면, 일반 응
용 프로그램의 차원에서는 유니코드로 건너가기가 비교적 쉽지만, 인터넷의 차
원은 그렇지 않다는 이야깁니다. 인터넷의 차원에서는 ISO-2022 규약이 꽤 생
명력 있게 유지될 것이며, 이에 따라 ISO-2022 규약과 UTF-8은 상당 기간 뒤섞
여 사용된다고 보는 게 합당할 것입니다.
그리고 이 문제를 푸는 열쇠는 MS의 시장 전략이 쥐고 있을 것이기 때문에,
MS가 앞으로 어떤 태도를 취할지... 주의 깊게 살펴볼 필요가 있겠어요.
Kang, Kyung-soo
>
> Sungwon Cho 작성:
> >
> > Unicode/UTF-8 등을 개발한 이유는 진정한 다국어 처리를 위한 것입니다.
> > 물론 어느 정도 충실한 한글 처리를 위한 좋은 기반도 제공합니다. 현재
> > 가능한 방법으로 가장 합리적입니다.
> >
> > 앞으로 EUC-KR 대신 UTF-8을 charset로 붙이고 포스팅할 그날이 오기를...
>
> 다만, (한자를 쓸 경우에는) CJK 한자가 어느 나라 한자인지를 꼭 표시해 주는
> 게 권장됩니다. (이런 목적으로 쓰이는 MIME 머리글이 뭔지는 모르겠지만, 이를
> 테면 "Content-Language=ko")
> 왜냐하면 한자는 중국/대만/일본/한국에서 각각 글자꼴도 다르고, 쓰이는 맥락
> 도 다르기 때문이며, 경우에 따라서는 유니코드의 예비 영역에 자기 나라에서만
> 정해 놓은 한자를 더러 쓸 수 있기 때문입니다.
예를 들어, 중국어/대만어/일본어/한국어를 섞어 쓴 웹 페이지를 UTF-8으로 인
코딩하면, 도대체 어떤 일이 생길 것인가? 과연 이런 경우에도 CJK 한자를 쓸
만한가?
이 물음에 대해 딱히 뭐라고 단정지어 대답할 수는 없겠지만, 다만 MS IE 사용
자들은 큰 무리 없이 읽을 수는 있겠어요. (모든 경우가 다 제대로 처리된다...
고는 확신할 수 없습니다.)
왜냐하면 MS IE는 각 나라의 글꼴로 글자들을 보여줄 수 있기 때문이며, CJK
한자들을 뽑을 때 기본적으로는 각국의 실정을 웬만큼 고려했을 것이기 때문입니
다. 예를 들어, 아주 간자화된 한자라면 다른 코드를 배정했습니다.
실제로 "Content-Language=ko" 같은 머리글이 꼭 필요할지 어떨지...는 확실히
말할 수 없지만, MS IE 이외의 프로그램 사용자들을 위해서는 넣어주는 게 바람
직할 듯싶군요.
CHOI, Junho
KK> 예를 들어, 중국어/대만어/일본어/한국어를 섞어 쓴 웹 페이지를
KK> UTF-8으로 인코딩하면, 도대체 어떤 일이 생길 것인가? 과연 이런
KK> 경우에도 CJK 한자를 쓸 만한가?
KK> 이 물음에 대해 딱히 뭐라고 단정지어 대답할 수는 없겠지만,
KK> 다만 MS IE 사용자들은 큰 무리 없이 읽을 수는 있겠어요. (모든
KK> 경우가 다 제대로 처리된다... 고는 확신할 수 없습니다.)
KK> 왜냐하면 MS IE는 각 나라의 글꼴로 글자들을 보여줄 수 있기
KK> 때문이며, CJK 한자들을 뽑을 때 기본적으로는 각국의 실정을
KK> 웬만큼 고려했을 것이기 때문입니 다. 예를 들어, 아주 간자화된
KK> 한자라면 다른 코드를 배정했습니다.
글쎄요. 유니코드의 단점은 언어의 구분이 없다는 것입니다.
실제로 누가 한중일 한자의 차이를 보여주는 교육 교재 등을 만들려고 할
때,
한(漢) : 한국식 한자
한(漢) : 일본식 한자
한(漢) : 중국식 한자
한(漢) : 대만식 한자
를 쓰려고 하면 이는 유니코드만으로 표현할 수 없습니다. 글자에는 언어
정보가 없고 단지 하나의 코드값만이 존재하니까요.
http://charts.apple.com/unihan/unihan.acgi$0x6F22
여기 보면 간체의 '한'만 없다는 것을 보실 수 있습니다. 이건 말씀대로
따로 배정되어 있죠. 특별히 차이가 나는 간자들은 따로 코드를
배정하였지만 '비슷한' 것들은 하나로 되어 있습니다.
제 생각에는 비슷하다고 같지는 않습니다. 이건 단순히 글꼴 디자이너의
선택인지 아니면 나라마다 차이가 나야 하는 것인가는 좀 불분명하지만,
저는 후자의 경우라고 생각합니다. 또한 아래의 경우도 있죠.
http://charts.apple.com/unihan/unihan.acgi$0x7FD2 (익힐 습)
즉 한국어 한자와 일본어 한자를 구별할 수 없다는 것이죠. 이럴 경우 IE가
아무리 똑똑해도 제대로 보여주지 못합니다. ISO-2022라면 이럴 경우
문자셋을 알고 있으므로 다른 글꼴을 사용해서(즉 국어 한자에는 한국어
글꼴을, 일본어 한자에는 일본어 글꼴을) 보여줄 수 있겠지만 유니코드로
되었다면 어떻게 해야 할지(언어 값에 따라서 우선 순위를 배정할 수
있겠습니다만) 알 수가 없습니다. 문자열 자체도 마찬가지고요.
KK> 실제로 "Content-Language=ko" 같은 머리글이 꼭 필요할지
KK> 어떨지...는 확실히 말할 수 없지만, MS IE 이외의 프로그램
KK> 사용자들을 위해서는 넣어주는 게 바람직할 듯싶군요.
전 딱히 필요 없다고 봅니다. 그게 있다고 해서 도움될 게 있는지...
--
** Any opinions in this posting are my own and not those of my employers **
CHOI, Junho <mailto:c...@kr.freebsd.org>
- Korea FreeBSD Users Group <http://www.kr.freebsd.org/~cjh>
- Web Data Bank Co. Seoul., ROK. <http://www.wdb.co.kr> (+82-2-554-9676)
Kang, Kyung-soo
>
> >>>>> "KK" == Kang, Kyung-soo <kang...@chollian.net> writes:
>
> KK> 예를 들어, 중국어/대만어/일본어/한국어를 섞어 쓴 웹 페이지를
> KK> UTF-8으로 인코딩하면, 도대체 어떤 일이 생길 것인가? 과연 이런
> KK> 경우에도 CJK 한자를 쓸 만한가?
> KK> 이 물음에 대해 딱히 뭐라고 단정지어 대답할 수는 없겠지만,
> KK> 다만 MS IE 사용자들은 큰 무리 없이 읽을 수는 있겠어요. (모든
> KK> 경우가 다 제대로 처리된다... 고는 확신할 수 없습니다.)
> KK> 왜냐하면 MS IE는 각 나라의 글꼴로 글자들을 보여줄 수 있기
> KK> 때문이며, CJK 한자들을 뽑을 때 기본적으로는 각국의 실정을
> KK> 웬만큼 고려했을 것이기 때문입니 다. 예를 들어, 아주 간자화된
> KK> 한자라면 다른 코드를 배정했습니다.
>
> 글쎄요. 유니코드의 단점은 언어의 구분이 없다는 것입니다.
> 실제로 누가 한중일 한자의 차이를 보여주는 교육 교재 등을 만들려고 할
> 때,
>
> 한(漢) : 한국식 한자
> 한(漢) : 일본식 한자
> 한(漢) : 중국식 한자
> 한(漢) : 대만식 한자
>
> 를 쓰려고 하면 이는 유니코드만으로 표현할 수 없습니다. 글자에는 언어
> 정보가 없고 단지 하나의 코드값만이 존재하니까요.
예전에 제가 언급한 적이 있는데요.
요점만 다시 말하면, 언어란 '기술적'인 차원의 문제이기 이전에 '문화적'
인 차원의 문제라는 이야기겠죠. 이를테면 러시아어나 스페인어를 모르는 사
람한테는, 러시아어/스페인어 문장이란 (특정한 의미로 다가온다기보다는) 한
갓 그림에 지나지 않을 것입니다.
따라서 '일상적'인 목적에 비춰 볼 때는, 유니코드를 쓰기가 거북한 측면이
생깁니다. 어떤 문서가 'UTF-8'으로 인코딩됐다...는 정보를 안다고 해서, 우
리가 그 내용을 알아들을 수 있는지 없는지...는 알 수 없는 노릇이니까요.
> http://charts.apple.com/unihan/unihan.acgi$0x6F22
>
> 여기 보면 간체의 '한'만 없다는 것을 보실 수 있습니다. 이건 말씀대로
> 따로 배정되어 있죠. 특별히 차이가 나는 간자들은 따로 코드를
> 배정하였지만 '비슷한' 것들은 하나로 되어 있습니다.
> 제 생각에는 비슷하다고 같지는 않습니다. 이건 단순히 글꼴 디자이너의
> 선택인지 아니면 나라마다 차이가 나야 하는 것인가는 좀 불분명하지만,
> 저는 후자의 경우라고 생각합니다. 또한 아래의 경우도 있죠.
>
> http://charts.apple.com/unihan/unihan.acgi$0x7FD2 (익힐 습)
>
> 즉 한국어 한자와 일본어 한자를 구별할 수 없다는 것이죠. 이럴 경우 IE가
> 아무리 똑똑해도 제대로 보여주지 못합니다. ISO-2022라면 이럴 경우
> 문자셋을 알고 있으므로 다른 글꼴을 사용해서(즉 국어 한자에는 한국어
> 글꼴을, 일본어 한자에는 일본어 글꼴을) 보여줄 수 있겠지만 유니코드로
> 되었다면 어떻게 해야 할지(언어 값에 따라서 우선 순위를 배정할 수
> 있겠습니다만) 알 수가 없습니다. 문자열 자체도 마찬가지고요.
나라마다 글꼴이 어떻게 달라지는지... 하는 등 미묘한 뉘앙스까지 CJK 한
자로써 보여주려면, Multipart 메시지를 구성해야 하고, 한 화면 안에서 그
Multipart 메시지를 따로따로 처리할 수 있는 기술이 실용화되어야 할 것입
니다.
그런데 CJK 한자의 특성으로써는, 글자 모양의 미세한 차이까지 수용할 수
는 없다고 봐야겠지요. (6만 5천 코드점 갖고 해결될 수 있을까요?)
> KK> 실제로 "Content-Language=ko" 같은 머리글이 꼭 필요할지
> KK> 어떨지...는 확실히 말할 수 없지만, MS IE 이외의 프로그램
> KK> 사용자들을 위해서는 넣어주는 게 바람직할 듯싶군요.
>
> 전 딱히 필요 없다고 봅니다. 그게 있다고 해서 도움될 게 있는지...
이건 그렇지 않습니다.
이를테면 우리 한자로만 된 웹 페이지를 UTF-8으로 인코딩했다고 칩시다.
영문 OS 사용자라면, 그 웹 페이지를 어느 나라 글꼴로 봐야 하는지... HTTP
프로토콜에 따라 지시받을 필요가 당연히 생길 것입니다. 이걸 지시해 놓지
않으면, 사용자가 유니코드 인코딩에 지정해 준 글꼴로 표시되지 않겠어요?
Changwoo Ryu
content-language가 아니더라도 적어도 HTML 4.0에는 tag마다
lang=<ISO639 code> attribute를 달 수 있도록 되어 있습니다. 그러니까
일부분은 일본어, 일부분은 한국어 한자로 쓴 페이지를 만드는 것도
이론상은 가능합니다.
웹브라우저가 제대로 보여주느냐는 별개 문제지만요..
--
Changwoo RYU
Jungshik Shin
: MS Typography <http://www.microsoft.com/typography/default.asp>에서
Apple 사의 직원의 말을 흉내내서 쓰자면, 기회 균등의 정신에 비추어서
다음 사이트도 방문할 것을 권합니다. (ATSUI/QuickDraw GX, Apple Advanced
Typography 등에 대한 정보가 있는)
신정식