|
:: 게시판
:: 이전 게시판
|
- 모두가 건전하게 즐길 수 있는 유머글을 올려주세요.
- 유게에서는 정치/종교 관련 등 논란성 글 및 개인 비방은 금지되어 있습니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
21/03/10 19:31
당시 완성형과 조합형이 혼재되어 사용되는 시기였죠.. 그런데 95가 완성형을 택해서.. 저런 논란이 있었어요. 초성 중성 종성의 경우를 모두 넣으면 160만개의 글자를 만들수 있지만 당시 기술문제로 완성된 모든 글자를 담기 어려워 자주쓰는 글자만 추려서 불과 2000개 정도만 담은것이 완성형이고.. 조합형은 초성 중성 종성 자모들 데이터를 조합해서 출력하는 방식이라 모든 글자를 찍을 수 있었습니다. 윈도우95에서 완성형을 밀면서 조합형은 대세에서 바이바이..
21/03/10 21:10
조합형은 이론적으로 초중종성을 맘대로 조합할 수 있기 때문에
실제 존재하지 않는 안쓰는 글자도 만들 수 있어요. 다만 160만개는 오타인듯 하네요.. 이론적으로 16000개쯤 만들 수 있습니다.
21/03/10 22:08
(수정됨) 치두음, 정치음 같은 옛한글 음소까지 포함한다면 최대 가능성이.. 초성 125개 * 중성 95개 * 종성 137개(없는 경우도 있으니 +1) = 1,638,750 가지 경우의 수가 나옵니다( ... ). 위에 카운트한 옛한글 음소들은 현재 유니코드상에서 구현이 되어있어 확인할 수 있습니다.
21/03/11 09:53
(수정됨) 말씀하시는건 조합형이 이미 아니지요.. 그냥 한글 그 자체의 가능성이죠. 아님 유니코드의 가능성이라던가..
조합형은 초성 중성 종성이 제각기 31개까지밖에 못쓰는데요... 그리고 실제로 31개를 꽉 채워서 쓰지도 않구요. 16비트 코드 체계가 어떻게 160만 글자를 표현하겠습니까..
21/03/11 10:22
(수정됨) 그러하네요. 160만개의 한글의 가능성 중에 당시 기술로는 조합형이 더 많은 글자를 표현할 수 있었다로 정정해야할 거 같네요!
21/03/11 01:35
찾아보니 유니코드의 옛한글까지 어떤 분이 정리해 놓은 자료가 있어 링크 남깁니다.
https://charset.fandom.com/ko/wiki/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C_%EC%98%9B%ED%95%9C%EA%B8%80_1638750%EC%9E%90
21/03/10 20:10
어차피 반대 운동 하시던 분들 나중에 이불킥하다가 지금은 이불킥도 멈출 정도로 시간이 오래 지났기 때문에 상관 없을 것 같고.. 그건 그렇고 41초부터 인터뷰하시는 분은 뭐라고 하시는 거에요? 영어로 말씀하시는데도 서울 사투리처럼 들리네요 ㅠㅠ
21/03/10 21:13
(수정됨) 사실 완성형이 문제다 문제다 했지만 문제되는 글자는 그렇게 많지 않았습니다.
펲시 하고.. 뭐 하여간 열몇개 정도 모자랐는데 그냥 그 열몇개만 완성형에 추가해줬음 깔끔했을텐데 말이죠. 뭐 표준이란게 그렇게 맘대로 늘릴 수 없는거야 당연하겠지만요. 조합형은 표시할 수 있는 글자의 갯수뿐만 아니라 처리하기도 좋았습니다. 지금과는 다르게 과거의 비트맵 글꼴은 초성 중성 종성의 글꼴을 조합해서 1글자를 만들어냈는데 이게 한마디로 조합형에 최적화되어있다시피한 방식이었습니다. 완성형 한글은 하드웨어적으로 2350글자의 폰트를 전부 다 가지고 있어야만 했습니다. 메모리 사용량이 과다해서 소프트웨어적으로 처리하기 힘들고 그래픽 카드에 롬으로 내장해야 했지요. 근데 완성형 한글 폰트를 내장한 한글 그래픽 카드는 롬값 때문에 쓸데없이 엄청 비싸졌습니다. 결국 나중엔 거의 사장되다시피하고 전부 소프트웨어적으로 처리했지요. 그래서 소프트웨어적으로 한글 처리할때는 무조건 완성형을 조합형으로 바꿔서 처리해야 했는데 그러고 있다보면 도대체 왜 완성형이란걸 쓸데없이 사용하는걸까.. 하는 의문이 드는게 당연한겁니다. 단순히 화면 표시할때 글꼴 처리말고도 검색이라던가.. 초성검색.. 정렬.. 기타 등등 모든 면에서 압도적으로 조합형이 우수했습니다. 완성형은 거의 안써가는 분위기였는데... 윈도우가 그걸 뒤엎어버린거죠. 뭐 지금 와서 생각해보면 그때는 글로벌 환경에 대한 이해가 모자랐습니다. 아마 그때 이미 유니코드에 대한 구상이 있었을텐데.. 유니코드에 포함시키려면 완성형이었어야 할겁니다. 조합형은 코드 공간을 지나칠 정도로 많이 사용할뿐만 아니라... 어떤 특정 바이트가 한글의 일부인지 아닌지 판단하기 위해서 문자열 처음부터 역으로 연산을 해야 한다는 치명적인 단점이 사실 있기도 했죠... 한글만 쓰는 환경에서야 뭐 그러려니했는데.. 외국인들 입장에선 무슨 이런 병신같은 코드체계가? 라고 생각했을겁니다. 조합형은 5비트씩 3개 해서 모두 15비트 공간을 꽉차게 전부 다 사용합니다... 그러다보니 16비트에서 첫번째 바이트의 맨 첫번째 비트는 1로 해서 따로 구분할 수 있는데 두번째 바이트의 맨 첫번째 비트를 1로 할 수가 없는겁니다. 14비트를 쓴다면 딱 좋았을텐데.. 초성 중성 종성 중에 그 어떤 것도 16개 이하로 줄어들지 않으니까요.. 좀 코드 체계가 약간 꼬이더라도 14비트로 다이어트할 수 있었다면... 윈도우에서 조합형 썼을지두요...
21/03/11 09:30
(수정됨) 이론적으로 못쓰는 글자하고는 별개로 실제로 실생활에서는 쓰는데
완성형으로 표현못하는 글자는 그리 많지 않았습니다. 그때 조합형 주장하는 사람들이 예로 들던 것들이 있는데 그럼 그것들말고 또 뭐가 있는데? 라고 물으면 애매했던 것도 사실입니다. 뭐 열 몇개가 그렇다고 적은건 아니지만요. 더 찾으면 조금 더 있을 것도 같고.. 완성형이 그렇게까지 허술한 코드체계는 아니죠. 수십년동안 표준으로써 큰 불편함없이 써왔는걸요. 그냥 표준을 정하는 경계선상에서 애매한 몇글자가 누락되었다 정도입니다.. 완성형이란게 구조상 메모리와의 싸움이었다보니.. 1글자 1글자가 메모리 부담이라 가지치기를 많이 한 형태입니다. 한글뿐만 아니라 한자쪽에서도 가지치기를 꽤 해서 표시못하는 한자가 많았죠.
21/03/11 09:34
요즘은 확장완성형이라고 해서 기존 완성형 코드체계 위에다가
기존에 표기못하던 글자들을 전부 덧붙여서 거의 조합형 수준으로 글자 표시가 가능합니다.
21/03/11 08:40
완성형문제는 의외로 아직까지 남아있습니다.
일례로 은행 송금시 송금자명에 특정 글자가 들어가지 않습니다. (금융결제원 공동망이 KSC5601을 사용중입니다.) '똠' 같은게 대표적인데 웃기게도 이걸 고치려는 움직임이 이제와서 있다는겁니다.
21/03/11 09:43
헐.. 은행들은 이미 자바로 다 바꿨을텐데 공동망이 아직도 구식이군요..
하기사 공동망 업그레이드하려면 전국 모든 은행이 스톱이니... 부담이 장난 아니긴 하겠군요.
|
||||||||||||