Mozilla 한국 커뮤니티

네이버 블로그 페이지 선두가 위와 같이 되어 있습니다. MS949는 IANA charset registry에 등록되어 있지 않습니다. 블로그 서비스를 전면적으로 UTF-8로 바꾸는 게 최선이지만(다른 서비스도 아니고, UTF-8이나 유니코드에 대한 인식이 충분히 확산된 시점에서 시작한, 또 XML과 연관이 많은 블로그 서비스를 처음부터 UTF-8로 만들지 않은 이유를 도저히 알 수 없군요.), 시일이 걸릴 수 있고, 급히 하다 보면 예상치 않은 자잘한 문제에 봉착할 수 있으므로, 당분간 다음과 같이라도 하면 좋겠군요.

1. EUC-KR로 바꾼다.
2. EUC-KR에서 2바이트로 표현되지 않는 한글 음절이나 US-ASCII/ISO-646:KR/KS X 1003 + KS X 1001의 표현 영역 밖의 글자는 NCR로 표시한다.

음.. 표준의 문제중 하나인 MS949라...

MS환경 종속적인 인코딩의 문제라고 볼 수 있겠네요.

과거 유니코드가 널리 퍼져있지 않던 시절에 자주 겪던 문제가...
아직까지 보이다니.. ^^

점진적으로 고쳐야 할 부분이 아닌(미봉책으로)
제대로 고쳐야 할 부분으로 보입니다만...

andre518 wrote: 점진적으로 고쳐야 할 부분이 아닌(미봉책으로)
제대로 고쳐야 할 부분으로 보입니다만...

제가 제시한 방법은 표준에 부합하는 방법이므로, '미봉책'이라고 하기에는 약간 어폐가 있지 않을까요? 단, 미래 지향적인 UTF-8이 아니라, '구시대의 잔재'인 (하지만, 표준에는 부합하는, IANA에 등록된 문자 인코딩인) EUC-KR을 사용한다는 점에서 만족스럽지는 않지요.

MS는 자사의 인코딩 가운데 글자 한 자를 한 바이트로 나타내는 Windows-1251, 1252, 1255, 1257 등을 IANA에 등록했지만, 동아시아 국가용 자사의 코드 페이지인 949(한국의 EUC-KR 확장), 932 (x-GBK: 확장이라는 용어가 949처럼 적절하지 않음. 등록된 GB2312의 확장이기는 하지만, 중국 정부는 x-GBK와 상위 호환적인 GB18030 사용하도록 했으므로), 936(Shift_JIs : 이 경우에는 확장이라는 용어가 그리 적절하지 않겠지요. SJIS를 만든 주체 가운데 하나가 MS이니까요. 굳이, 등록 필요 없음. Shift_JIS가 등록되어 있음.), 950 (Big5: 확립된 표준이 없이 오랫동안 관행적으로 사용해 왔으므로, 확장이라는 용어가 부적절합니다. 최근에서야 대만 표준 당국이 Big5를 '표준화'했습니다)는 등록하지 않았습니다. 949의 경우 명시적으로 MS에 등록 의향을 타진했으나 하지 않았지요. (ms가 하지 않아도 제 3자가 windows-949라고 등록할 수도 있기는 했습니다.) 대신, 마치 자신들이 임의로 EUC-KR을 확장해서 만든 코드 페이지 949가 마치 한국 표준인 양 자사 제품에서 'ks_c_5601-1987'이라는 황당한 꼬리표를 붙이도록 만들어 놓았지요 (MS OE, IE, Outlook, Frontpage 등)
MS가 이미 인터넷 상에서 잘 확립되어서 1990년대 초반 이후에 쓰이고 있었던 EUC-KR을 쓸 수 없다고 "버티면서" 'ks_c_5601-1987'이나 그 변형을 고집하던 1997-8년 무렵에 한국 표준 명명 체계가 바뀌어서 정보 통신 분야 표준이 전기/전자 표준인 C 섹션과 분리되어 새롭게 만들어진 X 섹션에 들어갔고, KS C 5601은 KS X 1001로 개명되었지요.

^^; 오해가 있었던 것 같습니다...

미래지향적인(말씀하신대로) UTF-8이 아니라 EUC-KR로 임시로 거쳐야 하는 과정을 표현으로 '미봉책'이라고 한 것일 뿐이구요.

특히 일개 기업이 자기네들 마음대로 한 국가의 글을 컴퓨터로 표시할 수 있는 것을 좌우하는 것이 특히 문제였던 과거에 비하자면 유니코드 기반에서 한글은 엄청난 날개를 단 것이란 것을 저도 잘 알고 있습니다.

과거 MS949는 언어학자와 개발자 어느 쪽에도 환영받지 못했던 절뚝발이였거든요. 하지만, 그네들 마음대로 결정하고 따라야했던 것은 그야말로 완성형, 조합형의 문제와 2벌식, 3벌식의 문제들과 마찬가지로 수많은 개발의 아픔을 남겼던... 하지만 그렇게 흘러갈 수 밖에 없었던 것이었겠죠.. (그걸 이끌어낸 회사가 M$였으니까요...)

지금도 우리나라의 문서환경들이 [TG조합형-KS완성형-KSSM조합형-MS통합형-유니코드]으로 넘어가면서 과거 문서들을 읽으면 컴퓨터쟁이만 어떤 프로그램을 통해서 어떤 셋팅으로 읽어야할지 안다는게 참으로 불공평한 일이라고 느낍니다.

특히 캐릭터셋이 MS덕분에 뒤죽박죽(순서대로가 아닌 제정에 추가된 캐릭터의 혼재로 인해)되어 있다는 것도 화나는 일이지요..

유니코드 역시 한글을 모두 표현할 수는 없습니다만, 65536개중 약 13000자 정도(제 기억이 맞는지 모르겠습니다만, 12000자에서 14000자 사이인걸로 기억합니다)를 한글이 차지할 수 있다는 것은 그야말로 과거와 비교하면 격세지감이요, 주어진 환경에서는 대단히 안락한 결과라고 느끼는 것을 보면 과거의 우리나라 글을 컴퓨터에서 구현하는게 얼마나 어려운 일이었는지 다시 한 번 새삼 느끼게 됩니다. 하긴.. '한글카드'란게 기억이 나네요.. ㅎㅎㅎ

얘기가 잠시 옆으로 흘렀습니다만, UTF-8로 해도 현재 시스템의 한글환경과 100% 맞아 떨어지지 않고 EUC-KR로 해도 현재 시스템의 한글환경과 100% 맞아 떨어지지 않는다면 UTF-8로 이전하는게 향후의 유니코드 발전에도 맞지 않을까해서 드린 말씀입니다.

국내 웹 환경을 돌아다니다보면 UTF-8로 페이지 인코딩을 할 때 그 페이지내에서 깨어지는 것도(아예 다 깨어지면 말도 안 합니다. 몇개는 제대로 나오고 그 페이지내 기타 내용은 깨어지고.. 거참...) 있는 것을 보면 이래저래 답답하죠..

다만 현재 JSP쪽(자바의 태상상 유니코드 기반이므로)은 꽤 많이 UTF-8로 와 있고, 테터툴즈와 같은 PHP 블로깅이나 기타 관련 소스들이 UTF-8로 자연스럽게 이전해와 있는 와중에 굳이 EUC-KR이라는 중간단계를 거칠 필요가 있을까 싶습니다. 아무래도 큰 업체가 움직여준다면 더할 나위가 없을테니까요.. 그게 네이버라면.. 더더욱 한 번 즈음 욕심내어볼만 하죠.. ^^

빛알갱이님의 말씀에 기분 좋게 답하고 갑니다....
그런데...? 이거 왜 우리가 고민하는거죠;;; 우린 어쩜 일개 개발자일뿐일지도 모르는데.. ㅡ,.ㅡ 생각하니 답답하네요.. 이런거 표준으로.. 확 밀어붙이는 대통령 나오면 한 표 찍어줄건데... 당연히 웹 표준도 플러스~~~!! ㅎㅎㅎ

andre518님의 UTF-8 전면 이행 주장에는 저도 전적으로 찬성합니다. 단, 그 주장 과정에서 두어 가지 오해하고 계신 부분이 있어서, 제가 알고 있는 바를 적어 봅니다.

andre518 wrote: 특히 캐릭터셋이 MS덕분에 뒤죽박죽(순서대로가 아닌 제정에 추가된 캐릭터의 혼재로 인해)되어 있다는 것도 화나는 일이지요..

앗, 정렬을 위해 한글 음절을 사전 순으로 배치해야 한다는 것은 오래 전에 깨어진 (저도 한때 그렇게 잘못 알고 있었던) 'urban myth'인데, 아직 잘 모르시나 봅니다.

Windows 949에서 한글 음절이 대한민국(DPRK의 사전 순서는 대한민국과 다릅니다. 그래서, DPRK의 대표단은 ROK 사전 순서인 ISO 10646/유니코드의 한글 음절 배열 순서를 변경해 줄 것을 요구한 적이 있습니다. 하지만, 이 단락에 적은 바와 같이 코드 포인트 순서와 정렬은 아무런 관계가 없으므로, 그 요구는 어느 누구도 귀기울여 듣지 않았습니다.)의 사전 순서가 아닌 것은 하등의 문제가 되지 않습니다. 그게 문제라면 당장 US-ASCII도 영어 사전 순서가 아닙니다. 또, ISO-8859-1이나 그 부분(첫 256자)과 코드 포인트가 100% 일치하는 유니코드 역시 서유럽 국가에서 사용하는 언어 가운데 어느 하나의 사전 순서도 아닌 순서로 글자를 배치하고 있습니다. 코드 포인트 순서로 정렬을 할 수 있는 언어는 이 세상에 단 하나도 없었고, 앞으로도 없을 것입니다. 유니코드가 아니라 각 언어별로 '멀티코드'를 수천, 수만 개 만든다면 모를까요? 정렬은 정렬을 위한 함수를 통해서 해야지 단순하게 코드 포인트 비교를 통해 하는 게 아니랍니다.

Windows-949는 MS가 엉터리 이름 사용을 고집하지 않고, Windows-949를 IANA에 제대로 등록해서 사용했다면 그리 나쁘지 않았을 수 있습니다. 바로 Windows NT4/2000/XP로 가지 않고 중간에 Windows 95/98을 거쳐야 하는 상황이었다면 MS로서는 괜찮은 공학적 선택이기도 했고요.

유니코드 역시 한글을 모두 표현할 수는 없습니다만, 65536개중 약 13000자 정도(제 기억이 맞는지 모르겠습니다만, 12000자에서 14000자 사이인걸로 기억합니다)를 한글이 차지할 수 있다는 것은 그야말로 과거와 비교하면 격세지감이요,

잘 해야 2350 (이것은 기존 KS X 1001 때문에 불가피하게) + 100 여자면 현대어에 쓰이는 한글 뿐 아니라 중세 국어 문헌까지도 완벽하게 표헌할 수 있음에도 불구하고 쓸데 없이 무려 11,172 완성 음절을 넣어 놓고, 현대어 완성 음절이 아닌 글자 표현을 위해 자모도 초성, 중성, 종성 각각 20 여자씩 100자 정도면 되었을 것을 무려 220 여자나 넣어 놓은 (후자는 DPRK가 ISO/IEC 회원국 권한이 일시 '정지된' 상태에서 결정이 이뤄지지 않았다면 - 그 뒤에 DPRK 대표단이 주장한 것에 비추어 보면 - 좀더 나은 방식으로 결정되었을 가능성이 있습니다. 흠... 이것은 아무개법 위반으로 걸고 넘어갈 수도 있겠군요 ) 결과를 초래한 ROK 표준 당국의 '뚝심'(ISO/IEC JTC2 산하의 ISO 10646 담당 분과위에서 논란이 아주 많아서 투표 끝에 겨우 통과시켰지요)이 저는 전혀 자랑스럽지 않은데요


또, 어째서 한글을 일부만 표현할 수 있다고 생각하시는지 모르겠군요. 한글 자모 영역을 쓰면 모든 한글 음절을 잘 표시할 수 있습니다. 단, 화면 표시 엔진이 잘 처리해 주고, 이를 뒷받침하는 (적어도 한 벌의 무료) 글꼴(글꼴은 상당히 힘든 문제입니다.)과 입력기(이미 리눅스/유닉스용으로는 훌륭한 입력기가 있고, Mac OS X용도 아마 있을 것입니다. WIndows의 경우 Office XP/2003 사용자라면 쓸 수 있는 게 있고, 아마 '날개셋'?? 입력기가 지원하는 것 같더군요)가 있을 경우에 한해서요. 한국 국어 연구원 등에서 이 방법을 쓰지 않고, PUA(Private User Area)를 써서 고문 등을 DB화하는 것은 우려스러운 일입니다. (위에 적은 사정 상 불가피한 측면이 있습니다.) 하지만, 이미 그 PUA (한양의 글꼴에 있는 글자 배치에 따른) 코드를 표준 유니코드로 바꿀 수 있는 표도 한국 TeX User Group에서 만들어 놓았으니, 나중에 표준 유니코드로 변환하는 것은 그리 힘든 일은 아닙니다.

얘기가 잠시 옆으로 흘렀습니다만, UTF-8로 해도 현재 시스템의 한글환경과 100% 맞아 떨어지지 않고 EUC-KR로 해도 현재 시스템의 한글환경과 100% 맞아 떨어지지 않는다면 UTF-8로 이전하는게 향후의 유니코드 발전에도 맞지 않을까해서 드린 말씀입니다.

우선, UTF-8은 한글 표현에 전혀 문제가 없다는 점(단지 데이터 전송량, 저장량의 크기 증가 문제로 약간 고민을 할 수는 있겠지요)을 다시 한번 말씀 드립니다.

UTF-8의 전면적 사용은 제가 지난 몇 년 동안 꾸준히 주장하고 있는 바(2005년판 KIPA의 웹 표준 가이드의 문자 인코딩 부분을 읽어 보십시오)입니다. (시험용이 아닌 제가 만드는 모든 웹 페이지는 UTF-8만 사용합니다.) 하지만, 네이버 블로그와 같이 대규모 시스템이라면 서비스를 일시 중단한다거나 하기가 쉽지 않고, DB 이전, 프로그램 수정 (글자 한 자의 길이가 두 바이트라고 가정해 놓은 부분도 있을 것이고) 등의 작업 과정에서 예상치 못 한 문제가 발생할 수 있으므로 공학적 입장에서 지금 당장 옮기라고 요구할 수 없습니다. 따라서, 그게 힘들다면 우선 문자 인코딩 레이블을 고치고, EUC-KR 2바이트 표현 영역 밖의 글자를 NCR로 표시하라고 한 것입니다. 하기는 그렇게 하는 게 오히려 UTF-8로 넘어가는 것보다 더 세세한 부분에서 문제가 생길 가능성도 배제할 수 없게군요. 제가 네이버 블로그의 내부를 모르니 판단을 쉽게 내릴 수 없는데, 전자가 더 손쉬울 것이라고 속단하는 우를 범했습니다. 어ㅤㅉㅒㅆ든, 하루 속히 UTF-8로 넘어간다면 더할 나위 없이 좋을 것입니다.