코드: 모두 선택
<html>
<head>
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
<meta name="robots" content="noindex">
<meta http-equiv='Content-type' content='text/html; charset=MS949'>
제가 제시한 방법은 표준에 부합하는 방법이므로, '미봉책'이라고 하기에는 약간 어폐가 있지 않을까요? 단, 미래 지향적인 UTF-8이 아니라, '구시대의 잔재'인 (하지만, 표준에는 부합하는, IANA에 등록된 문자 인코딩인) EUC-KR을 사용한다는 점에서 만족스럽지는 않지요.andre518 씀: 점진적으로 고쳐야 할 부분이 아닌(미봉책으로)
제대로 고쳐야 할 부분으로 보입니다만...
앗, 정렬을 위해 한글 음절을 사전 순으로 배치해야 한다는 것은 오래 전에 깨어진 (저도 한때 그렇게 잘못 알고 있었던) 'urban myth'인데, 아직 잘 모르시나 봅니다.andre518 씀: 특히 캐릭터셋이 MS덕분에 뒤죽박죽(순서대로가 아닌 제정에 추가된 캐릭터의 혼재로 인해)되어 있다는 것도 화나는 일이지요..
잘 해야 2350 (이것은 기존 KS X 1001 때문에 불가피하게) + 100 여자면 현대어에 쓰이는 한글 뿐 아니라 중세 국어 문헌까지도 완벽하게 표헌할 수 있음에도 불구하고 쓸데 없이 무려 11,172 완성 음절을 넣어 놓고, 현대어 완성 음절이 아닌 글자 표현을 위해 자모도 초성, 중성, 종성 각각 20 여자씩 100자 정도면 되었을 것을 무려 220 여자나 넣어 놓은 (후자는 DPRK가 ISO/IEC 회원국 권한이 일시 '정지된' 상태에서 결정이 이뤄지지 않았다면 - 그 뒤에 DPRK 대표단이 주장한 것에 비추어 보면 - 좀더 나은 방식으로 결정되었을 가능성이 있습니다. 흠... 이것은 아무개법 위반으로 걸고 넘어갈 수도 있겠군요유니코드 역시 한글을 모두 표현할 수는 없습니다만, 65536개중 약 13000자 정도(제 기억이 맞는지 모르겠습니다만, 12000자에서 14000자 사이인걸로 기억합니다)를 한글이 차지할 수 있다는 것은 그야말로 과거와 비교하면 격세지감이요,
) 결과를 초래한 ROK 표준 당국의 '뚝심'(ISO/IEC JTC2 산하의 ISO 10646 담당 분과위에서 논란이 아주 많아서 투표 끝에 겨우 통과시켰지요)이 저는 전혀 자랑스럽지 않은데요 우선, UTF-8은 한글 표현에 전혀 문제가 없다는 점(단지 데이터 전송량, 저장량의 크기 증가 문제로 약간 고민을 할 수는 있겠지요)을 다시 한번 말씀 드립니다.얘기가 잠시 옆으로 흘렀습니다만, UTF-8로 해도 현재 시스템의 한글환경과 100% 맞아 떨어지지 않고 EUC-KR로 해도 현재 시스템의 한글환경과 100% 맞아 떨어지지 않는다면 UTF-8로 이전하는게 향후의 유니코드 발전에도 맞지 않을까해서 드린 말씀입니다.
유저들이 이 포럼을 탐색중: 가입된 유저 없음 그리고 0 손님들