난 오늘도 X같은 한글코드를 쓰고 있다!!

익명 사용자의 이미지

역겨운 한글 코드체계!!!!!! 바꿉시다!!

우선, 한글 완성형 코드체계를 컴퓨터에
적용한 인간들을 저주하며!! 나쁜 X들...

과연 현재 컴퓨터에서 (Linux, M$
Windows, Unix, 기타..) 사용하는 한글
코드체계가 합리적인가?

이건 내가 컴퓨터를 사용해오면서 갖고있
는 오래된 의문이다. 나의 한글에 대한
짧은 지식으로는 중학교때 국어 시간에 '
훈민정음'을 배우면서 세종대왕님이 만든
한글의 원리에 대한 어렴풋한 기억이다.

한글은 표음문자이며 조합형 문자이다.
ㄱ ㄴ ㄷ ㄹ ㅁ ㅂ ㅇ ㅅ ㅈ ㅊ ㅋ ㅌ ㅍ
ㅃ ㅉ ㄸ ㄲ ㅆ
ㅏ ㅑ ㅓ ㅕ ㅗ ㅛ ㅜ ㅡ ㅣ ㅢ ㅐ ㅔ ㅒ

이 40개 미만의 문자들로 한국말을 모두
표현할 수가 있다. 영어의 알파벳보다 더
과학적이라고 한다.

근데, 컴퓨터에서의 한글은 겉으로 보기
엔 편리하지만 컴퓨터 내부에서의 한글은
과학적인 문자가 아니라 한자와 똑같은
무식하고 형편없는 문자가 아닌 코드값
으로 바뀐다.

예를들면, '가'를 입력하면 컴퓨터에서는
'ㄱ'과 'ㅏ'로 저장되는 것이 아니라 그
냥 '가'라는 코드값으로 저장이 된다. 완
성형 코드체계란 한글로 나타낼 수 있는
단어들 하나하나를 코드값으로 정의해 수
천개의 코드값을 가지고 있는 엄청난 코
드다.

유니코드 역시 마찬가지다. 유니코드에도
수천개의 한글코드값들이 들어가 있다.

1. 현재 컴퓨터에서는 새로운 단어 입력
은 불가능하다. 예를 들면,
'ㅉ+ㅜ+ㅃ'을 입력해보시라. 분명히 초성
(ㅉ)+중성(ㅜ)+종성(ㅃ)으로 이루어진 완
전한 한글이지만 입력을 하면 '쭈ㅃ'이거
나 '쭙'만 된다.
--> 이건 심각한 문제라고 본다.

2. 한글 관련 프로그래밍 어색하다.
예를들면, 영어에서는 "abc"라는 문자열
과 "abcd"라는 문자열의 길이는 각각 3
바이트와 4 바이트이다.
한글에서 "간다."는 몇개의 단어로 이루
어져있을까? 내 머리로는
"ㄱ ㅏ ㄴ ㄷ ㅏ ."의 6개의 단어다. 근
데, 컴퓨터에서는
"간다." = '간' + '다' + '.'
로 3글자로 문자열 길이는 5바이트다.

컴퓨터에서 한글은 과학적인 문자가 아니
라 한자가 못되 안달이난 후진 문자가 되
었다. 가끔은 이런 X같은 한글 코드체계
를 쓰고 있다는 것과 앞으로 얼마나 많은
한글 단어들이 사라지고 못쓰게될지 답답
하다.

대한민국의 머리좋은 컴퓨터 관련 대학교
수님들과 국어학자님들은 이런 잘못된 것
을 알면서도 내버려 두는 것일까?

Linux에서는 한글다운 코드체계가 하루빨
리 적용 되었으면 한다.

익명 사용자의 이미지

한글 조합형도... 국가 표준입니다.

문제는 ... 초기에 KSC 5601 이라는 머저리 완성형 코드를 국가 표준이랍
시고 세운 놈팽이들입니다.

리눅스에서도 조합형 잘 쓸 수 있습니다.
다만 .. 다른 사람들이 .. 잘 안 쓰죠.

완성형보다 더 큰 문제는 ... MS 의 확장완성형입니다.

그런데.......

유니코드에선 완성/조합형 논쟁이 무의미 합니다.
조합형 코드 모두를 포함한 완성형이니까요.

리눅스에서의 독자적인 ... 코드보다는 차라리 유니코드를 빨리 쓸 수
있기를 바라는 게 낫습니다..

익명 사용자의 이미지

국어 하 시간에~

정말 감명깊게 수업들었는데~

비록 기말고사는 망쳤지만 ^^;;

역시 훈민정음은 놀라워요~

익명 사용자의 이미지

이렇게 생각하면 안 되는 일이겠지만서도,

솔직히 소프트웨어 엔지니어의 입장에서 완성형이 고마울 때가 있습니다.
물론 이건 일본어, 중국어 간체, 중국어 번체의 다른 아시아권 DBCS 캐릭
터셋에 비해 말이지요.
아마 일반 프로그램에서는 동아시아권에서는 한국어 환경에서 그나마 제
일 오버헤드와 코드 깨짐이 제일 적을 것입니다. 그 근거를 예를 들면,

한국 KSX5601 코드셋 (EUC 영역 호환)
Leadbyte Range 0xa1-0xfe
Trailbyte Range 0xa1-0xfe

일본 ShiftJIS 코드셋, 중국어 번체 big5, 중국어 간체 gb2312
Leadbyte Range 0xa1-0xfe
Trailbyte Range 0x40-0x7e,0xa1-0xfe

뒤의 Trailbyte Range를 보면 0x40-0x7e가 있는데 이는 ascii코드 영역과
겹쳐버리게 되어서 특별히 DBCS 처리 루틴을 넣지 않으면 자국어 코드 보
기를 포기해야 할 때가 많아지지요.

예를들어 윈도나 리눅스에서 표준 한글 캐릭터를 조합형으로 쓰면, 엄청
난 사태가 발생할 수 있습니다. 영문은 그럭저럭 괜찮다고 하지만 hiansi
영역(0x80-0xff)을 쓰는 코드들인 움라우트나 악상그라브 붙은 유럽에서
쓰이는 알파벳, 특수 기호 및 기타 제어 코드들은 이상한 한글로 깨뜨려
서 보게 될 가능성이 다분합니다. 그렇다면 모든 프로그램들을 한글판으
로 만들어야 되는데 그게 어디 가능하겠습니까...? 따라서 조합형은 도스
에서같이 하나의 프로그램에서만 사용했을 때나 문제점을 인식하지 못했
을 뿐이지, 윈도나 리눅스같은 경우에 있어서 사용되었다면 우리의 컴퓨
터 환경은 매우 낙후했을 지도 모른다라는 점 입니다. 아마 심하면, 유저
분 여러분들이 앞장서서 조합형을 없애자고 나섰을지도 모른다는 생각이
듭니다.

좀 애매한 얘기지만 동료 일본인 개발자로부터 한국의 KS5601 완성코드가
부럽다...라는 말을 들었었지요.