한글 euc-kr , UTF8 코드 논쟁은 끝난건가요?

nonots의 이미지

얼마전이 한글날이었는데..
요즘은 컴퓨터에서 한글과 관련된 논쟁이 거의 없는 같습니다.
옛날에는.. 2 벌식, 3 벌식 논쟁.. 완성형 조합형 논쟁.. MS 완성형과 유니코드 논쟁..
..
새로 나오는 웹서버나 DB 등도 대부분 utf8 이 기본으로 세팅되는거 같습니다.
그런대도 euckr 완성형으로 된 데이타가 워낙 많다보니
이전 사이트를 최신 서버의 최신 버전으로 업데이트할 때 항상 한글 코드가
문제되곤 합니다.
..
이젠 대부분 UTF 8 로 통일이 되어 가는건가요?
이전 euckr 이 데이타나.. 설정을 utf8 로 변환하는 쌈박한 방법 있을까?
..
누가 정리좀..

바라미의 이미지

물론 UTF-8이 euc-kr 에 비해 한글의 데이터 크기가 큽니다. 한글의 경우 2바이트가 아니라 3바이트로 되니.
근데 어차피 요즘 대세는 유니코드로 가고 있고. 전세계적으로 지배적인게 아스키코드이니. 아스키코드랑 호환되는 인코딩이 UTF-8 이니 만큼..
어쩔수 없는거죠. 컴퓨터를 우리나라에서 개발했다면 모를까.

게다가 유니코드는 euc-kr 보다 더 많은 한글 표현이 가능하니, 몇몇문제점 말고는 유니코드가 더 유리하고요.(정렬문제라던지..)
임베디드 같은 곳에서는 유니코드 쓰기가 부담 스러울테니 아직 아스키코드만으로 할지 모르겠지만 PC 같은 Rich 플랫폼에서는 UTF-8로 거의 다 정착이 되가고 있네요.

그리고 변환이라.. 파일이 어떤 거냐에 따라 다르긴 한데. 변환 툴들은 다 존재합니다. 텍스트 파일 같은건 에디터에서 이미 다 UTF-8 지원하고 라이브러리들고 iconv, mbstring(php), chardet(문자셋 detect) 같은 라이브러리들이 존재하니까요.

ps. iconv 는 라이브러리뿐 아니라 명령어로도 존재합니다.

litnsio2의 이미지

2벌식 3벌식.. 이렇게 적게되면 이는 '이벌식', '삼벌식'이라고 읽어야 하지 않나요?

글로 적을 때에나 발음할 때에나 '두벌식', '세벌식'으로 하는게 맞지 않을까 합니다.

nulluser의 이미지

차 2대가... 빵 2개를... 을 차 이대, 빵 이개라고 읽지는 않습니다.

다콘의 이미지

하지만 2벌식, 3벌식이라고 적으면
이벌식, 삼벌식이라고 읽는 사람은 많습니다.

이거 딴지가 되어 버렸군요. -.-;;

hongminhee의 이미지

가끔 “여섯 개”, “6개”라고 써야할 것을 “6섯개”라고 쓴다거나… 하는 사람도 있더군요. ㅋㅋㅋ

ktd2004의 이미지

UTF8로 가는게 대세고 정답이긴 한데...
현실이 그렇게 만들지 못하네요.. ^^;

nonots의 이미지

이전에는.. 어떤 쪽이 옳다.. 혹은 타당하다.. 현명하다.. 등으로
한쪽 사용을 주장하고 유도하는 글들이 있었던거 같은데..
..
유니코드는 ... 앞으로 이렇게 쓰자..라고 주장하거나.. 설득하려는 글들이
별로 없네요..
..
반강제적으로 유도하는 흐름이 있다면..
혼란이 일찍 끝날거 같은데..

=== 건달의 경지를 꿈꾸며 ===


=== 건달의 경지를 꿈꾸며 ===

madman93의 이미지

euc-kr을 버렸으면 좋겠습니다.

---------------------------------------------
svn + trac + my project --> success ???
---------------------------------------------

---------------------------------------------
git init
git add .
git commit -am "project init"
---------------------------------------------

eungkyu의 이미지

개인적으로 EUC-KR 대신에 유니코드로 간 것은 당연히 잘 된 일이라고 생각합니다..
그런데 gtk나 기타 라이브러리에서 내부적으로 다루는 것이 UTF-8로 된 것은 조금 아쉬운 일이라고 생각합니다.
UCS-2나 UCS-4로 프로그래밍하고 필요할 때만 (예를 들어 I/O) UTF-8로 변환해서 사용하는 것이
우리에게는 좀 더 나은 선택이 아니었나 합니다.

아무래도 UTF-8은 가변 길이 인코딩이라서 스트링을 다룰때 좀 불편하죠...
UTF-8의 장점은 US-ASCII와의 호환성이 있다는 것인데 그것때문에 tradeoff된 것 같습니다.

wchar_t의 위치가 애매해지면서 많이 쓰지지 못하게 된 것이 정말 아쉽네요.

academic의 이미지

동감입니다. us-ascii와의 호환 때문에 포기해야 하는 것이 많아 조금 안타깝다는 느낌이 듭니다.

--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

winchild의 이미지

근데 글로발화에 추진하는데 막히지 않으려면 UTF-8 이 되어야 하겠지요.

사실 한군데만 바꿔주면 되는데... 바로 M$
근데 한글의 우수성을 잘알고 있는 M$ 가 의도적으로 안바꾸고, 지역적으로 고립시킨다는 카더라 음모론도 있습니다.

- 겨울아찌 -
winchild@kldp.org

- 겨울아찌 -
winchild@gmail.com

academic의 이미지

MS도 유니코드 채택하지 않았나요?
--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

imyejin의 이미지

아직까지 인터페이스나 바깥에 보이는 부분은 CP949가 기본이지 않나요?
그리고 윈도우즈에서 유니코드일 경우 텍스트 파일 맨 앞에다 이상한 바이트 넣는 거 맘에 안들더군요 -_-

리눅스는 배포판 한국어 기본이 확실히 UTF-8이 대세가 된 것 같습니다.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

송효진의 이미지

윈도의 함수들을 보면 뒤에 A 가 붙는것과 W 가 붙는것이 있습니다.
기존 98에서 쓰던 함수들은 기존이름 그대로 유지한 채 A 붙는 함수명으로 알리아스 되어있고,
유니코드 쓰는 함수가 W 가 붙어서 새로 만들어져 있습니다.
그러니까 그냥 하위호환성인거죠.

인자는 WideString(BSTR ?) 이나 PWideChar 같은 UCS-2 문자열이 이용됩니다.
(C++ 에서는 용어가 델파이랑 좀 다르더군요.)

ex)
CreateFile -> CreateFileA
CreateFileW

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

Necromancer의 이미지

데탑, 서버용 윈도우의 경우 윈도우 창이나 메시지 등등 화면에 표시되는 주요 부분은 cp949이고, CE는 ucs-2입니다.

아마도 하위호환성 때문에 바뀌기 힘들 듯 하네요. ms가 대모험(?) 한판 하지 않는 이상은

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

dg의 이미지

데탑, 서버용 윈도우에서도 윈도우 창이나 메시지 다 유니코드로 출력할수 있어요.. (nt 계열에서는요..)
윗분 말대로 A로 끝나는 함수와 W로 끝나는 함수 2벌이 있어서 하위 호환성을 유지합니다.

Fe.head의 이미지

유니코드에 조합형 형식으로 들어갔으면 하는 바람이었는데.

완성형 형식으로 들어갔지요?
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.

고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"

dg의 이미지

원래 완성형으로 들어갔는데 나중에 첫가끝 코드가 추가돼서 이제는 조합형으로도 쓸수 있습니다. Mac OS X 에서 그렇게 사용하고 있지요.

Prentice의 이미지

유니코드 음절 영역의 한글은 완성형이지만 조합형이기도 합니다.

hayarobi의 이미지

코드로 쓰자면
0x1100 부터 시작하는 영역은 조합형 형태의 한글자모이고
0x3131 부터 시작하는 영역이 단일 표시용 한글 자모 영역입니다.

=================
잠못자는 한솔아빠

=================
잠못자는 한솔아빠

M.W.Park의 이미지

개인적으로는 쓰기로 선언한 인코딩이나 제대로 써줬으면 좋겠습니다.
무슨 말이냐면...
제가 요즘 하는 일이 XML을 많이 다루는 일인데 실제로는 EUC-KR이 아니면서 XML 선언부에 EUC-KR로 선언된 문서가 있어서 곤혹을 치른 경우가 있습니다.
실제로는 CP949를 사용하면서 EUC-KR로 선언해놓으면, MS Windows 쪽에서는 별 문제없이 도는 것같은데, 리눅스에서 iconv같은 것을 사용해 변환시 제대로 안되는 경우가 있습니다.
얼마전부터 생긴 아파트 브랜드화(삼송 래미안이 처음이였던 것으로 기억합니다) 이후에 저를 힘들게 한 놈은 바로....

포스코 더샾

"샾"의 경우 예전 문서들 처리시는 주소필드에 거의 나오지 않는 문자라 iconv에서 오류나는 문서가 거의 없었는데,
요즘은 저기서 사는 사람들이 제법 되더군요. 잘돌던 놈이 몇년도 이후부터는 에러가 나는 황당한 상황이... Orz.
아파트 브랜드화가 아파트 가격상승으로 일정부분 저에게 영향(절망?)을 준 것은 알고 있었지만, 추적하기 힘든 버그도 만들어 낼줄이야... --;
여튼 euc-kr로 들어온 놈을 cp949로 강제로 바꾸는 것으로 해결하긴 했지만 좀 찜찜하더군요.
원천 XML 문서를 만든 사람이 제대로 만들었으면 제 모듈도 원래의 깨끗함을 유지하고 찜찜한 생각도 안들고 모두가 행복했을 것을 여럿 고생시키는 것같아서 안타깝더군요.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

ktd2004의 이미지

euc-kr과 cp949의 차이점에 대해서 좀 더 자세히 설명해 주실 수 있으신지요?
(저는 거의 차이가 없다고 생각하고 사용하고 있었거든요 ^^)

M.W.Park의 이미지

cp949 >= euc-kr 로 알고있습니다.
cp949는 MS 쪽의 확장완성형, euc-kr은 euc 쪽(unix 진영이었던가?)의 인코딩일겁니다.
대부분의 경우는 별 차이 없이 쓰입니다만,
저의 경우 iconv에서 "샾"같은 글자가 euc-kr로는 처리가 안된 케이스입니다.

어떤 글자들이 해당 범위에 들어가는지는 잘 모르겠군요. ^^;
구글링을 추천합니다.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

imyejin의 이미지

간단하게는 cp949가 euc-kr보다 글자수가 많아요.

그나저나 인코딩 얘기 나오니 한글 유즈넷 시절이 그립습니다.
예전이라면 이런 내용을 강경수님같은 분께서 정리하셔서 han.answers 에 정기적으로 포스팅하셨을텐데요 :-)
지금은 구글질을 통해 이렇게 찾아야 합니다. http://www.filewatcher.com/p/stable.tar.gz.12512211/perl-5.8.7/README.ko.html
웹이 편하긴 한데 같은 질문과 정보가 여러 곳에 너무 중복되어서 오히려 기본적인 정보를 찾기가 어려워진 것 같습니다.
이 문제를 뉴스그룹을 쓰던 분들은 불편하게 느끼는데 웹부터 사용한 분들은 당연한 것으로 보기 때문에 어떤 식으로 해결해야 할지 모르겠네요.
영어권에선 그래도 gmane 때문에 메일링 리스트의 형태로 뉴스그룹이 남아있다고 볼 수 있는데 ... (우리나라는 지식KIN -_- ???)

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

Necromancer의 이미지

euckr은 현대 한글에서 가능한 조합인 11172자 중 많이 쓰는 2350자만 코드로 정의해 놓았습니다. (ks-c-5601-1987 완성형)
하지만 '똠방각하' 같이 2350자로 쓸 수 없는 단어들이 나오니까 ms에서 기존 euckr 코드를 그대로 둔 채로 나머지를 빈 영역에 우겨넣은게 cp949고요. 그래서 2350자를 벗어나는 샾 같은 글자는 cp949는 받아주지만 euckr은 문제 생깁니다.

이거 나왔을때 사람들은 욕 무지 많이 했지만, ms도 어쩔 수 없었죠. 특수한 사람이 아닌 모든 사람이 쓰는 범용 프로그램이니 당시 표준코드였던 euckr도 준수하면서 안되는 문자들까지 다 되도록 해야 되니까요. 그때 유니코드는 쓰는곳도 별로 없었고.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

zz181321의 이미지

윈도 95 나왔을 당시에 식자들이 윈도의 한글 방식에 대해서 비난 하던게 생각 나는군요.

그때의 유산이 여지껏 남아서 우리를 골치아프게 하고 있다니 말이죠...

송효진의 이미지

ksc 표준은 말 그대로 한국에서 정한것이지 ms 가 한게 아닌데도 욕은 ms 가 먹지요.ㅎㅎ

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

molla의 이미지

사람들이 욕하는 것은 euc-kr 로 알려진 표준 방식이 아닙니다. 물론 그 인코딩도 욕하긴 합니다만, CP949와는 다른 이유로 욕을 합니다.

euc-kr 은 ISO 표준을 따른답시고 글자수 제한을 매우 심하게 했습니다.
조합형이 좋다는 것을 알고는 있었습니다만, ISO 표준에 어긋나는 부분들이 있어 포기를 하고 완성형으로 간 것이었습니다.

그런데 M$는 지멋대로 완성형을 또다시 바꿔 CP949라는 이상한 표준을 내 놓았지요.
그전까지는 사람들이 완성형이 구리니 제발 조합형으로 가 달라는 요구를 했었고, M$에서도 적극 반영하겠다고 하고는 맨 마지막에 저런 웃기는 코드를 들고나오면서 사람들 뒤통수를 제대로 쳤습니다.

CP949 가 무엇이 문제인가 하면.
가장 중요한 것이 소팅이 안 된다는 것입니다.
완성형이나 조합형 등은 모두 별다른 코드 변환 없이 크기 비교만으로 소팅이 가능합니다만, CP949는 euc-kr 완성형 코드에 없는 글자들을 엄한 곳에 배치하므로서 소팅이 불가능한 (조합형으로 바꾸고 나서 소팅하면 되긴 합니다만... ... ... 뷁) 웃기는 코드를 만들어냈지요.
그 외에도 euc-kr 에 없는 글자도 표시할 수 있다는 점을 제외하고는, 완성형의 문제점들을 고스란히 물려받았습니다. (예를들면 글자 입력시 조합을 위해서는 조합형 방식이 필요합니다. 조합형 방식으로 조합을 완성하면 해당 글자를 완성형 테이블에서 다시 찾아 완성형 코드로 바꿉니다. 뷁.)

sangu의 이미지

molla wrote:
euc-kr 은 ISO 표준을 따른답시고 글자수 제한을 매우 심하게 했습니다.
조합형이 좋다는 것을 알고는 있었습니다만, ISO 표준에 어긋나는 부분들이 있어 포기를 하고 완성형으로 간 것이었습니다.

이때는 대부분 조합형 코드를 사용하고 있었으므로 완성형 보다는 조합형을 지지하는 분위기였고, 쉽게 표준화가 이뤄질 수도 있는 상황이었지만 결국 표준화는 실패하게 된다. 다름 아닌 업체마다 자신의 코드를 중심으로 표준화를 시도하다 보니 아무런 결말도 나지 않았던 것이다.

[...]

우여곡절 끝에 1987년 완성형을 표준으로 하는 KSC5601-1987(혹은 KS완성형 코드)이 제정되었지만 당시 관련 업체에서는 바로 이 코드를 사용하지는 않았다. 즉 상당수의 업체가 계속해서 자신들이 고안한 조합형을 사용했었는데 어떤 계기로 인해 KS완성형 코드가 국내 컴퓨터 산업에 자리를 잡게 된다. 그것은 바로 국가에서 주도한 행정 전산망 사업에서 KS완성형을 기본 코드로 채택한 사건 때문! 게다가 뒤이은 교육용 컴퓨터 보급 사업에서는 행정 전산망과 호환되는 코드를 사용한다는 원칙이 제시되면서부터 본격적으로 KS완성형 코드가 보급되었다. 더욱이 개인용 컴퓨터의 운영프로그램인 DOS의 제작사였던 마이크로소프트(이하 MS)가 1989년에 이르러서는 조합형을 포기하고 KS완성형을 지원하였으며, 중대형 컴퓨터의 운영체제인 유닉스 진영에서도 KS완성형을 공식적으로 지원하면서 KS완성형은 사실상 표준으로 확고한 입지를 다지게 되었다.
여기서 간과해서는 안될 중요한 사실이 있다. 현재 한국은 물론 전 세계적으로 개인용 컴퓨터 운영 프로그램 시장에서 막대한 시장 점유율을 자랑하는 MS는 그 당시 조합형을 기본으로 사용하고 있었는데, 국가적 표준 코드(완성형) 보급 정책과 맞물려 조합형을 포기하게 되었다는 점이다.

molla wrote:
그런데 M$는 지멋대로 완성형을 또다시 바꿔 CP949라는 이상한 표준을 내 놓았지요.
그전까지는 사람들이 완성형이 구리니 제발 조합형으로 가 달라는 요구를 했었고, M$에서도 적극 반영하겠다고 하고는 맨 마지막에 저런 웃기는 코드를 들고나오면서 사람들 뒤통수를 제대로 쳤습니다.

당시 MS가 발표한 내용
"MS는 1992년 조합형 발표 이후 모든 한글을 포함하는 조합형(KSC5601-1992)을 지원하기 위해서 내부적으로 많은 노력을 해왔으나, 기존의 완성형만을 지원하는 대부분의 프로그램과 자료 데이터와의 심각한 호환성 문제가 항상 걸림돌이 되어 왔다. 이에 MS는 기존의 프로그램 및 데이터와의 호환성을 유지하면서 모든 한글을 지원하는 데 가장 바람직한 방법은 완성형(KSC5601-1987) 코드를 그대로 두고, 나머지 한글을 남아 있는 DBCS(Double Byte Character Set) 영역으로 확장하는 방법이라고 보고 확장 완성형 코드를 개발하였다"

-------------------------------------------------------------
마이크로 소프트웨어 1998년 11월호 P 216~218 부분 인용

molla의 이미지

제 국어실력이 딸려서 정확히 하고자하시는 주장을 제가 제대로 이해했는지 잘 모르겠네요. ^^;
제가 이해하기론, 1. 결국 완성형이 표준화가 된 것은 조합형이 여러가지 표준이 나와 서로 싸우기만 하고 하나로 일치하지 못했기 때문이다. 그리고 MS는 조합형을 지원했지만 국가에서 완성형을 주장해서 어쩔수 없이 조합형을 버렸다. (결국 MS는 잘못이 없다?)
2. 위와 마찬가지로 MS는 조합형을 지원하고자 했지만 기존 프로그램들이 완성형만을 지원해 어쩔 수 없이 완성형을 확장한 코드를 만들었다. (역시 이것도 MS 잘못은 아니다?)

예 약간은 공격적인(?) 응답이 된 것은, 일단 제가 쓰려했던 글은 (제가 표현을 잘 못해서 잘못 이해하기 쉽게 썼을진 모르겠습니다만) 송효진 님의 표준은 국가가 정했는데 욕은 MS가 먹는다에 대한 답글이었습니다.
MS가 욕을 먹는건 표준 한글 코드 때문이 아니라, MS가 지멋대로 만들어낸 표준도 아닌 변태같은 CP949를 만들어 지멋대로 사용했기 때문이다. 라는 것이 요지였습니다. 뭐 그걸 설명하는 과정에서 코드 역사(?) 에 대한 제 기억에 기반한 글들이 들어갔고, 그곳에 기억에 의존하다 보니 어느정도 잘못된 내용도 들어갈 수 있긴 했습니다만...

일단 sangu 님이 반박(?)하신 내용들에 대해서는...
1. 완성형이 표준이 된 것에 대해서는 (뭐 벌써 20년도 넘은 옛날 일인지라 자료가 정말 없군요... 쩝) 이준희씨, 정내권씨가 쓴 "컴퓨터속의 한글" 이라는 91년에 정보시대에서 나온 책의 내용을 요약해 보겠습니다.
3.3장 (82페이지)의 내용을 보면,
"따라서 당시의 일반적인 분위기는 조합형으로 기울었다고 볼 수 있는데, 이러한 경향에도 불구하고 표준 코드가 완성형으로 제정된 것은 국제표준화기구(ISO) 에서 정한 국제 규격과의 호환성 문제 때문이다.
...
그런데 당시 표준 연구소의 연구 결과로는 2바이트 조합형 시안이 ISO-2022에 명기된 부호확장법을 따를 수 없고, 한자를 3000자밖에 넣을 수 없으며, 통신에서 사용되는 제어문자인 XON/XOFF 와 충돌하는 것으로 보고되었다. 이러한 상황에서는 당연히 완성형 시안 쪽으로 결론이 날 수밖에 없었을 것이다."

라는 내용이 있습니다. 조합형이 표준에서 밀린 것이, 조합형의 표준이 정해지지 못했기 때문 만은 아니라는 것이지요.

2. M$도 원래는 조합형을 지지했지만 국가 표준 때문에 어쩔 수 없이 완성형으로 갔는지 어떤지는 저도 정확히 모르겠습니다. 뭐 원체 오래된 이야기이고 그땐 저도 어린 학생이었으니 속사정은 정확히 알 수 없었겠죠.
뭐 해당 내용들을 찾아보면. "표준은 완성형으로 정해졌지만, 사실상 사람들이 사용하는 표준은 조합형이었다. 하지만 이게 결국 MS의 dos와 windows 때문에 결국 무너졌다." 라는 내용들은 있습니다. 하지만 이것 때문에 MS를 욕하기는 부족합니다. (MS가 완성형을 만든건 아니니까요)

M$가 욕을 먹어야 하는 것은 완성형을 지원했다는 것이 아니라, 표준도 아닌 이상한 변태같은 CP949를 만들어 사용했다는 것입니다. 그에 대한 내용들을 찾다 보니 나온 내용들 입니다.
http://blog.thesalt.net/22
http://jkjjang825.tistory.com/22
뭐 요약하자면, windows 95에서 M$가 CP949 를 만들어 사용하겠다고 했고, 이에 사람들이 문제점을 들먹이며 난리를 치고 정부에서는 수입규제를 하겠다고까지 했습니다. 결국 M$가 한발 물러나 CP949를 버리고 그냥 완성형으로 가게다고 발표했지만, 정작 뚜껑을 열어보니 CP949를 그대로 쓰고 있었습니다. 이에 사람들이 불매운동까지 벌이고 했지만... 뭐 결국 흐지부지 넘어가 아직까지도 사용되고 있습니다.

제가 하고자 하는 이야기는. 계속 이야기가 나왔지만, M$가 변태같은 CP949라는 코드를 만들어 사용했기 때문에 M$가 욕을 먹어야 한다는 것입니다.

wkpark의 이미지

사실 euc-kr에서도 2350개 이외의 글자를 쓸 수 있습니다. KS X 1001 부록 3에 규정되어있는데
2바이트로 표현하는게 아니라 8바이트 (첫 2byte는 '한글 채움', 연이어 6byte는 한글 자모 3개)로 표현됩니다.

모질라에서도 지원하며, 한텀(한텀-xf말고)에서도 지원합니다. (이른바 고정폭 조합방식)

이것을 M$가 지원하도록 했다면 상황이 많이 달라졌을지도 모릅니다.

현 유니코드의 첫가끝은 가변폭 조합방식입니다. 2바이트 조합형과도 다르고, KS X 1001 부록 3에 규정된 고정폭 조합방식과도 다릅니다.

온갖 참된 삶은 만남이다 --Martin Buber

perky의 이미지

파이썬도 2.6부터 지원합니다. :)

You need Python

zepinos의 이미지

윈도우즈에서 파일명은 cp949 로 되어 있지 않나요?

UTF-8 로 된 리눅스 머신에서 도는 장비에서 UTF-8 로 작성된 페이지를 통해 form 전송으로 파일을 올릴 경우 리눅스에 CP949(ko_KR.eucKR)로 봐야 제대로 보이는 것 같던데요...

한글...컴퓨터 자판 칠 때 무지 좋은 언어지만...내부 처리는 참 어렵습니다...

송효진의 이미지

ucs-2 입니다.
form multipart/form-data 는 현재페이지의 인코딩을 따라갑니다. 다른 문제가 있을것 같네요.
ftp 는 서버나 클라이언트나 utf-8 지원하는게 거의 없는게 문제고 (지원되는거면 잘 되죠.)
mount 라면 iocharset 만 잘 해주면 됩니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

wish의 이미지

윈도우즈의 파일명이 ucs-2로 인코딩 되어 있다면, 마운팅 옵션에 iocharset은 왜 필요한거죠?

송효진의 이미지

자신의 환경에 맞추기 위해 필요하죠.
LANG=ko_KR.UCS-2 로 쓰지는 않으니까요.
/dev/sdb1 /mnt/calmee vfat noauto,iocharset=utf8,dmask=0000,fmask=1111 0 0

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

serikas의 이미지

MS가 유니코드를 방해한다는 인식들이 있으신데요,

MS가 뒤늦게 유니코드를 채택한 것이 아니라 NT는 첫 버전인 3.1부터 내부 텍스트 처리가 유니코드로 되어있습니다. 윈도우만큼 유니코드를 적극적으로 밀어준 OS가 없을 겁니다. 유니코드 지원이 처음부터 UCS-2 였는가는 확실하지 않습니다만.

imyejin의 이미지

끄래도 한글 윈도우즈에서는 메모장 열고 한글로 치고 저장하면 기본적으로 인코딩이 cp949였고 커맨드 라인도 마찬가지였죠. 내부가 바뀌어도 애플리케이션 사용자 입장에서는 그대로 죽 cp949 인겁니다.

그리고 마이크로소프트의 국제화 패키징은 상식에 어긋날 만큼 비효율적이고 엉뚱했습니다. 리눅스나 맥은 기본적으로 동일한 배포판에서 로케일만 바꾸면 되는건데, 윈도우즈 같은 경우는 같은 버전이라도 국가별로 CD를 제각각 양산하고 각각이 미묘하게 다릅니다. 로케일만 바꾼다고 똑같은 설정이 나오지도 않고 말이죠. 비스타부터는 안써봐서 어떻게 되었는지 모르겠네요.

임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

academic의 이미지

동감입니다.

아웃룩 2003 같은 경우는 영문판과 한글판이 아예 데이터 DB 구조부터 달랐죠.

실제적으론 완전히 별개의 프로그램이나 마찬가지였다고 할까요?

--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

김정균의 이미지

논쟁을 할 필요가 있나요? 상황에 맞게 사용하면 그 뿐이라 생각합니다.

klutzy의 이미지

UCS-2랑 UTF-16이 혼용되어 쓰이네요. 둘은 다른 인코딩입니다. 정확히 말하면 UCS-2는 유니코드 전체를 표현할 수 없는, "obsolete"된 인코딩입니다. UCS는 고정길이 인코딩이라서 특정 범위(BMP)를 넘어가는 글자는 표현하지 못합니다.

윈도에서 쓰는 유니코드 인코딩도 UCS-2가 아니라 UTF-16이에요. 이 둘의 차이는 글자 수로 따지면 euc-kr과 cp949의 차이보다도 더 큽니다. >:)