리눅스에서 유니코드사용 확대에 대하여
글쓴이: geekforum / 작성시간: 일, 2000/08/20 - 4:00오전
리눅스 초보입니다.
토론할 논제라기 보다는 지식을 좀 얻고자 해서
올리는 글인데요...
한글코드 관련해서는 과거에 많이 논의 되었던 것으로 알고 있읍니다만.....
향후 리눅스에서 유니코드를 지원하는 프로그램
들이 많이 확대될 전망인데요...
그래서 리눅스에서 유니코드 지원 확대시
한글 사용 환경이 어떻게 변화될지하고,
이에 따르는 선결과제나 장/단점 등,
뭐 그러한 제반 사항에 대해 알고 싶고,
다른 분들의 고견을 듣고 싶읍니다.
Forums:
리녹스에서 유니코드에 관한 완성형, 조합형에 관한 예기는 앞에 분들이
리녹스에서 유니코드에 관한 완성형, 조합형에 관한 예기는 앞에 분들이
좋은 의견을 올려 주셔서. 저는 거기에 관한 예기보다. 타 언어에 대한
문자 입력이 수월 했으면 하는 생각에 글을 씁니다.
몇년 전만 해도. 한글 OS 쓰는 사람은 영어를 제외한 타언의 글자를
보거나 쓸수 없었죠. 설사 보기 까지는 가능해도. 쓰기는 별도의 유틸리티
프로그램이 있어야 했습니다.
작년초 쯤 인가요. MS 에서 Global IME 라는 것을 내놓으면서. 한글
운영체제에서 일본어와 중국어 보는것과 입력이 가능 해졌죠. 윈도우 2000
에 와서 OS 에서 타 언어의 문자의 입력을 쉽게 했다고 들었습니다.
( 물론 유니코드는 MS 에 의해서 이루어 졌습니다. )
즉 제가 하고싶은 말은. 세계가 국제화 되 가는데. 타 언어의 문자의
입력에 어려움이 없어야. 국제간에 문서 교환이 쉬울 것입니다. 리녹스를
예를 들자면 한글 문서 작성할때 한글버전쓰고, 일본어 문서를 작성할때
일본어 버전쓰고, 중국어 문서를 작성할때. 중국어 버전 쓰는 식이라면 상
당히 큰 하드 용량이 필요 할 뿐더러. 비 효율적 일 것입니다. 한글 버전
에서 라도. 중국어 입력기를 실행할때. 한글이 깨지지 않고. 중국어도 제
대로 입력이 되고. 하면은 빠른시간에 문서를 끝내고. 국제간에 문서교환
이 쉬울 것입니다. 이 점을 생각하지 않을수 없지요.
토론안을 상정하신 분은 유니코드를 한글 표준화에만 초점을 마추신듯
한데. 유니코드는 꼭 그 부분에만 한정해서 생각 할 수는 없을거라 생각
합니다. 인터넷으로 국경이 의미가 없어져 가는데. 국제적 문서 호환도
같이 생각 해 볼 필요가 있다고 생각합니다.
안녕하십니까...제가 유니코드관련하여 논의에 붙인 이유는유니코드냐
안녕하십니까...
제가 유니코드관련하여 논의에 붙인 이유는
유니코드냐 완성형이냐 조합형이냐에 대해
과거에 논의되었던 바를 되풀이 하자는 의도는
아니고요...^^;
현재 리눅스에서 사용하고 있는 한글환경이
유니코드 지원확대로 인해서 변화되어질 장래의
모습을 여쭙고 싶어서이며, 또한 현재 완성형
환경에서 유니코드 환경으로 가고자 할때 필요한 사항들이 어떤게 있는지 그리고 이것들이
어느정도의 준비 단계에 있는지에 대한 정보를
공유하자는 차원이 크다고 하겠죠.
사실 논의 보다는 정보를 얻고자 함이 크다 하겠습니다.
유니코드란게 어떠하던 어느정도 대세라 여겨지고,
그러다보니 초보입장에서 외국의 하우투문서를
읽어보고 주변에서 자료를 얻자고 보니, 별로인지라
앞서 이 문제에 관심이 있으셨던 분들이
이런 흐름을 그냥 관망하고 계시지는 않을 듯하여
올려본 것입니다.
신화 1. 유니코드는 11172자로 이루어진 완성형 코드이다 유니
신화 1. 유니코드는 11172자로 이루어진 완성형 코드이다
유니코드는 11172자의 조합 가능한 모든 현대 한글 영역 외에도
한글 자모(Hangul Jamo)로 불리우는 영역에 고어를 비롯한 거의
대부분의 자모를 따로 두고 있습니다. 이들 자모를 조합함으로써
현대어뿐만 아니라 고어까지도 대부분 표현할 수 있습니다.
신화 2. 유니코드는 조합형보다 표현할 수 있는 글자수가 적다
현재의 상용 조합형 코드는 단지 현대 한글의 자모만 사용할 수
있기 때문에 고어를 표현할 수 없습니다. 남는 영역을 사용할 수
있다고는 하지만 기존의 코드와 대부분 중첩되기 때문에 실제로는
사용 불가능합니다.
신화 3. 유니코드는 한글의 창제 원리를 무시한 코드이다
유니코드 한글은 그 자체에 규칙성을 가지고 있기 때문에 자모를
추출하기가 조합형 한글에서 자모를 추출하는 것만큼 쉬우며, 자모를
가지고 글자를 완성하는 것도 마찬가지로 쉽습니다.
신화 4. 유니코드는 미래에 있을 수 있는 변화에 대처할 수 없다
이것은 유니코드뿐만 아니라 세상의 모든 코드 체계가 가지고 있는
문제입니다. 5천년후에 한글에 다시 세모가 도입될지 안될지는
지금으로선 누구도 알 수 없는 문제지만, 정말로 그걸 걱정하는 사람은
없습니다.
밑에서 적은 내용인데요.:전 컴터를 컴ㅌ 로 표현하고 싶은데 글이
밑에서 적은 내용인데요.
:전 컴터를 컴ㅌ 로 표현하고 싶은데 글이 안써진다면?
:표현 자체가 안되죠?
:전 채팅을 채ㅌ 으로 쓰고 싶은데 안써진다면 챗으로 쓸수밖에 없고요.
:글자로 인한 의미전달이 제대로 안되겠죠.
이게 궁금하거든요?
유니코드에 대해 정확히 이해하지 못했을 수도 있구요.
채ㅌ이라고 제가 적을수 있나요?(ㅌ는 받침으로요) 유니코드에서... 물론 아무조작없이
적을수 있어야 하고요. 아무 조작없이 볼수 있어야되지요.
된다면 유니코드를 인정하겠습니다. 전 저게 아쉬운 거거든요.
글자에서 자소를 분석하는 것이 parser에서 필요한 것이지만
국어의 발전은 parser가 쉽다고 되는것은 아니지요. 내가 내 생각을
표현하는 글자를 맘대로 만들어 낼수 있는 환경은 기본이라고 생각합니다.
:새로운 자소의 가능성 자체는 없어도 된다는건 저도 동감합니다.
이부분은 저도 어쩔수 없다고 생각합니다. 생겨날 가능성이 있는 자모를 집어넣을 수는 없으니까요.
:하지만 있는 자소의 조합은 만들어 져야지요.
:hello라는 단어를 완성영어형 또는 유니영어형으로 집어넣자고 합시다.
:아예 웹스터 영어사전을 전부 유니영어형으로 집어넣읍시다.
:전 hello를 halllo라고 쓰고싶은데 안써진다면?
:그리고 새로운 개념의 프로토콜 attp(agolta text transfer protocol)
:을 만들었는데 써지질 않는다면?
:이게 말이 됩니까?
:당연히 10만단어(웹스터 단어가 이정도라고 치죠) 데이터 베이스화 하고
:코드화 해서 관리하면 속도 빠르죠, 스펠체크 쉽죠. 장점이 무궁무진 할 겁니다.
:그런데 왜 영어는 그렇게 하질 않죠?
:그리고 왜 한글은 그렇게 하죠?
:그냥 안타깝네요.
리눅스를 쓰시는 분들은 어떻게 입력하시는지 모르겠습니다.윈도우즈에서는
리눅스를 쓰시는 분들은 어떻게 입력하시는지 모르겠습니다.
윈도우즈에서는 입력이 가능합니다. ^^;
혹시, 윈도우즈에서도 챝, 똠, 꽗 등의 글자가 입력이 안된다면,
Windows 디렉토리밑에서 iso10646 이란 프로그램을 실행시켜서
iso10646 사용함 이란 옵션을 선택하면 됩니다.
제가 이런 글을 올리는 것은, 혹시라도 unicode 에서
챝, 똠, 꽗, 쓩 등이 입력이 안된다고 알고 계시는 분이 있을
까봐.. ^^;
아무 조작없이도 가능합니다.agolta wrote..: 밑에서
아무 조작없이도 가능합니다.
agolta wrote..
: 밑에서 적은 내용인데요.
:
: :전 컴터를 컴ㅌ 로 표현하고 싶은데 글이 안써진다면?
: :표현 자체가 안되죠?
: :전 채팅을 채ㅌ 으로 쓰고 싶은데 안써진다면 챗으로 쓸수밖에 없고
요.
: :글자로 인한 의미전달이 제대로 안되겠죠.
: 이게 궁금하거든요?
: 유니코드에 대해 정확히 이해하지 못했을 수도 있구요.
: 채ㅌ이라고 제가 적을수 있나요?(ㅌ는 받침으로요) 유니코드에서...
물론 아무조작없이
: 적을수 있어야 하고요. 아무 조작없이 볼수 있어야되지요.
: 된다면 유니코드를 인정하겠습니다. 전 저게 아쉬운 거거든요.
: 글자에서 자소를 분석하는 것이 parser에서 필요한 것이지만
: 국어의 발전은 parser가 쉽다고 되는것은 아니지요. 내가 내 생각을
: 표현하는 글자를 맘대로 만들어 낼수 있는 환경은 기본이라고 생각합니
다.
:
:
: :새로운 자소의 가능성 자체는 없어도 된다는건 저도 동감합니다.
: 이부분은 저도 어쩔수 없다고 생각합니다. 생겨날 가능성이 있는 자모
를 집어넣을 수는 없으니까요.
:
: :하지만 있는 자소의 조합은 만들어 져야지요.
: :hello라는 단어를 완성영어형 또는 유니영어형으로 집어넣자고 합시
다.
: :아예 웹스터 영어사전을 전부 유니영어형으로 집어넣읍시다.
: :전 hello를 halllo라고 쓰고싶은데 안써진다면?
: :그리고 새로운 개념의 프로토콜 attp(agolta text transfer
protocol)
: :을 만들었는데 써지질 않는다면?
: :이게 말이 됩니까?
: :당연히 10만단어(웹스터 단어가 이정도라고 치죠) 데이터 베이스화
하고
: :코드화 해서 관리하면 속도 빠르죠, 스펠체크 쉽죠. 장점이 무궁무진
할 겁니다.
: :그런데 왜 영어는 그렇게 하질 않죠?
: :그리고 왜 한글은 그렇게 하죠?
: :그냥 안타깝네요.
일단 현재로서는 조합형이니 완성형이니 하는 논쟁은 별로 의미가 없어 보
일단 현재로서는 조합형이니 완성형이니 하는 논쟁은 별로 의미가 없어 보
입니다.
저도 조합형을 지지하던 사람이었지만 이미 컴 환경은 아래에 쓰신 분들얘
기대로 굳어져 있기때문입니다.
유니코드2.0 에서는 현대한글 11172자를 모두 지원하고 그외에도 첫가끝
조합한글(자세히는 모르는 내용입니다.)을 처리할 수 있도록 되어있는걸
로 알고 있거든요...
결국 정보의 호환이라는 측면에서도 앞으로는 유니코드로 가야하지않을까
합니다.
박석육 wrote..
: 리눅스 초보입니다.
: 토론할 논제라기 보다는 지식을 좀 얻고자 해서
: 올리는 글인데요...
: 한글코드 관련해서는 과거에 많이 논의 되었던 것으로 알고 있읍니다
만.....
: 향후 리눅스에서 유니코드를 지원하는 프로그램
: 들이 많이 확대될 전망인데요...
: 그래서 리눅스에서 유니코드 지원 확대시
: 한글 사용 환경이 어떻게 변화될지하고,
: 이에 따르는 선결과제나 장/단점 등,
: 뭐 그러한 제반 사항에 대해 알고 싶고,
: 다른 분들의 고견을 듣고 싶읍니다.
----------박석육 wrote..리눅스 초보입니다.토론할
----------
박석육 wrote..
리눅스 초보입니다.
토론할 논제라기 보다는 지식을 좀 얻고자 해서
올리는 글인데요...
한글코드 관련해서는 과거에 많이 논의 되었던 것으로 알고 있읍니다
만.....
향후 리눅스에서 유니코드를 지원하는 프로그램
들이 많이 확대될 전망인데요...
그래서 리눅스에서 유니코드 지원 확대시
한글 사용 환경이 어떻게 변화될지하고,
이에 따르는 선결과제나 장/단점 등,
뭐 그러한 제반 사항에 대해 알고 싶고,
다른 분들의 고견을 듣고 싶읍니다.
---------------
선결과제라면, 저 빌어먹을 완성형 체제의 보루, 윈도스가
세상을 휘어잡고 있는데, 요걸 어떻게든 유니코드로 바꿔야 됩니다...
라는 게 유니코드 옹호자의 입장이 되겠죠.
하지만 제가 보기엔 우리나라에서 유니코드까지
도입할 필요는 없다고 봅니다. 한글의 과학적 원리나
정신적 이유를 모조리 제쳐두면 당장 완성형 체제가
그리 불편하진 않습니다. 제가 완성형을 싫어하지만
체제가 거의 굳어진 만큼(이 역시 윈도스 때문이죠)..
유니코드로는 다른 문자 코드 체계와 소통이 힘들겠죠.
사실 급한 건 조합형 체제로의 전환인데 리눅스는
아무래도 우리나라 특수specified가 아니고 전세계를
대상으로 하는 거니까 유니코드 같은 체제가 필수겠죠.
유니조합형이 정착되면 지금 조합형으로 할 수 있다고
보는 '완벽한 한글 사용성accessability'이 보장되겠죠.
readline에서 한글 첫소리만 치면 완전한 글자로
완성시켜준다던가 하는 거 말이예요. (제 홈 임시 게시판에
글을 적어둔 게 있습니다. 보면 무슨 말인지 아실 겁니다.)
아미가 gtk+ 1.3용으로 나왔다던가요?
저게 유니코드 체제를 수용한 것으로 기억하는데
일단 아미가 발빠르게 변신한 이상 한글 입력 문제는
크게 없다고 봐도 되겠죠.
유니코드라.. 조합형이나 살리지..
from [ke'izi] : where is [r]?
유니코드는 조합가능한 현대 한글 11172자를 모두 수용하고 있기때문
유니코드는 조합가능한 현대 한글 11172자를 모두 수용하고 있기
때문에 표준완성형과 달리 코드로부터 자소를 추출하기가 아주
쉽습니다. 즉, 중간 변환 과정을 거칠 필요가 없다는 것이죠.
따라서 한글의 과학화를 위해 조합형을 써야 한다는 주장은 이제
더이상 현실성이 없습니다(과학화를 위해 바쳐야 하는 코드 낭비및
충돌의 대가를 생각한다면).
여러가지 면에서 유니코드는 현존하는 코드중 최선의 선택입니다만,
가장 큰 문제는 쓰는 사람이 아무도 없다는 것... :-(
조합형과 유니코드라...유니코드로 모든걸 할 수 있는데 비용을 들여가
조합형과 유니코드라...
유니코드로 모든걸 할 수 있는데 비용을 들여가며 조합형으로 할
필요가 있느냐.
지나버린 논쟁을 왜 다시 끄집어 내느냐...
일리가 있습니다.
저는 국어국문학과 출신이고 그렇기 때문에 한글 코드에 관하여 관심이
많습니다.
한글의 창제원리를 진정으로 반영하는 코드는 조합형밖에 없지요.
11172자의 유니코드...
현상황에서는 좋습니다.
하지만 반치음과 순경음 ㅂ,아래아,여린 ㅎ,이 없어졌드시 새로운
알파벳이 생겨날 가능성이 있지요.(대표적으로 또ㅁ방각하 --> 써지지도 않죠?)
또한 필요에 의해서 ㄱ+ㅏ+ㅎ+ㄹ(표현이 안되네요)라는 글자가
생겨날 수도 있습니다.
한글의 창제원리는 이러한 모든 가능성을 염두에 두고 조합에 기반을 둡니다.
이러한 조합의 가능성을 막아버린다면?
언어의 변화가능성을 막는 길이지요.
11172의 유니코드는 10년후 100년후 1117의 코드만 남을수도 있습니다.
없어지고 생겨나는 언어의 변화에서 없어지는 것만 허용하고 생겨나는 것을
허용하지 않했기 때문이지요.
이미 결론이 나버렸지만, 막대한 비용이 들어가겠지만
그만큼의, 아니 더 큰 가치가 있는 논의일것 같네요. 한글을 죽이기 싫으면.
말씀하신 내용은 유니코드가 조합형에 대해 갖는 단점이 아니라 장점입니
말씀하신 내용은 유니코드가 조합형에 대해 갖는 단점이 아니라 장점
입니다. 유니코드는 11172자의 조합가능한 현대 한글 영역외에도
한글 자모-예전엔 첫가끝조합형으로 불려지기도 했던-영역을 배당해
두고 있어서 생각해 낼 수 있는 거의 모든 한글을 표현할 수 있습니다
(물론 여기서도 조합 방법이나 순서같은 약간의 표준은 더 제정할
필요가 있습니다만). 그러나 현재의 조합형은 현대 한글에서 쓰이는
자모만 가지고 있기 때문에 고어나 미래어를 표현할 수도 없고
임의로 자모를 추가해 넣더라도 다른 프로그램과는 전혀 호환되지
않는, 오히려 유니코드보다 더 심각한 문제점이 있습니다.
제 개인적인 생각으로는 단지 우리나라의 극소수 학자들을 위해
죽은 고어나 존재하지 않는 미래어에 대한 코드 영역을 필요 이상으로
남겨놓는 것은 바람직하지 않다고 봅니다. 그런 코드들은 유니코드의
한글 자모처럼 조합해서 쓰는 형태가 가장 이상적입니다. 그리고
어느 순간에 자연스럽게 사라져버린 순경음 ㅂ이나 쌍히읗같은 글자가
부활할 가능성이 있을까요? 아래 예로 드신 '똠방각하'같은
경우는 2350자 완성형을 제정할 때 빠진 글자였기 때문에 표현이 안되는
것이지 한글 자체의 문제이거나 유니코드에 해당되는 문제는 아닙니다.
agolta wrote..
: 조합형과 유니코드라...
: 유니코드로 모든걸 할 수 있는데 비용을 들여가며 조합형으로 할
: 필요가 있느냐.
: 지나버린 논쟁을 왜 다시 끄집어 내느냐...
:
: 일리가 있습니다.
: 저는 국어국문학과 출신이고 그렇기 때문에 한글 코드에 관하여 관심
이
: 많습니다.
: 한글의 창제원리를 진정으로 반영하는 코드는 조합형밖에 없지요.
: 11172자의 유니코드...
: 현상황에서는 좋습니다.
: 하지만 반치음과 순경음 ㅂ,아래아,여린 ㅎ,이 없어졌드시 새로운
: 알파벳이 생겨날 가능성이 있지요.(대표적으로 또ㅁ방각하 --> 써지지
도 않죠?)
: 또한 필요에 의해서 ㄱ+ㅏ+ㅎ+ㄹ(표현이 안되네요)라는 글자가
: 생겨날 수도 있습니다.
: 한글의 창제원리는 이러한 모든 가능성을 염두에 두고 조합에 기반을
둡니다.
: 이러한 조합의 가능성을 막아버린다면?
: 언어의 변화가능성을 막는 길이지요.
: 11172의 유니코드는 10년후 100년후 1117의 코드만 남을수도 있습니
다.
: 없어지고 생겨나는 언어의 변화에서 없어지는 것만 허용하고 생겨나는
것을
: 허용하지 않했기 때문이지요.
:
: 이미 결론이 나버렸지만, 막대한 비용이 들어가겠지만
: 그만큼의, 아니 더 큰 가치가 있는 논의일것 같네요. 한글을 죽이기 싫
으면.
이 논의는 제가 알기로는 3~4년전 뉴스그룹을 뒤덮었던걸로 알고 있는데.
이 논의는 제가 알기로는 3~4년전 뉴스그룹을 뒤덮었던걸로 알고 있는데.
지금 얘기하는 것 조차 뒷북치는 것 같군요.
제가 얘기해봤자 흘러가는 강물을 손으로 막을 순 없지요.
하지만 개인적인 안쓰러움은 여전히 존재합니다.
1년전과 현재의 채팅 및 게시판에서의 한글이 얼마나 변했습니까?
또 앞으로 얼마나 변할겁니까?
씨바, 졸라, 엽기등등의 신조어부터
냉무,방가 등등 약어까지
이러한 새로운 표현, 새로운 단어들이 그나라의 국어를 발전시키는
것이지요.(혹자는 왜곡이라고도 하죠)
그런데 새로운 표현, 새로운 글자들이 11172자로 한정되었다는것은
11172자 이외의 표현을 만들어 낼 수 없다는 것을 의미합니다.
한글의 발전 가능성 자체를 원천봉쇄하는 무서운 일이지요.
전 컴터를 컴ㅌ 로 표현하고 싶은데 글이 안써진다면?
표현 자체가 안되죠?
전 채팅을 채ㅌ 으로 쓰고 싶은데 안써진다면 챗으로 쓸수밖에 없고요.
글자로 인한 의미전달이 제대로 안되겠죠.
새로운 자소의 가능성 자체는 없어도 된다는건 저도 동감합니다.
하지만 있는 자소의 조합은 만들어 져야지요.
hello라는 단어를 완성영어형 또는 유니영어형으로 집어넣자고 합시다.
아예 웹스터 영어사전을 전부 유니영어형으로 집어넣읍시다.
전 hello를 halllo라고 쓰고싶은데 안써진다면?
그리고 새로운 개념의 프로토콜 attp(agolta text transfer protocol)
을 만들었는데 써지질 않는다면?
이게 말이 됩니까?
당연히 10만단어(웹스터 단어가 이정도라고 치죠) 데이터 베이스화 하고
코드화 해서 관리하면 속도 빠르죠, 스펠체크 쉽죠. 장점이 무궁무진 할 겁니다.
그런데 왜 영어는 그렇게 하질 않죠?
그리고 왜 한글은 그렇게 하죠?
그냥 안타깝네요.
조합형이 여러모로 맘에 들긴 하지만, 완성형이 채택된 이유에는국제규격
조합형이 여러모로 맘에 들긴 하지만, 완성형이 채택된 이유에는
국제규격과의 호환성이란 문제가 있었기 때문입니다.
즉, 우리나라에서 만든 소프트웨어가 외국에 나가면 코드의 충돌로
인하여 프로그램 실행 자체가 안되는 경우도 있기 때문입니다.
이러한 문제들로 인하여 Global Network 시대에서는 외국코드와의
호환성이 매우 중요하다고 생각됩니다.
MS(?) 에서 만들고 정리한만큼 unicode 는 우리나라, 미국뿐만이
아니라 전 세계적으로 사용되고 있습니다. 즉, 외국에서 우리나라에
제공할 소프트웨어를 만든다면 unicode 를 사용해서 만들것이라는
것입니다.
문제는 이것만이 아닙니다. 현재 Digital TV 등, PC/인터넷 이외의
가전제품등의 Software (좋은 예가 핸드폰이군요.)등에서는
이미 조합형 한글은 사용되지도 않고, 대부분 통신장비인 경우가 많기
때문에, 국제표준에 어긋나지 않는 완성형 한글 및 unicode 를 사용
하고 있는 중입니다. 즉, 외국의 소프트웨어가 아니라, 우리나라 내의
각종 가전기기들의 호환성도 떨어진다는 것입니다.
생물이 진화해 가면서 '완벽한 생물'도 환경의 변화에 의해서 멸종되고
불완전한 생물이 새롭게 지배해 가듯이 국어도 그렇게 변해 갈 것이고,
한글코드도 그렇게 변해 갈 것입니다. 별로 탐탁하진 않지만, unicode가
생김으로 인해서 더이상 조합형에 대한 미련은 추억과 역사속에 사라져
가게 될 것 같습니다.
이미 컴퓨터상에서의 한글이 체계가 잡혀 버림으로 해서, 한글의
기계화에 대해서는 몇세대 정도가 지날 때 까지는 변화가 없을것으로
예상됩니다만..
암튼, 조합형이 맘에 들긴 하지만, 유니코드도 상관 없다는 생각입니다.
^^;
유니코드, 유니코드... 유니코드를 써서 코딩한 경험은, 제 경우
유니코드, 유니코드...
유니코드를 써서 코딩한 경험은, 제 경우에는 Windows CE용 솔루션 개발
때 입니다만. (win CE는 8bit char는 지원하지 않고, 16bit wchar_t, 유니
코드만 지원하거든요)
유니코드로 코딩하기 때문에 따로 별달리 불편하다 싶은 것은 거의 느끼지
를 못했었습니다.
유니코드 - 완성형 코드 - IBM의 한글 코드, 사이의 변환을 해 가면서,
한 컴퓨터에서 다른 컴퓨터로 넘어갈때 마다 손 보는 것이 짜증이 나는
T.T 경우도 있었지만 말입니당 :)
그나저나, Unicode에서 자소 추출이 쉽다는 이야기군요. 괜찮은데요. 자
연언어처리 분야에서 있기때문에, 각 단일 자소를 추출할 일이 많거든요.
지금 현재 프로그램들은 대개 완성형을 일단 조합형으로 변환후에 처리하
는데. 유니코드 상에서 쉽게 자소를 얻어내는, 그런 방법이 있는지 궁금하
네요. 그러니까 코드 번호 내에 규칙이 있어.... 그러기는 어렵나? 흑. 쉬
운 방법일지, 궁금하네요 ;)
unicode, 특히 linux상에서 unicode관련 한글 처리에 대해 참고할 만한 페
이지 있으면 알려주세요 ;)
장기적으로 unicode로 가는 것이 당연하다고 보고 있습니다.... 다들
unicde를 쓰고있으면 변환할 일도 없고, locale 바꿀 일도 없고 즐겁고 평
이하고 평화롭고 ..... 그러나 16bit code에도 한계가 있쥐요. 쩌비.....
아래 보이는 소스 코드는 저의 hanmiscutils에서 가져온 한글 변
아래 보이는 소스 코드는 저의 hanmiscutils에서 가져온 한글 변환
함수입니다. 코드표가 필요한 표준 완성형<->조합형간 변환과 달리
몇번의 간단한 연산으로 바로 자소를 추출해 낼 수 있습니다. 완전한
소스 코드는 http://kldp.org/~bangjy/hangul/ 에 가면 있습니다.
/*
* utf16_to_johab: Convert UTF-16 Hangul code to Johab code.
* Note that Johab code used here is different from the
popular Johab code.
*/
int
utf16_to_johab(int ch)
{
int choseong, joongseong, jongseong;
ch -= UNI_HANGUL_FIRST;
choseong = ch / (NUM_JOONGSEONG * NUM_JONGSEONG);
joongseong = (ch % (NUM_JOONGSEONG *
NUM_JONGSEONG)) / NUM_JONGSEONG;
jongseong = ch % NUM_JONGSEONG;
return (choseong << 10) | (joongseong << 5) |
jongseong;
}
감사드립니다. 어떤 이유인지 알겠네요 ;)유용하게 잘 쓰겠습니닷.
감사드립니다. 어떤 이유인지 알겠네요 ;)
유용하게 잘 쓰겠습니닷.