encoding이란 대체 무엇입니까?
글쓴이: geekforum / 작성시간: 화, 2001/05/08 - 7:15오후
흔히들 프로그래밍할때 EUC-KR, UTF-8, KSC5601..등으로 encoding 한다고들 합니다. 저도 전산을 전공하고 있지만 누군가가 encoding이 뭔지,그리고 키보드를 찍을때 편집기에서 어떻게 글자가 보이게 되는지 물어 보았을때 뭐라고 꼬집어 대답해 주지 못하고 대충 가르쳐 주고 넘어갔습니다. 작동원리를 분명히 배웠음에도 불구하고 말이죠.
이 참에 원리를 파악하고자 자료를 찾아 보았지만, 저의 경험과 머릿속의 지식이 정리가 안되더군요.
encoding에 대한 경험많으신 여러분들의 지식을 듣고 싶습니다. 범위가 너무 넓기 때문에 디지털, 네크워크분야쪽을 제외하고 일반적인 프로그래밍 차원수준에서 한 수 부탁드립니다.
질문은
1. 유니코드, UTF-8, KSC5601 등 이런 문자세트의 차이점은?
2. 키보드에서 글자를 치면 편집기에서 글자가 찍히는 것의 원리는?
3. 텍스트 파일과 이진파일의 차이점은요? 둘다 이진파일로 저장되는게 아닙니까? 0,1로요.
질문이 많아서 죄송합니다.
댓글
가정은 필요없고... 직접 유니코드(현재 유닉스나윈도우에서 쓰이는 2
가정은 필요없고... 직접 유니코드(현재 유닉스나
윈도우에서 쓰이는 2.0이상. 1.1은 순서대로
되어 있지 않고 이제 쓰이지 않습니다) 에서 "가" "나"
"다"를 찾아서 코드 순서대로 되어 있는지 살펴보세요.
아니, "가" 부터 마지막 글자인 "ㅎㅣㅎ"까지 중에
조합형과 순서가 다른 글자를 한글자라도 찾아내시면
지금까지의 제 주장을 모두 철회하고 님의 말씀이
모두 옳다고 인정하겠습니다.
제가 몇번 언급한 자료는 한번이라도 읽어보셨는지
모르겠군요.
>> 조합형에서는 '각''갃' 이 있는데 새로운 글자인 가+
>> 조합형에서는 '각''갃' 이 있는데 새로운 글자인 가+'ㄱㄷ'종성 이 추가된다면.. 바로 쇼트문제나 사용에 문제가 없지만 유니코드에서는 새롭게 테이블을 정의해야 하고 가+'ㄱㄷ'라는 글자코드는 맨뒤로 가겠네요?
> 구체적으로 설명해 드리죠. 조합형은 받침을 모두 하나로 생각하지
ㄱ 받침과 ㄱㅅ은 모두 하나의 순서대로 되어 있습니다. 그리고 ㄱ은
종성 코드 2이고, 그 다음이 ㄱㄱ(3), 그 다음이 ㄱㅅ(4)입니다.
말씀하신 대로 ㄱㄷ 을 추가해야 한다고 하죠. 그러면 3과 4 사이가 되는데
간격이 없으니 ㄱㄷ을 맨 뒤에 추가하고 별도의 정렬 테이블을 쓰거나,
(이렇게 하고 싶지는 않겠죠. "제자 원리"를 따라야 하고 직접
수치로 비교되어야 하고 싶을 테니까...) 아니면
ㄱㅅ부터 하나씩 밀리면서 ㄱㄷ을 추가해야 겠죠? 그럼 기존의 조합형과는
호환성이 없어지니까 그러면 안되겠죠.
고어에 있던 자음이나 겹자음받침이 현대어에서 사라진 것은....
그 발음이 존재하지 않는다는 것이 증명되었거나 정의하지 않기로 했기 때문입니다. 즉, 더이상 추가되지는 않습니다. (그러나 고어부분은 추가될 수 있습니다.)
하지만 나중에 순시옷(연시옷, 약한발음이 나는 시옷, 세모로 표시) 발음과, 옛이응(꼭지 달리 이응) 등은 발음이 존재한다는 것이 밝혀졌습니다.
"값을 치루다."에서... "갑슬 치루다"라고 읽지만 사실 '슬'의 시옷은 순시옷입니다.
또한 "이응"의 받침 'ㅇ'은 음가는 이응과 옛이응 모두 적용이 됩니다.
그리고, 모음에서도 그런 현상은 있습니다. 아래아 발음은 처음 표준말을 제정할 때, 서울을 기준으로 했기 때문에, 제주도에 남아있던 아래아 발음을 없애버렸죠.
끝으로 한가지, 유니코드의 주체가 누구입니까? 컴퓨터 분야
끝으로 한가지,
유니코드의 주체가 누구입니까?
컴퓨터 분야에서 국제표준 기술은 누가 만듭니까?
힘의 논리가 지배하는 국제사회에서 힘쌘 놈이 표준하자고 주장하면 표준이 됩니다. 당연히 유니코드는 M$를 비롯한 몇몇 다국적 컴퓨터 회사들이 겠지요.
> 유니코드는 자모단위가 아니라 글자 단위로 가정하고 있습니다. 모든
> 유니코드는 자모단위가 아니라 글자 단위로 가정하고 있습니다.
모든 언어는 자음과 모음으로 이루어져있습니다. 언어보다 컴퓨터 처리에 우선인 코드체계는 출발부터 잘못된 것입니다.
> 구체적으로 설명해 드리죠. 조합형은 받침을 모두 하나로 생각하지 ㄱ 받침과 ㄱㅅ은 모두 하나의 순서대로 되어 있습니다. 그리고 ㄱ은 종성 코드 2이고, 그 다음이 ㄱㄱ(3), 그 다음이 ㄱㅅ(4)입니다.
'ㄱㄷ' 을 추가해야 한다고 합시다. 그러면 3과 4 사이가 되는데 간격이 없으니 ㄱㄷ을 맨 뒤에 추가하고 별도의 정렬 테이블을 쓰거나,
(이렇게 하고 싶지는 않겠죠. "제자 원리"를 따라야 하고 직접
수치로 비교되어야 하고 싶을 테니까...) 아니면
ㄱㅅ부터 하나씩 밀리면서 ㄱㄷ을 추가해야 겠죠? 그럼 기존의 조합형과는 호환성이 없어지니까 그러면 안되겠죠.
--
우리가 일상 생활에서 한글을 쓰는 원리 그대로의 조합형이면 전혀 문제가 없습니다. 코드에 상당히 집착을 하시는 군요.
한국 사람이면 'ㄱㅅ'은 고정된 글자가 아니라 'ㄱ+ㅅ'으로 이해합니다. 아닌가요? 'ㄲ'은 'ㄱ+ㄱ'으로 이해합니다. 'ㄱㄷ'이란 새로운 받침이 생긴다고 해도 컴퓨터에 저장될 때는 'ㄱ'+'ㄷ'의 분리된 값으로 저장되어야 합니다. 'ㄱㄷ'에 새로운 코드값을 줄 필요는 없습니다. 단, 새로운 문자가 생겼으면 문자사전에 저장을 시켜 입출력 프로그램이 참조를 하도록 해야 겠지요.
"각다"와 "각ㄷ+다"를 처리할 때 'ㄱㄷ'이 새로운 글자로 가정을 하면
컴퓨터에 저장될 때는 'ㄱ+ㅏ+ㄱ+ㄷ+ㄷ+ㅏ'로 합니다. 화면에 뿌릴때 '(가ㄱㄷ-다)가 됩니다. 'ㄱㄷ'이 정의되기 전에는
'각따'로 표시되겠지요.
전혀 새로운 기본 문자가 만들어졌을 경우에는 코드에 새로운 값을 추가해야 겠지요. K모양과 비슷한 자음 글자가 생겼다고 가정을 합시다. 유니코드에서는 어떻게 K 글자를 처리할 건가요? K라는 받침글자를 사용해 만들 수 있는 모든 글자를 코드에 첨가해야지요? 유니코드에서는 각 글자가 개별 코드값으로 존재하니까 'Kㅏ', 'Kㅑ'식으로 유니코드의 한글 부분에 넣어야 하겠지요.
유니코드는 절대로 한글을 위한 코드체계가 아닐 뿐더라 미래의 대안도 될 수가 없습니다. 한글 글꼴을 만들려면 1만개가 넘는 글자를 도안해야 합니다. 아닌가요?
글꼴 개발자에겐 정말 끔찍한 코드입니다.
코드체계가 글자를 쓰는 방법을 정의할 수가 있는 것입니까? 전 도저히 이해가 안가는 군요. ASCII코드에 영어를 쓰는 방법이 정의 되어 있나요? 코드는 컴퓨터에 저장되는 데이터 값에 대한 사람이 읽을 수 있는 문자(비트맵)의 대응 테이블입니다.
리눅스에서 한글 메시지가 보이는 프로그램을 제대로 사용하려면 소스를 뒤져서 코드에 관련한 부분을 다 손봐야 합니다. 메뉴나 메시지가 한글로 보인다고 한글화가 된 프로그램은 아닙니다.
한글 표현에 어울리는 코드체계는 대한민국에서 만들어 다른 국가에 "한글코드체계는 이렇게 되있다"라고 알려야 합니다.
11172가 한글은 전부 다 표현한다고 자신할 수가 있는 건가요? 참, 대단한 발상입니다. 실제로는 50개도 안되는 문자를 사용하는데 컴퓨터에서는 11172개의 문자를 사용하는 현실이 된다면 한국인으로서 창피한 일입니다.
도글 wrote...> 한국 사람이면 'ㄱㅅ'은 고정된 글자가 아니라
도글 wrote...
> 한국 사람이면 'ㄱㅅ'은 고정된 글자가 아니라 'ㄱ+ㅅ'으로 이해합니다. 아닌가요? 'ㄲ'은 'ㄱ+ㄱ'으로 이해합니다. 'ㄱㄷ'이란 새로운 받침이 생긴다고 해도 컴퓨터에 저장될 때는 'ㄱ'+'ㄷ'의 분리된 값으로 저장되어야 합니다. 'ㄱㄷ'에 새로운 코드값을 줄 필요는 없습니다. 단, 새로운 문자가 생겼으면 문자사전에 저장을 시켜 입출력 프로그램이 참조를 하도록 해야 겠지요.
이것은 n바이트 코드라고 이미 사용되었던 인코딩
형태입니다. 따라서 님이 말씀하시는 조합형은
보통 사람이 이야기하는 "상용 조합형 표준"과는
거리가 먼 "N바이트 코드"와 유사한 방식으로 이해하겠습니다.
n바이트 코드는 이전에도 존재하였던 방식입니다. 다만
한 글자가 표현하는 바이트열의 수가 들쭉날쭉하므로
(1-6바이트 정도 되겠죠) 컴퓨터 상에서는 상당히
처리하기 골치아파집니다. 이미 사용되다가 더 이상
쓰이지 않는 코드이기도 하고요.
그리고 유니코드에 첫가끝 코드라는 형식으로 님이 원하는
것과 비슷한 사양이 이미 준비되어 있다는
사실은 몇번이나 이 스레드에 썼습니다.
게다가 한글 자모는 쉽게 바뀌는 것이 아닙니다.
고등학교 국어 시간에 배우셔서 잘 아시겠지만,
적어도 자모가 줄어들기는 했지 세종대왕 이래로
더 생긴 자모나 자모 조합은 없는 것으로 압니다.
사람의 경향이라는 것이 그렇게 하죠.
> 유니코드는 절대로 한글을 위한 코드체계가 아닐 뿐더라 미래의 대안도 될 수가 없습니다. 한글 글꼴을 만들려면 1만개가 넘는 글자를 도안해야 합니다. 아닌가요?
글꼴 개발자들은 이미 조합 방식으로 많은 글자를
디자인하고 있습니다. 윈도우의 굴림 글꼴을 적당한
트루타입 글꼴을 한번 열어보세요.
도안 문제는 코드 문제랑은 관련이 없습니다.
완성형 인코딩 =! 완성형 글꼴이 아닙니다.
오히려 글꼴을 네모 박스에 넣지 말고 자유롭게
빨래꼴 스타일을 쓰자고 한다면 이해가 되겠습니다만...
> 리눅스에서 한글 메시지가 보이는 프로그램을 제대로 사용하려면 소스를 뒤져서 코드에 관련한 부분을 다 손봐야 합니다. 메뉴나 메시지가 한글로 보인다고 한글화가 된 프로그램은 아닙니다.
맞습니다.
> 11172가 한글은 전부 다 표현한다고 자신할 수가 있는 건가요? 참, 대단한 발상입니다. 실제로는 50개도 안되는 문자를 사용하는데 컴퓨터에서는 11172개의 문자를 사용하는 현실이 된다면 한국인으로서 창피한 일입니다.
11172자는 현대 한글의 초성*중성*종성의 조합수입니다.
님이 알고 계시는 자모로는 고어 자모가 들어가지 않으면
더 이상 표현이 안됩니다.
그리고 "문자"와 "자모"를 혼동하지 마세요.
적어도 외국인도 한글이 자모를 조합해서 만드는 글자라는
것은 다 알고 있습니다. 글자는 glyph나 ligature의
연결로 구성되며, 한글 이외의 외국 문자도 동일한 문제를
안고 있습니다.
가령 독일어의 움라우트를 생각해 보세요. 글자와 글자에
붙는 장식 기호는 별도로 취급할 수 있습니다.
하지만 보통은 움라우트를 붙인 글자까지 코드 하나로
칩니다.
일본어도 마찬가지입니다. 일본의 50음도가 모두
별도의 글자입니까? 같은 글자에도 탁음 기호(")등을
붙이면 발음도 다른 새로운 글자가 됩니다. 물론
일본어 가나 표준에는 이러한 조합 가능한 문자가
모두 들어 있죠. 하지만 그것 이외에도
여러가지 조합으로 만들 수 있는 글자들이 많습니다.
심심하시면 태국어를 어떻게 쓰는지 한번 살펴보세요.
한글만큼 복잡하게 그립니다.
한글 문자를 각각의 glyph로 나누고 그것을 조합하라고
하든, 조합 가능한 세트를 미리 구할 수 있기 때문에
조합 가능한 문자들을 모두 순서대로 배열해 놓든,
그것은 편리에 대한 문제입니다.
한글은 그나마 쉬운 편이라고 합니다. 애초에 조합 방식으로 코드 배치가 불가능한 언어의 글자도 많이
있답니다. 이러한 글자들은 glyph나 ligature만
정의하고 실제 화면이나 종이에 대한 표현은 별도의
프로그램이 맡아서 합니다.
다만 중요한 것 중 하나는, 코드에 표준으로 정의되어
있어도 프로그램이 지원하지 않으면 의미가 없다는 것입니다.
가령 최근이 X용 모질라에서는 한텀에서 쓰던 조합 글꼴
을 사용하여 유니코드에 정의된 모든 한글 코드를 표현할
수 있습니다. 이것은 모질라측 프로그래머와 한국의
뜻있는 몇몇 분에 의해서 구현되었습니다.
첫가끝 코드의 경우에도 구현할 수 있어야 하지만 제대로
구현하고 있다는 라이브러리나 운영체제를 들어본 적이
없군요. 님이 원하시는 방식은 바로 그것과 유사하고,
게다가 고어 등도 표현이 가능한 유연한 방식이므로,
이러한 글꼴의 지원과 글꼴을 사용한 화면/프린터 출력과
입력할 수 있는 입력기에 대한 지원을 먼저 하는 것이
더 중요합니다.
>이것은 n바이트 코드라고 ><b>이미</b> 사용되었던 인코딩 >형
>이것은 n바이트 코드라고 >이미 사용되었던 인코딩
>형태입니다. 따라서 님이 >말씀하시는 조합형은
>보통 사람이 이야기하는 "상용 >조합형 표준"과는
>거리가 먼 "N바이트 코드"와 >유사한 방식으로 이해하겠습니다.
그럼 N바이트 코드가 한글 코드를 위한 대안이 되야 겠지요.
>n바이트 코드는 이전에도 >존재하였던 방식입니다. 다만
>한 글자가 표현하는 바이트열의 >수가 들쭉날쭉하므로
>(1-6바이트 정도 되겠죠) 컴퓨터 >상에서는 상당히
>처리하기 골치아파집니다. 이미 >사용되다가 더 이상
>쓰이지 않는 코드이기도 하고요.
영어는 어떤 코드 인가요? 한글자를 표현하는 바이트 수가 들쭉날쭉 하다니 이해가 안됩니다. N바이트 코드에선 '가'라는 글자를 여러 바이트로 다중 정의할 수 있나보지요?
님은 한글에서의 단어와 글자를 혼동하시는 것이 아닌가요?
'각'은 'ㄱ+ㅏ+ㄱ' 3글자로 이루어진 1 단어입니다.
완성형에서는 '각'은 그냥 1글자, 고유 코드값으로 존재합니다. 유니코드 역시 마찬가지 겠지요?
'홍 길동'은 '홍+길동'의 두 단어로 이루어질 수도 있고 '홍길동'의 한 단어로 글을 쓰는 사람이 정의할 수 있습니다.
>11172자는 현대 한글의 >초성*중성*종성의 조합수입니다.
>님이 알고 계시는 자모로는 고어 >자모가 들어가지 않으면
>더 이상 표현이 안됩니다.
님은 코드에 상당히 집착을 하시는 군요. 한글이란 언어를 유니코드에 적합하다고 무진 애를 쓰시네요. :-(
>도안 문제는 코드 문제랑은 >관련이 없습니다.
>완성형 인코딩 =! 완성형 글꼴이 >아닙니다.
>오히려 글꼴을 네모 박스에 넣지 >말고 자유롭게
>빨래꼴 스타일을 쓰자고 한다면 >이해가 되겠습니다만.
코딩 방식에 따라 글꼴의 갯수나 스타일이 정해집니다. 만일, 한글의 코딩방식이 유니코드나 완성형이 아닌 영어와 같은 형태고 풀어쓰기를 사용한다고 가정하면 한글의 글꼴 수는 100개 미만으로 줄어듭니다.
>글꼴 개발자들은 이미 조합 >방식으로 많은 글자를
>디자인하고 있습니다. 윈도우의 >굴림 글꼴을 적당한
>트루타입 글꼴을 한번 열어보세요.
왜 글꼴 개발자들이 완성형 대신 조합방식을 씁니까? 한글의 원리상 조합방식이 맞는 것입니다. 그리고, 글꼴의 최종 확인은 사람이 합니다. 완성형 코드에 대응되는 각각의 글자는 이미 고정된 글자이기 때문입니다. 완성형 코드의 글꼴을 만드는 것보다 유니코드 글꼴 만드는 것이 더 시간이 많이 걸립니다. 부정하시 겠습니까?
>그리고 "문자"와 "자모"를 >혼동하지 마세요.
문자와 자모를 혼동하다는 소리는 뭡니까?
'ㄱ'은 자음입니다. 'ㅏ'는 모음입니다. 'ㄱ'과 'ㅏ'는 각각 한문자 입니다. '가'는 'ㄱ'과 'ㅏ'의 두개의 문자로 이루어진 단어입니다. '가'라는 단어입니다. 제 이해가 틀립니까?
한글코드체계에 대해 솔찍히 깊숙히 알진 못하지만 완성형 코드 때문에 특정 한글의 표현자체가 컴퓨터에서 막혀있습니다.잘못된 표준으로 한국인 전체가 개피보고 있는 현실입니다.
한글 관련처리를 가끔 할 때가있는데 완성형 코드, 최근에는 유니코드를 다루고 있습니다만 진짜로 짜증납니다. 제가 원하는 한글 코드는 한글이 어거지로 컴퓨터에 끼워맞추어진 완성형이나 유니코드가 아니라 영어권 국가가 컴퓨터에서 영어를 실제와 똑같이 사용할 수 있는 것처럼 한글도 단순하면서 모든 표현을 가능하게하는 코드를 원하는 것입니다.
똑같은 결과를 보여주는 여러 기술들 중에 가장 뛰어난 기술은 사용하기 편리하고 이론적으로 단순한 것입니다. 유니코드는 한글처리를 위한 최선의 대안이 아닌 임시방편입니다. 임시방편으로 만들어진 조잡한 기술에 1억에 가까운 한국인들이 어설픈 한글을 몇년동안 사용해야 된다는 현실이 실제로 벌어지려고 하고 있으니 참 답답한 노릇입니다.
M$, IBM, SUN, 기타.. 유니코드가 한글의 표준으로 되면 매우 좋아하겠지요.
도글 wrote...> >n바이트 코드는 이전에도 >존재하였던 방식입
도글 wrote...
> >n바이트 코드는 이전에도 >존재하였던 방식입니다. 다만
> >한 글자가 표현하는 바이트열의 >수가 들쭉날쭉하므로
> >(1-6바이트 정도 되겠죠) 컴퓨터 >상에서는 상당히
> >처리하기 골치아파집니다. 이미 >사용되다가 더 이상
> >쓰이지 않는 코드이기도 하고요.
> 영어는 어떤 코드 인가요? 한글자를 표현하는 바이트 수가 들쭉날쭉 하다니 이해가 안됩니다. N바이트 코드에선 '가'라는 글자를 여러 바이트로 다중 정의할 수 있나보지요?
"가"와 "각"을 표현할 때 바이트수가 다르다는 것입니다.
완성형이나 조합형 등에서는 2바이트이지만 n바이트 인코딩
에서는 1 또는 2바이트가 된다는 의미입니다.
옛날 n바이트 코드는 나오는 대로 죽 풀어쓰는 형식입니다. 따라서 글자가 복잡하면 바이트수가 길어지죠.
> 님은 한글에서의 단어와 글자를 혼동하시는 것이 아닌가요?
> '각'은 'ㄱ+ㅏ+ㄱ' 3글자로 이루어진 1 단어입니다.
"각"이 글자가 아니라 단어라고요?
단어 (單語) (언어학) 자립하여 쓰일 수 있거나, 따로 떨어져서 문법적 기능을 가지는, 언어의 최소 기본
단위.
예를 드신 것은 의미가 없는 말이므로 단어라 보기
어렵겠죠. 제 글에서는 글자를 자모를 조합하여 만든
모아쓰기의 단위라고 생각하시는게 적절하겠습니다.
물론 글자를 자모에 대응하여 생각하면 혼동할 수도
있습니다만... 글자가 모여서 의미를 가지면 단어가
되겠죠.
> >11172자는 현대 한글의 >초성*중성*종성의 조합수입니다.
> >님이 알고 계시는 자모로는 고어 >자모가 들어가지 않으면
> >더 이상 표현이 안됩니다.
>
> 님은 코드에 상당히 집착을 하시는 군요. 한글이란 언어를 유니코드에 적합하다고 무진 애를 쓰시네요. :-(
이미 유니코드에서 첫가끝이라고 N바이트 인코딩과
비슷한 것을 지원한다고 적어도 5번은 썼습니다. :<
첫가끝을 사용하면 절대로 안되는 이유가 있습니까?
첫가끝의 가능성을 부정하는 것 보다는 살리는게
좋겠다는게 제 일관된 주장입니다. 왜 11172자
배열만을 문제삼는 것입니까? 그것이 유니코드에서
유일한 한글 인코딩입니까?
위쪽에 가면 제 주장을 정리한 글이 있습니다.
다시 한번 읽어주시면 감사하겠습니다.
많은 분들은 "완성형 = 유니코드 = 절름발이 코드 =
완성형 글꼴 = 비논리적 = 쓰레기"로 생각합니다.
그것이 왜 아닌지는 잘 아시겠죠?
> >도안 문제는 코드 문제랑은 >관련이 없습니다.
> >완성형 인코딩 =! 완성형 글꼴이 >아닙니다.
> >오히려 글꼴을 네모 박스에 넣지 >말고 자유롭게
> >빨래꼴 스타일을 쓰자고 한다면 >이해가 되겠습니다만.
> 코딩 방식에 따라 글꼴의 갯수나 스타일이 정해집니다. 만일, 한글의 코딩방식이 유니코드나 완성형이 아닌 영어와 같은 형태고 풀어쓰기를 사용한다고 가정하면 한글의 글꼴 수는 100개 미만으로 줄어듭니다.
코딩과 글꼴 도안은 관련 없다고 여러번 말씀드렸습니다.
한글 코딩을 내부적으로 완성형이든 풀어쓰기를 하든,
글꼴의 표현은 마음대로입니다. 가령 풀어쓰기 코드라도
완성형 글꼴을 사용할 수 있습니다.
내부적으로는 풀어쓰기 인코딩을(N바이트식) 쓰고
화면에는 완성형 글꼴로 그리게 되면 분명히 좋아하지
않으실 테지요. 하지만 그렇게 할 수 있습니다.
반대로 코드는 완성형을 쓰지만 화면 출력은
풀어쓰기로 할 수도 있습니다.
풀어쓰기 코드를 쓰니 풀어쓰기로 그려야 하는 것이
아닙니다. 제발 코드와 글꼴의 상관관계는 잊으십시오.
> >글꼴 개발자들은 이미 조합 >방식으로 많은 글자를
> >디자인하고 있습니다. 윈도우의 >굴림 글꼴을 적당한
> >트루타입 글꼴을 한번 열어보세요.
> 왜 글꼴 개발자들이 완성형 대신 조합방식을 씁니까?
> 한글의 원리상 조합방식이 맞는 것입니다. 그리고, 글꼴의 최종 확인은 사람이 합니다. 완성형 코드에 대응되는 각각의 글자는 이미 고정된 글자이기 때문입니다. 완성형 코드의 글꼴을 만드는 것보다 유니코드 글꼴 만드는 것이 더 시간이 많이 걸립니다. 부정하시 겠습니까?
당연히 갯수가 많으니 시간이 더 오래 걸리죠. :)
(2350 < 11172)
글꼴 디자인시
조합방식을 쓰는 것은 글꼴 작성의 효율 때문입니다.
말씀하신 대로 시간이 많이 걸리기 때문입니다.
앞서 네모꼴 이야기를 한 것은, 네모꼴로 글자를 디자인하면
하나의 초성 글자라도 다음에 어떤 중성이 오는지,
받침이 있는지의 여부에 따라 모양이 달라집니다.
미려한 모양을 위해서는 하나의 ㄱ이라도 수십개의
조합을 사용합니다. 10x4x4 이니 하는 것은
바로 초중종의 벌수를 나타내죠.
반면에 간단하게 디자인한 빨래꼴 글꼴은 초중성을 한벌만
디자인하면 되죠. 원하시는 것은 그런 것 아닙니까?
하지만 미적 감각의 측면에서는 다른 문제입니다.
이러한 차이는 글꼴의 미적 감각이나 도안상의 문제이지
내재하는 한글 코드와는 전혀 관계가 없습니다.
즉, 완성형 코드와 완성형 글꼴과는 관련지어 생각하시면
안됩니다. 코드가 바뀐다고 글꼴이 바뀝니까?
한글을 완성형 코드를 써도 화면에는 풀어쓰기로 할 수 있습니다.
한글을 풀어쓰기 코드를 써도 화면에는 완성형 글꼴을 사용할 수 있습니다.
완성형 코드의 비논리성을 글꼴로 증명하시면 안됩니다.
서로 다른 이야기이기 때문이죠.
결론: 원하시는게 n바이트 스타일의 인코딩이고
유니코드를 다루신다니 첫가끝 코드를 제대로 구현하시면
되는 일이 아니겠습니까?
>"각"이 글자가 아니라 >단어라고요? >단어 (單語) (언어학)
>"각"이 글자가 아니라 >단어라고요?
>단어 (單語) (언어학) 자립하여 >쓰일 수 있거나, 따로 떨어져서 >문법적 기능을 가지는, 언어의 >최소 기본
>단위.
단어는 문장을 쓰는 사람이 결정합니다! 위 정의에 있는 것처럼 '문법적 기능'을 만족하는 한 글자로 이루어진 단어가 많습니다.
'각'은 문장의 위치에 따라 '단어가 될 수도 있고 글자가 될 수 있습니다. 'ㄱ'도 단어가 될 수 있습니다. 아닌가요?
예로, "그녀의 이름 희.' 에서 '희'는 단어입니다. 사람의 한글자로 이루어진 이름입니다.
마찬가지로 영어에서 도 'a'는 단어가 될 수도 있고 글자가 될 수도 있습니다. There is a book! 에서 'a'는 문법적인 의미를 가지는 단어 a입니다. 'apple'에서는 a가 글자가 됩니다.
>한글을 완성형 코드를 써도 >화면에는 풀어쓰기로 할 수 >있습니다.
>한글을 풀어쓰기 코드를 써도 >화면에는 완성형 글꼴을 사용할 >수 있습니다.
모아쓰기로 만들어진 글꼴이 풀어쓰기에 적당하다고 할까요? 그냥 개인이 테스트나 장난으로는 할 수가 있습니다. 당연히 표현방식이 달라지면 글꼴의 모양도 바뀌어야 합니다.
>완성형 코드의 비논리성을 글꼴로 >증명하시면 안됩니다.
>서로 다른 이야기이기 때문이죠.
유니코드의 비논리성은요?
>즉, 완성형 코드와 완성형 >글꼴과는 관련지어 생각하시면
>안됩니다. 코드가 바뀐다고 글꼴이 >바뀝니까?
완성형 글꼴로 유니코드의 한글 코드를 전부 표현할 수 있다고 생각하십니까? 그렇다면 글꼴이 별로 관계가 없겠지요. 근데, 표현 못할 글자가 상당히 많습니다.
>옛날 n바이트 코드는 나오는 대로 >죽 풀어쓰는 형식입니다. 따라서 >글자가 복잡하면 바이트수가 >길어지죠.
원래 이렇게 되어야 맞잖아요? 한글의 구성원리에 맞게요.
유니코드와 완성형의 문제는 한글 언어의 기본 성격을 개무시 한 겁니다. 그래서 싫습니다. 국가 표준으로 정해지면 어거지로 사용해야겠지요. 별수 있습니까? 몇명이서 "한글로 표현할 수 있는 글자의 수는 1만 몇천가지이고 이것으로 현재 한글 생활을 충분하다!"
대한민국 지식인과 정부의 사대주의가 유니코드에서도 드러나는 셈이겠지요. 10의 노력으로 될 것을 다른 국가들이 괜찮다고 100의 노력을 드려야 똑같은 결과를 얻는 그렇다고 미래에 대한 확실한 대안도 없는 기술을 사용하는 셈이니까요.
> 첫가끝 코드의 경우에도 구현할 수 있어야 하지만 제대로 구현하고
> 첫가끝 코드의 경우에도 구현할 수 있어야 하지만 제대로
구현하고 있다는 라이브러리나 운영체제를 들어본 적이
없군요. 님이 원하시는 방식은 바로 그것과 유사하고,
게다가 고어 등도 표현이 가능한 유연한 방식이므로,
이러한 글꼴의 지원과 글꼴을 사용한 화면/프린터 출력과
입력할 수 있는 입력기에 대한 지원을 먼저 하는 것이
더 중요합니다.
순전히 표준화한 사람들 잘못입니다.
표준안에 넣어두기만 하고... 구현 방법은 전혀 제시하지 않았습니다.
중국어나 일본어는 친절히 모든 경우에 대해 구현 예시를 들었음에도 불구하구 말입니다.
구현하지 않은 이유는... 실제로 해당 언어 사용자들이 사용하지 않기 때문이랍니다.
즉, 너희들이 쓰지 않는 것은 우리가 고생해서 넣어줬으니, 구현은 알아서 해라 뭐... 그런 뜻이죠.
이천풍 wrote...> 순전히 표준화한 사람들 잘못입니다.> 표
이천풍 wrote...
> 순전히 표준화한 사람들 잘못입니다.
> 표준안에 넣어두기만 하고... 구현 방법은 전혀 제시하지 않았습니다.
> 중국어나 일본어는 친절히 모든 경우에 대해 구현 예시를 들었음에도 불구하구 말입니다.
> 구현하지 않은 이유는... 실제로 해당 언어 사용자들이 사용하지 않기 때문이랍니다.
> 즉, 너희들이 쓰지 않는 것은 우리가 고생해서 넣어줬으니, 구현은 알아서 해라 뭐... 그런 뜻이죠.
중국어와 일본어에 대한 모든 경우에 대한 구현
예시라는 것을 어디서 찾을 수 있나요?
한국어를 읽고 쓰지 못하는 사람들에게 어떻게 한국어
구현에 대한 예시를 제시하라고 할 수 있습니까?
당연히 그건 우리나라 사람들이 해야죠. 국가가 하는
것이 가장 좋습니다만 안되면 개인들이라도...
표준안에 한국 사람들도 참여한 것으로 압니다.
(그랬으니 현대어 한글이 모두 들어갔겠죠)
마지막으로 한마디 하죠.혹시 님의 이름(한자)을 유니코드로 표현할 수
마지막으로 한마디 하죠.
혹시 님의 이름(한자)을 유니코드로 표현할 수 있나요?
제 이름은 표현할 수 없답니다.
아니, 더 정확하게는 제가 지금까지 사용한 프로그램 가운데....
유일하게 아래아한글만이 표현할 수 있답니다.
그래서 요즘에 제 이름을 정확히 쓰는 것을 포기하고,
그냥 코드에 있는 대로... 李天豊이라고 표기한답니다.
저 13획짜리 "풍부할 풍"는 표준 한자입니다만...
제 이름은.... "풍부할 풍"의 원자입니다.
같은 뜻의 한자이지만... 이름에 쓰게 되면 의미가 틀려지죠.
豊에는... '가을'이라는 의미나 '기원(바램)'이라는 의미가 없습니다.
궁금하시면... 그런 의미가 있는지... 한자 사전(옥편)에 찾아보십시오.
제가 가진 사전에는 눈을 씻고 찾아봐도 없네요.
제가 유니코드를 싫어하는 이유는 비단 조합형이네 완성형이네를 떠나서...
솔직히 제 이름조차 표현할 수 없는 코드가 싫기 때문입니다.
특히나, 유니코드 2.0이나 3.0에서는 많은 기대를 했었습니다.
그런데, 속자나 반자는 기록되지만, 원자는 기록되지 않는다고 해서 실망이 큽니다. 배신당한 기분이죠.
속자나 반자는 문장에서 사용되지만, 원자는 사용하지 않기 때문이겠죠.
유니코드에 있는 원자들은... 한중일 삼국 가운데 어느 한 나라에서는 원자이지만 표준한자인 경우입니다.
(어떤 의미에서 보면... 컴퓨터 코드에 한이 맺힌 사람이죠. -.-;;)
그래서 더욱 아래아한글을 좋아하는지도 모르구요.
아참...
구현방법을 직접 제시하거나 하지는 않고,
어느 문헌 참조라는 식으로 넘어갔습니다.
그런데, 유독 한글처리에 대한 부분은 그런 것이 없네요. -.-;
> 한국어를 읽고 쓰지 못하는 사람들에게 어떻게 한국어
> 구현에 대한 예시를 제시하라고 할 수 있습니까?
그리고, 독해와 구현은 전혀 다릅니다. 구현은 번역이 아니거든요.
적어도 컴퓨터 상에서는 구현은 바이트나 비트를 다루는 작업일 뿐입니다.
님이 그러셨듯이 외국인이 한국어 처리에 대해 더 잘 알 때가 있다고 하셨죠.
그럴 수 밖에 없습니다.
그네들이야... 필요하기 때문에 열심히 한국어 처리에 매달리겠지만...
우리야 단순히 한국어를 표현하게 되면 더이상의 변환이나 구현은 신경쓰지 않게 됩니다.
그리고, 구현방법을 제시하는 것은 코드 변환작업을 제시하라는 의미가 강하죠.
실제 화면에 뿌려주는 것은 구현이 아닌 단순한 표현일 뿐이죠.
자기 이름을 제대로 표현하고 싶다는 바램이 너무 지나친 녀석이라고 생각해 주십시오.
그럼 안녕히.
한국에 사는 사람으로서,이름을 지을 때 쓰였던 한자의코드문제로
한국에 사는 사람으로서,
이름을 지을 때 쓰였던 한자의
코드문제로 고민해야 합니까?
이름이 어떻게 만들어졌는지를
아는 것은 좋지만,
이름을 원어로 표시할 필요는
없습니다.
다른 수많은 외래어들과 마찬가지로...
이천풍 wrote...> 유일하게 아래아한글만이 표현할 수 있답니다.
이천풍 wrote...
> 유일하게 아래아한글만이 표현할 수 있답니다.
> 그래서 요즘에 제 이름을 정확히 쓰는 것을 포기하고,
> 그냥 코드에 있는 대로... 李天豊이라고 표기한답니다.
> 저 13획짜리 "풍부할 풍"는 표준 한자입니다만...
> 제 이름은.... "풍부할 풍"의 원자입니다.
남의 이름에 대해 왈가왈부하는것은 예가 아닙니다만,
말씀하신 豊(EUC-KR에서 0xf9a5)의 원자라면
제가 제 옥편과 아래한글 97에서 찾아보건대 다른 글자가
아니라면, 18획짜리 풍자가 맞는지요?
혹시 그렇다면 다음 유니코드 2.1 표 중 일부를
보시기 바랍니다. 맞지 않다면 제가 더 말씀드릴게 없군요.
일단 지금 쓰신 글자는 0x8c4a입니다.
http://www.kr.FreeBSD.org/~cjh/misc/feng2.gif
그리고 이것이 원래 글자가 맞는지요. (유니코드 0x8c50)
http://www.kr.FreeBSD.org/~cjh/misc/feng1.gif
아니었다면 정말 죄송합니다.
순무 풍자를 풀이 해 보시기를....맨 위에... 풀초 머리...
순무 풍자를 풀이 해 보시기를....
맨 위에... 풀초 머리.... 이건 먼 뜻이고... (豊자에는 '가을'이라는 뜻은 없네요. 수확이라는 의미가 없기 때문에...)
그 아래 ... 그윽할 유(또는 굽을 곡의 원자)는 어떤 뜻이고...
맨 아래 콩 두는 또 어떤 뜻일까요?
아무튼 잘 새겨보시기를....
시간 나시면....
오얏꽃 리 .... 하늘 천 .... 에서는
왜 '봄'과 '여름'이 나타나는지도 생각해 보심이...
피식.. 유니코드2.1로 입출력하는 대중적인 워드프로세서가 있었던가요?
피식.. 유니코드2.1로 입출력하는 대중적인 워드프로세서가 있었던가요?
사람들이 그렇게 많이 쓰는 MS워드도 그 코드를 못집어 넣겠어요~
하긴.. 워드에서 줄간격 조절하려고(워드97) 1시간동안 헤매다가 때려치고
아래아한글쓰는 저로서는 MS워드에서 넣을수 있는 방법이 있음에도 불구하고
모르고 있는지도요.. 리눅스의 문자편집기나 워드프로세서는 어떤지 궁금하네요?
(전 X를 안쓰는지라..) X쓰시는 분의 의견을 듣고 싶습니다.
도글 wrote...> > 유니코드는 자모단위가 아니라 글자 단위로
도글 wrote...
> > 유니코드는 자모단위가 아니라 글자 단위로 가정하고 있습니다.
> 모든 언어는 자음과 모음으로 이루어져있습니다. 언어보다 컴퓨터 처리에 우선인 코드체계는 출발부터 잘못된 것입니다.
>
> > 구체적으로 설명해 드리죠. 조합형은 받침을 모두 하나로 생각하지 ㄱ 받침과 ㄱㅅ은 모두 하나의 순서대로 되어 있습니다. 그리고 ㄱ은 종성 코드 2이고, 그 다음이 ㄱㄱ(3), 그 다음이 ㄱㅅ(4)입니다.
> 'ㄱㄷ' 을 추가해야 한다고 합시다. 그러면 3과 4 사이가 되는데 간격이 없으니 ㄱㄷ을 맨 뒤에 추가하고 별도의 정렬 테이블을 쓰거나,
> (이렇게 하고 싶지는 않겠죠. "제자 원리"를 따라야 하고 직접
> 수치로 비교되어야 하고 싶을 테니까...) 아니면
> ㄱㅅ부터 하나씩 밀리면서 ㄱㄷ을 추가해야 겠죠? 그럼 기존의 조합형과는 호환성이 없어지니까 그러면 안되겠죠.
> --
> 우리가 일상 생활에서 한글을 쓰는 원리 그대로의 조합형이면 전혀 문제가 없습니다. 코드에 상당히 집착을 하시는 군요.
> 한국 사람이면 'ㄱㅅ'은 고정된 글자가 아니라 'ㄱ+ㅅ'으로 이해합니다. 아닌가요? 'ㄲ'은 'ㄱ+ㄱ'으로 이해합니다. 'ㄱㄷ'이란 새로운 받침이 생긴다고 해도 컴퓨터에 저장될 때는 'ㄱ'+'ㄷ'의 분리된 값으로 저장되어야 합니다. 'ㄱㄷ'에 새로운 코드값을 줄 필요는 없습니다. 단, 새로운 문자가 생겼으면 문자사전에 저장을 시켜 입출력 프로그램이 참조를 하도록 해야 겠지요.
> "각다"와 "각ㄷ+다"를 처리할 때 'ㄱㄷ'이 새로운 글자로 가정을 하면
> 컴퓨터에 저장될 때는 'ㄱ+ㅏ+ㄱ+ㄷ+ㄷ+ㅏ'로 합니다. 화면에 뿌릴때 '(가ㄱㄷ-다)가 됩니다. 'ㄱㄷ'이 정의되기 전에는
> '각따'로 표시되겠지요.
>
> 전혀 새로운 기본 문자가 만들어졌을 경우에는 코드에 새로운 값을 추가해야 겠지요. K모양과 비슷한 자음 글자가 생겼다고 가정을 합시다. 유니코드에서는 어떻게 K 글자를 처리할 건가요? K라는 받침글자를 사용해 만들 수 있는 모든 글자를 코드에 첨가해야지요? 유니코드에서는 각 글자가 개별 코드값으로 존재하니까 'Kㅏ', 'Kㅑ'식으로 유니코드의 한글 부분에 넣어야 하겠지요.
>
--------------
잘못 이해하고 계신것이 한가지 있군요.
님께서 주장하시는 것은 조합형이 아니라 *조합 방식* 입니다.
현재 유니코드에 있는 11172개의 한글은 조합형으로 모두 표시가능한
글자입니다. 그러므로, 조합형과 완전히 같다고 할 수 있죠.
-----------
> 유니코드는 절대로 한글을 위한 코드체계가 아닐 뿐더라 미래의 대안도 될 수가 없습니다. 한글 글꼴을 만들려면 1만개가 넘는 글자를 도안해야 합니다. 아닌가요?
> 글꼴 개발자에겐 정말 끔찍한 코드입니다.
>
---------
일만여 글자를 일일이 도안할 필요 있나요 ?
현재 글꼴 개발자들은 내부적으로 조합방식을 많이 사용합니다.
(조합형이 아닙니다. 조합방식입니다. TrueType 글꼴 조합해주는
상용 프로그램이 있다고 들었습니다.)
개발단계에서 조합방식을 이용해서, 수많은 글꼴을 얻어낼 수 있다는 말입니다.
---------
> 코드체계가 글자를 쓰는 방법을 정의할 수가 있는 것입니까? 전 도저히 이해가 안가는 군요. ASCII코드에 영어를 쓰는 방법이 정의 되어 있나요? 코드는 컴퓨터에 저장되는 데이터 값에 대한 사람이 읽을 수 있는 문자(비트맵)의 대응 테이블입니다.
>
> 리눅스에서 한글 메시지가 보이는 프로그램을 제대로 사용하려면 소스를 뒤져서 코드에 관련한 부분을 다 손봐야 합니다. 메뉴나 메시지가 한글로 보인다고 한글화가 된 프로그램은 아닙니다.
>
> 한글 표현에 어울리는 코드체계는 대한민국에서 만들어 다른 국가에 "한글코드체계는 이렇게 되있다"라고 알려야 합니다.
>
> 11172가 한글은 전부 다 표현한다고 자신할 수가 있는 건가요? 참, 대단한 발상입니다. 실제로는 50개도 안되는 문자를 사용하는데 컴퓨터에서는 11172개의 문자를 사용하는 현실이 된다면 한국인으로서 창피한 일입니다.
----------
님께서 주장하시는 것과 준호님께서 말씀하신 것과 전혀 초점이 맞지 않습니다.
님이 주장하시는 것은 조합형이 아닌 *조합 방식*이겠죠. 그러나, 말씀하시는
내용은 그 둘을 혼동하여 사용하고 계십니다.
모든것에는, 이상적인 것이 존재하고, 타협점도 존재합니다.
유니코드는, 개인적으로 개인적으로 유니코드를 좋아하지 않습니다만...
적절한 타협점이라고 생각합니다.
준호님이 여러모로 참 고생하시는군요. :)이런 상황에서는 오히려
준호님이 여러모로 참 고생하시는군요. :)
이런 상황에서는 오히려 준호님처럼 "제대로" 알고 있는 게
더 피곤하다니깐요. ^^
'제대로'라구요?유니코드에 대해서 제대로 알고 있는 것을 말씀하시는
'제대로'라구요?
유니코드에 대해서 제대로 알고 있는 것을 말씀하시는 건가요?
원리원칙을 제대로 알고 있는 것을 말씀하시는 건가요?
정말 피곤하네요~
한글의 원리원칙에 맞는 코드방식이첫가끝 방식이 아니던가요?유니코드
한글의 원리원칙에 맞는 코드방식이
첫가끝 방식이 아니던가요?
유니코드에 완성형(기존 것과는 다름)과 첫가끝
둘 다 들어 있다고 준호님이 설명하셨잖아요...
앞으로 새로운 단어가 생긴다면...?혹은, 고어에서 새로운 낱자가 발
앞으로 새로운 단어가 생긴다면...?
혹은, 고어에서 새로운 낱자가 발견된다면...?
그리고, 새로운 한자가 만들어진다면...?
중국측에서는 외국과의 호환이 필요한 공식적인 외교문서 파일에서조차 유니코드를 쓰지 않습니다.
즉, 유니코드를 만든 목적 - 서로 다른 언어체계의 2진 호환성 부여 - 을 부정하고 있는 거죠.
즉, 조합형이 우수한가? 아니면, 유니코드가 우수한가가 아니라, 앞으로 어떻게 될 것인가를 따지자면, 중국정부의 행동이 맞다고 생각합니다.
표준이 중국(대만 제외) 실정에 맞지 않는 부분이 많은데, 그것을 써라고 한다면 어떻게 되는지를 보여주는 행동이라고 생각합니다.
실제로 유니코드로 중국어를 표현하면, 전산표준용어를 겨우 표현할 수 있는 정도랍니다.
실제 생활용구나 몇몇 사무용품을 제외하면 상당히 많은 것이 표현되지 못한다는 거죠.
오죽했으면, 중국은 대만과는 다르게... 유니코드의 문자수를 2의 32 지수승 또는 2의 31 지수승으로 하자고 주장했겠습니까?
많은 국가에서 "코드의 낭비"라고 하면서 반대했다고 하는데...
솔직히... 코드의 낭비이지만, 해볼만한 것이죠.
특히나, 유니코드를 만든 목적이 진정으로 "서로 다른 언어체계의 2진 호환성 부여하는 것"이라면 당연히 그렇게 했어야 하구요.
즉, 유니코드는... 알파벳을 주로 쓰는 서양 사람들 입맛에 맞춰서 만들어낸 것일 뿐... 진정으로 2바이트 코드를 쓰는 우리네를 위해 만든 것은 아닙니다.
그리고 또한, 유니코드에선 에스페란토가 직접 기재되어 있지는 않습니다.
UN 공식문서에는 에스페란토도 기재되는데... -_-;
유니코드(UCS-2)는 ISO 10646-1에서 정의한 32비트플레인
유니코드(UCS-2)는 ISO 10646-1에서 정의한 32비트
플레인 중 첫번째 (0x00000000-0x0000ffff)에
해당합니다. 첫번째 영역이라서 BMP(Basic
Multilingual Plane)이라고 부릅니다.
(앞서 제가 제시했던 URL을 보세요)
중국에서 유니코드를 2^32로 하자고 했다면 그건
ISO10646을 모르고 하는 이야기였을 가능성이 큽니다.
원래 유니코드는 2^32 개의 코드 중 2^16개만을
의미하고 있기 때문입니다. 나머지 영역에 대한 정의도
이미 시작되었고 이집트의 상형문자 등이 보조 플레인에
정의되고 있는 단계입니다. 한자가 모자라면 그곳에,
한글 고어가 모자라면 그곳에 배치되겠죠. 고어같은것이나
일상에서 사용하지 않는 한자의 경우(중국사람이 모두
한자를 3만자 이상 외고 다닐까요?) 별도의 영역에
배치해서 문제를 해결할 수 있습니다.
한자 영역은 유니코드 3.1의 경우 2만 7천여자가 부여되어 있습니다.
http://www.unicode.org/unicode/standard/versions/Unicode3.0.html
물론 이것갖고는 부족할 수도 있겠죠.
그 경우 보조 플레인에 정의하고 BMP의 Sorrogate
영역을 통해 접근할 수 있습니다. 필요하다면 더 정의해서
사용하면 되는 것 아니겠습니까?
유니코드는 65536개로 끝나는게 아닙니다.
단지 편의상(영문자 하나 표현하는데 4바이트씩 매번
써야 한다면 별로 좋아할 사람 없겠죠)의 문제일 뿐입니다. 이러한 문제나 기존의 8비트 바이트 단위로
된 인코딩과 호환을 갖기 위해서 UTF-8같은 특별한
인코딩 방법을 사용하고 있습니다.
일본 등에서도 유니코드에 반대하는 주장이 있습니다만
그것은 언어의 구별(ISO-2022에서 보여주는)이
불가능하고 언어에 대한 글꼴 선택 문제를 어렵게 하기
때문입니다. 글자수자 모자라서라는 것은 이유가 될 수
없겠죠.
저는 유니코드를 맹신하지는 않습니다. 다른 관점이겠지만
어느 정도는 ISO-2022와 같이 언어별, 인코딩별을
구별해야 한다는 데도 동의하고, 실제로 어느 정도는
실제로 문제가 되는 부분이기도 합니다.
그리고 에스페란토 이야기인데, 주의해야 하실 것은
유니코드는 "글자를 정의"하고 있지 "언어를 정의"하고
있지 않습니다. 즉 유니코드에서는 언어 구별이 없습니다.
에스페란토에서만 사용하는 6개 글자의 경우 이미
유니코드에 정의되어 있고,
(http://www.unicode.org/Public/UNIDATA/NamesList.txt 에서 Esperanto로 찾아보세요)
나머지 글자는 기존 알파벳과 동일하니까 별도로 정의할
필요가 없습니다. 따라서 에스페란토어를 표현하는데에는
아무 문제가 없습니다.
참고로 한자 총 글자수는... 14만자가 넘는다고 하네요. (갖은자와 속
참고로 한자 총 글자수는... 14만자가 넘는다고 하네요. (갖은자와 속자, 반자, 원자 제외)
중국어 총 낱자 수는... 12만자입니다.
중국어 낱자가 한자수보다 적은 이유는...
"고어"에서만 쓰이는 중국한자가 일본이나 한국에서는 쓰이고 있기 때문입니다.
특히나 한국에서는 중국어 고어가 현대어에서 많이 쓰이고 있죠.
ps> 갖은자와 속자, 반자, 원자가 약 2만자 가량 된답니다.
>중국에서 유니코드를 2^32로 하자고 했다면 그건 ISO10646을
>중국에서 유니코드를 2^32로 하자고 했다면 그건
ISO10646을 모르고 하는 이야기였을 가능성이 큽니다.
원래 유니코드는 2^32 개의 코드 중 2^16개만을
의미하고 있기 때문입니다. 나머지 영역에 대한 정의도
이미 시작되었고 이집트의 상형문자 등이 보조 플레인에
정의되고 있는 단계입니다. 한자가 모자라면 그곳에,
한글 고어가 모자라면 그곳에 배치되겠죠. 고어같은것이나
일상에서 사용하지 않는 한자의 경우(중국사람이 모두
한자를 3만자 이상 외고 다닐까요?) 별도의 영역에
배치해서 문제를 해결할 수 있습니다.
>한자 영역은 유니코드 3.1의 경우 2만 7천여자가 부여되어 있습니다.
음... 그 한자 2만 7천자로는 중국 북경어 교과서 초등과정조차 표현하지 못한다네요.(표현하지 못하는 문자에서 지명과 인명은 제외하고도 많이 모자란다네요.) 중국이 유니코드를 싫어할만하죠.
더구나... 유니코드를 쓰자면, 중국은 모든 교과서를 새로 짜야할 판이랍니다.
교과서에 쓰이는 문자를 총합하면... 1만2천자 가량이랍니다.
이것이 교과서의 90%(10권 중 9권)이죠. 나머지 10%는 한두번 나오는 것이기에 제외한 것이랍니다.
문자수로만 따지만 10% 부분이 90%부분의 1/3 정도랍니다. 약.. 4천자...
유니코드에 정의된 부분은 8천자 가량... 나머지 부분은 일본의 한자이거나, 한국의 한자(또는 중국어 고어)이기 때문에 실제로 사용하기 힘든 한자입니다.
더구나... 문자 추가에 대한 처리가 미비하기 때문에 불만이 더욱 커졌죠.
그리고, 1문자 4바이트가 크다고 보기는 힘듭니다.
요즘에는 압축알고리듬이 많이 발전했거든요. 물론, 처음 유니코드가 제시될 때에는... 적은용량을 효율 좋게 쓰자는 의견이 나왔겠지만요.
저는 개인적으로 중국쪽에서 제출한 표준안을 지지했습니다.
언어구별도 되어 있고,
고어와 현대어 구별, 자모의 표준어와 비표준어 구별도 되어 있기 때문이죠.
구현이 좀 복잡해서 1차 선정과정에서 잘렸다고 하더군요.
> 에스페란토에서만 사용하는 6개 글자의 경우 이미
유니코드에 정의되어 있고,
> (http://www.unicode.org/Public/UNIDATA/NamesList.txt 에서 Esperanto로 찾아보세요)
나머지 글자는 기존 알파벳과 동일하니까 별도로 정의할
필요가 없습니다. 따라서 에스페란토어를 표현하는데에는
아무 문제가 없습니다.
에스페란토를 추가한 이유는 "단순히 발음을 나타내는 기호"로서입니다.
발음기호로 추가한 것이지 에스페란토어를 추가한 것은 아닙니다.
독일에서 같은 이유로 유니코드를 반대하는 사람들이 있습니다.
유니코드가 움라우트를 단순히 발음기호로서만 인정하기 때문입니다.
물론, 발음기호라도, 문자로 표현하는 것은 쓰는 사람 마음이지만, '자존심' 상하는 일이라는 점이죠.
중국쪽에서 만들었다는 안에 대한 내용을 조금 더구체적으로 볼 수 없을
중국쪽에서 만들었다는 안에 대한 내용을 조금 더
구체적으로 볼 수 없을까요?
그리고 중국의 표준 문자셋이 GB-2312인데,
이것은 6763자의 한자만이 정의되어 있답니다.
여기에 세번 확장을 더 했는데, 각각이
GB6345.1-86, GB8565.2-88, ISO-IR-162:1992인데 다 합쳐 봐야 8443자의
한자를 정의하고 있습니다. 현재 중국어 웹페이지에서
쓰이는 한자들입니다.
중국은 ISO10646-1(유니코드의 수퍼셋)을
GB 13000.1-93이라는 이름으로 93년에
국가 표준으로 받아들였습니다.
여기에는 중국측에서 추가한 101자까지 해서 총
21,003자입니다. (유니코드 2.1상당)
http://czyborra.com/charsets/codepages.html
교과서가 12,000자라면 다 표현하고도 남겠군요.
님이 말씀하신 "유니코드에 정의된 부분은 8천자 가량.."
이라는 근거는 어디에서 나오는 것인가요?
또한, 한자 영역은 일본 한자셋 따로, 한국 한자셋
따로, 중국 한자셋 따로 되어 있는 것이 아니라 섞여
있습니다. (UniHan영역) 크게 모양이 다르지 않다면
한중일의 한자는 같은 글자는 같은 코드로 매핑이 되어
있습니다. (간체 중 모양이 많이 틀린 자와 일본의
국자 등은 물론 다른 코드입니다) 한중일 표준에 정의된
글자를 모두 합친 것이 약 121,000자 정도, 여기서
공통되는 것을 추려서 20,902자가 나왔다고 합니다.
그리고 저는 일전에 "유니코드는 언어가 아니라 글자를
정의하는"이라고 했습니다. 따라서 에스페란토어의 경우
에 대한 님의 주장은 저도 동감하는 바입니다만
지금과는 관련 없는 이야기군요. 한국어의 경우도
한글 문자가 추가된 것이지 한국어가 유니코드에 존재하는
것은 아닙니다. ISO-2022의 예를 들어 그런 유니코드의
특성에 반대하는 사람들이 있다는 말씀도 드렸고요.
질문을 보고 생각난거...제 전공은 전산쪽은 아님니다만..
질문을 보고 생각난거...
제 전공은 전산쪽은 아님니다만..
기술이나 자연과학쪽의 분야에서
정확한 개념의 이해라는건 절대 쉽지않다는
생각이 듭니다..
몇년전에 일본기술자가쓴 기술의 이해라는 책에 보면
대학의 기계공학과에서 이런저런 개념을 가르치고 시험도치고
외우기도 합니다만..
진짜 열역학이나 유체역학의 개념을 심도있게
정확히 이해하는 친구들은 거의 없더라는게
그 사람의 얘기입니다..
물리나 수학쪽은 더하다고...
그냥 설명된 책을 읽고 교수의 강의를 듣고
교재 딸딸 외워서 시험치고 합니다만
정확히 그 개념이 뭔가? 하면 자신있게
이해했다고 할 사람이 과연 얼마나 될까요?..
전산쪽으로도 깊은 개념이해가 필요한 분야의
프로그래밍을 하다보면 내가 이전에 알았다고 생각했던게
잘못이었다는걸 알게됩니다...
os의 작동원리?
cpu의 작동원리?(이건 너무 어렵다....)
흔히들 공학분야를 모르는 바보들은 공학기술은
개념의 깊이가 없는줄알지만
자연의 원리를 정확히 이해한다는건
어떤 철학이나 종교를 이해하는만큼이나 어렵습니다..
더 어렵죠...
2. 키보드를 누르면 누를때와 땔 때 두번 인터럽트가 발생합니다. 이 인
2. 키보드를 누르면 누를때와 땔 때 두번 인터럽트가 발생합니다. 이 인터럽트는 키보드 내에서 처리되서 고유의 스캔코드라는 값으로 표현되서 컴퓨터로 전해지지요. 이 값이 전해질때 컴퓨터에서도 역시 인터럽트가 발생하고 OS의 인터럽트 서비스루틴이 이 스캔코드 값을 조사해서 현재 사용하고 있는 적절한 문자 세트를 표현하는 값으로 변환해줍니다. 편집기는 이 값을 받아서 적절한 폰트로 매핑한 다음 디스플레이 합니다.
3. 옛날 옛적에 텔렉스용 전동타자기로 터미널을 삼던시절. 한줄이 끝나고 다음 줄의 첫째 컬럼으로 타자기의 헤드가 이동하는 시간이 1문자가 전선을 통해 전송되는 시간보다 길어서 데이터가 씹히는 문제로 고민하다가 줄바꿈 문자를 CR-LF(캐리지리턴, 라인피드) 페어로 해서 헤드가 이동할 시간을 벌었다고 합니다. 그러다가 기계터미널의 시대가 끝나면서 더 이상 줄바꿈에 2바이트를 낭비할 필요가 없다고 여긴 개발자들은 CR을 없애버리고 LF만 사용했지요. 그래서 유닉스 계열의 시스템에서는 텍스트 파일과 이진 파일의 구분이 없습니다.
그러다가 도스가 등장하면서 무슨 이유에선지 '/'를 타이핑하기도 어렵고 터미널마다 생김새도 다르게 찍히는 '\'로 바꿔버리더니 줄바꿈 문자까지 CR-LF로 되돌려 놓습니다. 그래서 도스계열 운영체재의 시스템 콜들은 텍스트 문서로 화일 스트림을 열면 CR이나 LF를 처리할 때 CR-LF 페어로 만들어 버리거나 가정을 합니다. 따라서 줄바꿈이 없는 이진 데이터를 텍스트 파일 스트림으로 열면 난리가 나죠.
매킨토시는 CR만 사용하는 걸로 알고 있으므로 아마 매킨토시도 텍스트화일과 이진화일을 구분하지 않을 것 같습니다.
2번에 대한 답은 디지털 시스템 설계쪽을 보면 됄것같습니다.
2번에 대한 답은 디지털 시스템 설계쪽을 보면 됄것같습니다. ^^;
메모리나 cpu, 간단한 ip를 설계하는 계열의 책중에서 가장
기초적인걸 보면 키보드를 만들어서 lcd난 세븐세그먼트에 찍히는
원리같은걸 알수있게되거든요 ^^;
제가 본 책은 digital systems - prentice hall 출판
입니다.
그럼
Decoding의 반대말...
Decoding의 반대말...
encoding = en ( - 화하다 ) + coding ( 코드 )
encoding = en ( - 화하다 ) + coding ( 코드 )
코드화하다.
encoding = en ( - 화하다 ) + code ( 코드 ) +
encoding = en ( - 화하다 ) + code ( 코드 ) + ing (동명사)
코드화하기..
음... 전에 C++ 배울때... 교수님께서 하던 말....코드를
음... 전에 C++ 배울때... 교수님께서 하던 말....
코드를 만드는 작업은 모두 encoding 이라고 할 수 있다.
라고 했네요.
하지만, 컴퓨터의 자료는 모두 "코드"라고 하시면서...
결국 코드끼리 변환하는 작업이 encoding이고....
이것을 다시 복원하는 작업이 decoding이라고 하셨습니다.
이것이 전산분야의 여러 소분야에도 공통적으로 적용될 듯 하네요.
하지만, encoding과 decoding이 구분되는 경우도 있다고 생각합니다.
예를 들면 압축과 같은 경우죠.
특히나 손실압축에서는 encoding과 decoding이 구별된다고 생각하네요.
http://trade.chonbuk.ac.kr/~leesl/code/
http://trade.chonbuk.ac.kr/~leesl/code/ 를 참고하세요....
페이지
댓글 달기