RFC 5646 (언어 식별 코드 정의 - BCP) 발표
글쓴이: bh / 작성시간: 일, 2009/09/06 - 11:07오후
IETF 에서.. 언어를 식별하는 코드를 재정의 하는 BCP 급 RFC 문서를 5646 번으로 하여..
다시 발표하였습니다.. 잘 모르고 있었는데.. 이 문서의 공동 편집자로 있는 "마크 데이비스" 씨는
유니코드 발전에 온몸과 마음을 바쳐서 일하고 있는듯 하였씁니다.. 지금은 구글에서 일하고 있다네요..
ko_KR.UTF-8 뭐 이런식으로 써오던 것에다.. 뭔가 조금 더 복잡한 형태로 바뀔거 같은 ... ...
i18n 분야에서 일하시는 분들에게 익숙한 문서이구요.. 저도 갠적으로 유니코드에 관심이 많아서..
이 문서를 함 다시 재정독 해보려 해요..
한줄요약: 모든 문자들은 "UTF-8" 로 보냅시다~~~
File attachments:
| 첨부 | 파일 크기 |
|---|---|
 wl20090906001.png | 112.82 KB |
Forums:
으흠..
UTF-8 로 대동단결!!
--------------- 절취선 ------------------------
하늘은 스스로 삽질하는 자를 삽으로 팬다.
http://glay.pe.kr
--------------- 절취선 ------------------------
하늘은 스스로 삽질하는 자를 삽으로 팬다.
http://glay.pe.kr
제 생각에는 html이
제 생각에는 html이 xhtml로 가지 못한 것과 비슷하게 euc-kr이 utf-8로 가지 못할 것이라 생각이 듭니다. 제가 있는 회사만 해도 storage에 들어 있는 게시판 본문들을 처리 하려면 힘이 들거든요. 그리고 utf8로 바꾸는 순간 storage비용이 엄청나게 들게 됩니다. DB도 마찬가지 이겠죠.
또한, 관리되지 않는 수많은 euc-kr 문서들은 어떻게 해야 할까요? 현재 시점에서 새로 시작하는 문서들을 utf-8로 가는 것은 어렵지 않습니다. (저 역시 새로운 문서들은 utf-8로 작성 합니다만..) 기존의 모든 문서를 utf8로 변경하는 것은 쉬운 작업도 아니고, 그걸 꼭 해야 한다고 생각하지 않는 사람들도 많기 때문입니다.
더군다나, windows에서 utf-8문서를 작성하는 것은 너무 귀찮습니다. 무려 마우스질을 2번이나 더 해 줘야 하거든요. 메모장에 따라 붙는 bom도 무시를 못하겠고..
그렇기 때문에 무조건 utf-8만이 대세다.. 라고 외칠 시에는 문제를 떠 않을 소지가 다분 하다고 봅니다.
P.S
http://kldp.org 는 utf-8을 사용합니다. 하시만 kldp 서버는 ko_KR.eucKR locale로 지정이 되어 있습니다. 이유인즉, 예전의 kldp 문서 파일 이름이 euc-kr인지라 ko-KR.utf8 로 지정할 경우 ls로 해당 파일이름을 볼 수가 없습니다. 보려면 'ls | iconv -f euc-kr -t utf-8' 이런 명령을 내려야 하는 데 많이 귀찮습니다. ko_KR.eucKR locale에서 utf-8 웹을 운영하는데 귀찮지 않기 때문에 굳이 locale을 ko_KR.utf8 로 갈 이유가 없는 것이죠. :-)
아 또 하나.. utf-8을 쓰지 말자는 글이 아닙니다. 요즘 자꾸 negative 한 놈으로 인식되는 것 같아 미리 밝혀 높습니다.
인코딩이 다른 파일명을 바꾸는 가장 쉬운 방법은
다른 인코딩으로 설정되어 있는 파티션으로 복사하는 것입니다.
인코딩 변경만을 위한 작업이라면, 이는 비용발생이지만,
한번 구축된 시스템이 반영구적으로 사용되는 것도 아닌 이상,
언젠가는 업그레이드라는 것이나 신규장비 이전은 언젠가는 필요로 합니다.
이 때의 이루어지는 인코딩 변경은 비용이라는 것이 발생하지 않습니다.
저장된 문서의 내용을 바꾸는 것 이는 비용이 발생합니다. 이부분은 확실히 난관이죠.
제가 볼때는 euc-kr에서 utf-8로의 이전이 생각만큼 난제가 많은 것은 아닙니다.
중요한 것은 관리자들의 의지죠.
신규장비 이전할 때 아주 약간만 신경쓰면 될 것을 이것이 귀찮아 하지 않을 뿐 아닐까요?
utf-8이 대세다라고 말하는 것은 확실히 시기상조일 수는 있습니다만...
제 생각에는 IPv6가 앞으로는 선택의 여지없이 대세 일수밖에 없는 것처럼,
utf-8 역시 마찬가지가 될 것이라 생각합니다.
사실 utf-8라고 꼭집어 말하기 보다는 유니코드가 되겠지만요.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
너무 지리즈님만의
너무 지리즈님만의 경험에 의한 단언을 하시는 것 같습니다. :-)
지리즈님의 경우에는 utf-8로의 변환이 쉬운 경우만 있으셨는지는 모르겠지만, 그렇지 않은 상황도 많습니다. 다른 파티션의로의 복사도 여러가지 경우가 있습니다. 100개의 파일을 복사하는 것과 50억개의 파일을 복사하는 것은 방법 자체가 틀립니다. 또한 100개의 파일의 작업 후 확인을 하는 것과, 50억개의 파일을 확인하는 것 또한 틀립니다. 일반 서버의 HDD 가격과 전문 Storage 장비의 HDD 가격은 엄청난 차이를 가집니다. 관리자의 업무 중에는 한가지 일만 하는 경우는 틀립니다. 특히 지원 부서의 경우에는 동시에 여러가지 작업을 하는 경우도 많습니다. utf-8로 변환하는 작업이 관리자의 의지가 없어서 라기 보다는, 그 일을 하는 것 보다 더 급한, 더 중요한 일들이 많기 때문입니다.
utf-8이 사업적인 이슈로 인하여 필요한 것이 아니라면, 제가 있는 회사의 경우에는 utf-8이 대세가 올일은 별로 없다는 것이고, 이로 인하여 utf-8이 대세라고 할 수는 없다는 말을 하고 싶었던 것입니다. (물론 전혀 쓸일이 없는 것은 아닙니다. 게임 내의 메시지의 경우에는 수출시에 각 언어별 charset에서 utf-8로 변경되는 부분이 있습니다. 하지만 주 사이트의 경우 한국인/한글을 사용할 줄 아는 사람 대상이고, KSC5601(요즘은 KSX1001이라고 해야 하나요?) 범위 밖의 문자가 중요하지 않기 때문에, 이 작업을 할 명분이 없고 (사업부에 이 작업을 하기 위한 인건비, 시간등을 할당할 명분이 없는 것입니다.) 그렇기 때문에 회사 서비스 차원에서 보면, UTF-8을 사용할 경우는 일부 밖에 없기 때문에 대세라는 것에는 전혀 동의가 되지 않는 것입니다. 너네 회사만 그렇다고 하면 할말은 없겠지만, 제가 생각했을 때는 대부분의 회사들이 비슷하지 않을까 생각 합니다. converting 할 시간에 다른 일들을 선택하는 경우가 더 많을 것이라는 의미이고, 결국에는 많은 site들이 기존에 사용하던 euc-kr을 그대로 계속 사용하는 경우가 많을 것이라는 의미입니다. xhtml도 결국에는 비슷한 이슈로 html5에 밀린 것 처럼 말이죠. (그렇다고 utf-8이 euc-kr에 밀린다는 의미는 아닙니다. utf-8이 필요한 영역이 엄연히 존재를 하고 있으니 말이죠.)
변환은
변환은 어려울지라도, 신규||확장 에 슬쩍 utf8 로 만들어 놓는 것은 괜찮을 것 같습니다.
확장의 경우 실시간 변환이라는 무시무시한 것이 필요해질 수도 있겠지만...
데이터가 utf8 로 바뀌었을 경우에 오동작하지 않도록 코드만이라도 신경 써 놓으면
어쩔 수 없이 닥쳐왔을 때 그나마 좀 편하겠죠.
emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/
https://xenosi.de/
charset의 혼재는
charset의 혼재는 그만큼 혼란만 더 가중 시킬 뿐이라고 생각이 됩니다. :-) 제 경험상.. 일부만 변경한 것들은 항상 어떤식으로든지 현재보다 더 많은 문제를 추가시켰던 것 같습니다.
정확한 지적입니다.
그래서, utf-8이 필요한 것입니다.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
지리즈님의 표현을
지리즈님의 표현을 보자면, euc-kr은 없어져야 하는 charset인것 처럼 느껴집니다. 그래서 이 쓰레드가 길어지는 것 같고요. 저는 utf-8이나 euc-kr 둘다 나름대로의 장단점이 있다고 생각하여, 필요한 곳에 사용하는 것이 좋겠다는 입장입니다. :-)
말씀 그대로 저는
euc-kr은 없어져야 하는 charset이라고 생각합니다.
제가 UTF-8이 euc-kr보다 더 좋다고 생각하거나 마음에 들어서가 아닙니다.
사실, 모든 로컬 캐릭터셋이 사라져야 한다고 생각합니다.
세계화 같은 이유로 다양한 언어를 수용해야 경우가 점차 늘어나는 것과 같은 기술적인 이유때문입니다.
저는 한 국제 컨소시엄을 위한 다양한 언어의 다양한 플랫폼에서 구동되는 다양한 어플리케이션간에
전문을 주고 받는 일종의 메세지큐 역할을 하는 미들웨어를 개발하고 있습니다.
인코딩만 생각하면 지긋지긋하죠. 이런 인터네셔날한 솔류션을 계속 개발해야 나가는 입장에서는
euc-kr,shift-jis(euc-jp)와 같은 캐릭터셋을 보는 것만으로 구역질이 날 정도입니다.
플랫폼 별, 어플리케이션마다 그 언어를 처리하는 방식이 너무나 다양하기 때문에
원래 미들웨어의 본 기능보다 이러한 캐릭터셋에 업무부하가 너무 발생합니다.
사실 더 이상 정보가 그 해당 언어권에 머물지 않고,
전세계적으로 교류가 활발해질 것은 자명한 사실입니다.
그것이 대세라면 utf-8 역시 대세입니다. 싫건 좋건 말이죠.
첨언하면 저는 UTF-8을 지지하는 것은 아닙니다. 유니코드를 지지하는 것입니다.
UTF-16이던 상관없습니다. 단 하나의 캐릭터셋으로 전세계 모든 플랫폼이 운영되는 것이 가장 바람직하고 그렇게 될 수밖에 없다고 생각할 뿐입니다.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
바로 그점 때문에 utf-8 을 별로 좋아하질 않습니다.
저역시 유니코드를 지원합니다. 하지만, 말씀하신대로 현시점까지는 단 하나의 캐릭터셋으로 전세계 모든 플랫품이 운영되는 것은 불가능하고, 그것은 utf-8 로는 안되고 있습니다. utf-16 이든 utf-32 .. 제 생각으로는 utf-128 쯤 가야 가능할 것 같습니다만 ...
그런 상황에서 새로 만드는 자료를 utf-8 로 만드는 것이라면야 괜찮겠지만, 기존의 euc-kr 이든, cp949 이든 .. 하여간에 ksc5601(요새는 좀 이름이 바뀌었지만) 에 기반을 둔 자료를 utf-8 로 바꾼다는 것은 나중에 제대로 된 유니코드(utf-8 은 반쪽짜리 유니코드일 뿐이라고 보고 있습니다.) 로 바꿀 때 어차피 한번은 더 손을 보아야 할 것이기 때문에, 두번 일하지 않기 위해서라도 굳이 멀쩡히 잘 있는 자료를 들어 엎을 이유는 없다고 봅니다. 그 자료가 몇개 안돼서 시간도 얼마 안 걸리고 ... 뭐 그렇다면 별 상관없겠지만 말입니다. ...
작년에 회사에 ERP 시스템을 도입하면서 기존 자료(euc-kr)를 utf-8 로 바꾸려다가 결국은 포기하고 그냥 euc-kr 로 쓰고 있더군요. 물론, 그렇기 때문에 ERP 도입 시점부터 생성된 자료 역시 euc-kr 로 되어 있습니다.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
세계화 같은 이유로
역시 바라보는 바가 틀리기 떄문에 발생하는 문제일 수 밖에 없습니다. 지리즈님은 개발 입장에서 local charset이 머리아픈 존재이기 때문에 없어져야 한다는 입장인 것이고, 저는 현실적으로 없어질 수 없기 때문에, 모든 charset을 case by case로 다루어야 한다는 입장인 것입니다. 정말 인터넷 상에서 local charset이 없어질 수 있다고 생각 하시는지요? 정말 앞으로 10년이나 30년 후에는, local charset에 대한 예외 처리를 하지 않아도 된다고 생각하시는지요? 제 생각에는 그 시점에도 local charset으로 된 문서는 굉장히 많을거라 생각이 됩니다.
unicode 가 개발자들의 괴로움을 덜어줄 수 있지만, 기존 euc-kr을 utf-8로 migration을 하지 않는 것을 관리자의 의지가 모자르다는 것으로 모는 것 역시 관지라들에게는 괴로움이라는 것도 아셔야 합니다. utf8 사용을 권장하는데는 동의 하지만, 지리즈님이 utf8 사용 권장을 위하여 내놓는 의견에는 동의가 되지 않아서 이렇게 계속 답변을 남기는 것입니다. 차라리 제가 위에 인용한 부분을 강조 하셨더라면 이렇게 길어지지도 않았을 겁니다. (물론 위의 인용도 너무 지리즈님의 개인 감정이 많이 들어가 있죠.)
지적하신 사항을 잘 이해했습니다.
하드디스크 복사에 대한 예는 단지 일례만 말한 것입니다.
중요한 것은 UTF-8에 대한 변환은 확장/신규장비 도입시 기회가 되면 하면 되는 것이고,
아니라면 그만인 것입니다.제 의미는 따로 전환을 위해서 크게 비용이 든다면 할 필요는 없다는 의미입니다.다만, 그렇지 않은데도 불구하고 안한다면, 관리자의 의지 부족일 수 밖에 없다는 것이죠.
UTF-8(정확히 말하면 유니코드)은 최상위 호환을 보장합니다.
상당히 많은 공개/상용 소프트웨어에서 마이그레션을 위한 인코딩 변환시
euc-kr=>UTF-8은 지원하지만, 역은 지원하지 않는 경우가 많습니다.
만약, 김정균님께서 새로운 회사에 입사해서,
제로 베이스에서 신규로 시스템을 구축해야 한다면,
어떠한 인코딩을 사용하시겠습니까?
지금 속속 새롭게 구축되는 이전시스템과의 호환이 필요없는
많은 시스템들은 어떠한 인코딩을 따를까요?
대세라고 해서 단시간에 바뀐다는 것은 아닙니다.
몇해 혹은 수십년이 걸리수도 있습니다.
그렇지만, 오늘날 euc-kr은 어쩔수 없을 때나 선택하는 옵션이 되고 있습니다.
결국 UTF-8은 대세일 수밖에 없습니다.
김정균님께서 근무하시는 회사에는 그다지 와닫지 않더라도,
SI로 많은 회사의 시스템을 구축했던 입장에서는 전혀 시각이 다를 수밖에 없습니다.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
중요한 것은 UTF-8에
아마 대부분 위에서 utf-8 변환 작업을 하라고 하면 할 겁니다. 하지만, 위에서의 의사 결정이 없다면, utf-8로의 변환 작업은 관리자의 의지로 하는 작업 중, 대부분 다른 작업 보다 우선권이 떨어질 겁니다. 즉, 관리자의 "의지 부족"이라는 단어를 사용하시기에는 부적절 하다고 보입니다. utf-8로 바꿔야 하는 상황에서 바꾸지 않을 경우에나 "의지 부족"이라는 단어를 사용하기에 적당해 보입니다.
이건 접근 방식의 차이라고 봅니다. 당연히 기존이 대부분 euc-kr 이기 때문에 utf-8로의 인코딩 변환을 지원하겠죠. :-) 수요의 차이라고 봅니다.
이 경우라면, 저만의 생각이라면 아마 저 역시 80% 이상은 utf-8을 채택할 겁니다. 하지만, 하나의 사이트에 개발이 여러팀으로 쪼개져 있는 경우라면, 고집을 할 수는 없습니다. 이 경우라면 아마 대부분 기존에 사용하던 charset을 그대로 사용하게 될 것 같습니다. (저 역시 이에 동의할 것 같다는 의미입니다.) 일단, 이에 대한 고민을 전혀 하지 않는 개발자도 있고, 지리즈님과는 반대로 utf-8을 왜 써야 하는지 이유를 모르겠다고 하는 개발자도 있습니다. 이런 개인차를 다 설득 시키면서 utf-8로 가기에는 대부분 회사의 개발 일정들은 너무도 짧습니다.
제가 제 회사의 입장에서만 그렇다고 느끼시듯이, 지리즈님의 경험은 지리즈님만의 경험으로 UTF-8이 대세야 라고 말씀하시는 것 밖에 되지를 않습니다. 지리즈님의 경험이 전체를 대변할 수는 없기 때문이죠. SI가 신규 구축이 많을지 모르겠지만, 제 경험으로는, 신규 구축보다는 migration이 더 많았던 것 같습니다. 즉, 입장차일 뿐이죠.
간혹 KLDP의 글 중 서명에 보면, "fedoar가 최고야, zentoo 로 대동단결.." 등등의 문구를 볼 수가 있습니다. 이건 개인 기호에 의해서 자기가 좋은 것을 권장하는 식의 advertize라고 볼 수도 있겠지만, 글 본문에서의 언급은 다른 사람에게 "강요"같이 보여 집니다.
요즘 개발자들 사이에, IE6을 더이상 사용하지 않기를 바라는 글들을 종종 볼 수 있습니다. 하지만, 마케팅 관점에서는 개발자 입장 때문에 IE를 업데이트 해서 사용자가 불편하게 사용을 해야 한다고 강요를 하는 것 또한 어불성설입니다. 개발자들이 IE6에 특화된 환경을 스스로 만들어 놓고선 그 폐헤를 이제 사용자에게 전가하는 것 밖에는 되지 않습니다. (물론 개발자 개개인으로 따지면 이건 불공평하게 여겨질 수 있습니다만, 사용자 입장에서는 개발자를 구분하지 않죠.)
제가 이렇게 쓰레드를 길게 물고 늘어지는 이유는 단 한가지 입니다.
이 문장을 보고 싶지 않기 때문입니다. 그냥 이러한 경우에는 utf-8을 사용하는 것이 어떻게 도움이 됩니다 정도로 해 주셨으면 하는 것입니다. 입장에 따라 euc-kr이 대세인 사람도 제가 보기에는 아직까지는 utf-8보다 많다고 생각이 됩니다.
이게 쉬워 보이기는 하는데 ...
직접 해보니 장난이 아니더군요.
대충 7, 8년전쯤, 하이텔에서 osc 동호회 자료를 정리하는데
- 다른 동호회들은 db 를 사용하는데, 케텔 초기부터 있던 몇몇 동호회 들은 text db 를 사용하여 게시물 하나마다 파일을 2개 생성(본문 파일, index 파일) 하여 저장하는 방식이었죠.
osc 동호회가 들어가 있는 메인프레임(피라미드 ...)의 자료를 일단 백업 받은 다음에, 백업 받은 걸로 테스트 삼아서 진행해 보았는데, 게시판 하나 indexing 하여 db 에 집어 넣는데, 3일 걸리더군요. - PC 나 PC 서버급이 아닌 '메인프레임'급 의 장비로 작업하는 데도 그정도 걸렸습니다. - 그것도 제대로 안되고, 중간 중간 자료 빠지고, 오류나고 ... 하면서요. 결국 일주일쯤 삽질하다가, 그냥 두기로 했었습니다. osc 가 그때 제 기억에 게시판이 30 ~ 40개가 넘었었으니 ... 게시판 하나당 일주일 잡고 ... 30개로 따지면, 거의 반년쯤 걸린다는 계산이 나오죠. 그것도 서비스 제대로 못하면서... 그러니 포기할 수 밖에는 없었습니다.
그 뒤에 계속 피라미드 시스템을 쓰고 있는지는 모르겠고, text db 를 db 로 변환시켰는지 여부는 알 수 없지만, 결코 쉬운 문제는 아니었던 걸로 기억합니다.
만일, 각 파일들의 인코딩까지 신경을 써줘야 하는 .. 거였다면 ... 히유 ...
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
convmv 쓰세요~
convmv 쓰세요~