kldp.net을 euc코드로 바꾸실 의향은 없으신가요?

ziolo의 이미지

다른 kldp 싸이트는 euc-kr인데 kldp.net만 유니코드군요.
사실 파이어폭스같은 모질라로 보는 것은 문제가 안되는데 (코드변환기능이 없는)저사양 브라우져로는 사용하기가 어렵습니다.
사실 전 dillo를 주로 쓰는데 테스트 해봤더니 kldp에 로그인 후 글쓰기까지 다 됩니다.(국내에서 유일한 것 같군요.) kldp.net만 제대로 볼 수 없습니다.
부디 저사양 브라우져들을 배려하여 kldp.net도 euc-kr로 바꿔주실 순 없나요?

File attachments: 
첨부파일 크기
Image icon kldp.net.jpg79.08 KB
Image icon kldp.png317.09 KB
Image icon dillo-utf8.jpg101.72 KB
다크슈테펜의 이미지

딜로가 유니코드를 지원하지 않는 모양이군요.
그런데 제생각에는 약간은 KLDP에 실망입니다.리눅스에서는 윈도우즈와의 호환때문에 euc-kr를 쓰는 경우는 있어도 거의 디폴트가 유니코드입니다.
그리고 파이어폭스나 다른 브라우저 같은 경우에는 euc-kr을 지원하기 때문에 리눅스 상에서도 별로 불편 없이 살았지만..
그래도 아직도 유니코드가 아니라니 약간 KLDP에 실망이군요.
물론 저사양을 사용하시는 분을 위해서는 어쩔수 없을 겁니다.하지만 모든 운영체제를 포함한다 하더라도 대다수의 리눅스 유저를 가장 우선 순위에 두어야 하는 것은 어쩔수 없을 겁니다.
그리고 한글 코드상 다국어 지원면에서도 윈도우즈도 하루빨리 유니코드로 가야 하는게 이치상 맞는 거구요..
결론적으로는 저사양유저에게는 미안한 감이 있지만 다른 사이트들도 유니코드로 통일 되는게 더 바람직하지 않을까 생각합니다.
모든 리눅스 유저를 끌기에는 너무나 많은 딜레마가 있으며 그리고 그것을 다 포함한다고 하면 발전은 오히려 더뎌 지겠지요.

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

정태영의 이미지

아...아직도 gtk1 을 쓰시는 분이;; dillo 는 아직도 개발이 되고 있었군요...

그런데 파이어폭스등을 쓰면 안되는 이유같은게 있으신건가요?

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

정태영의 이미지

다크슈테펜 wrote:
결론적으로는 저사양유저에게는 미안한 감이 있지만 다른 사이트들도 유니코드로 통일 되는게 더 바람직하지 않을까 생각합니다.
모든 리눅스 유저를 끌기에는 너무나 많은 딜레마가 있으며 그리고 그것을 다 포함한다고 하면 발전은 오히려 더뎌 지겠지요.

w3m 마저도 유니코드는 지원합니다... dillo 보다 w3m 이 더 가벼우면 가볍지 무겁지는 않을거 같군요 ;)

유니코드로 통일해야 한다는데는 저도 동의합니다 :evil::evil:

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

kall의 이미지

정태영 wrote:
w3m 마저도 유니코드는 지원합니다... dillo 보다 w3m 이 더 가벼우면 가볍지 무겁지는 않을거 같군요 ;)

어플리케이션의 문제라기 보다는..시스템의 문제가 아닐까 싶은데요.
coLinux 데비안에 램을 64메가 주고 locales를 설치했는데..
로케일 설정하는데서 euc-kr까지는 잘 되는데..utf-8 설정하다가 메모리가 모자르다면서 프로세스를 하나하나 죽이기 시작해서 locale-def(프로세스 이름이 정확히 기억이 안나는군요)이라는 프로세스까지 죽여서 패키지 설정이 실패로 끝나더군요.

결국 128로 늘리고 설정을 끝냈습니다. ;;

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

정태영의 이미지

kall wrote:
정태영 wrote:
w3m 마저도 유니코드는 지원합니다... dillo 보다 w3m 이 더 가벼우면 가볍지 무겁지는 않을거 같군요 ;)

어플리케이션의 문제라기 보다는..시스템의 문제가 아닐까 싶은데요.
coLinux 데비안에 램을 64메가 주고 locales를 설치했는데..
로케일 설정하는데서 euc-kr까지는 잘 되는데..utf-8 설정하다가 메모리가 모자르다면서 프로세스를 하나하나 죽이기 시작해서 locale-def(프로세스 이름이 정확히 기억이 안나는군요)이라는 프로세스까지 죽여서 패키지 설정이 실패로 끝나더군요.

결국 128로 늘리고 설정을 끝냈습니다. ;;

스왑 파티션을 설정하지 않으셨었나보군요 ;)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

dragonkun의 이미지

대세는 utf-8입니다..
kldp.net을 euc-kr로 바꾸는 것을 건의 하는 것보다
dillo가 계속 개발되고 있다면..
dillo의 개발자에게 utf-8을 지원하게 건의하는 것이 낫지 않을까요?

Emerging the World!

ziolo의 이미지

대세라서 유니코드 사용하자는 말씀은 말아주시길 바랍니다.

그리고 유니코드가 대세라는 증거는 없는 것 같은데요...?

한글표현에는 유니코드가 좋다는 어떤 타당한 이유가 있나요?

유니코드를 고집하는 것이 결국 우리같은 한글 사용자들의 선택의 여지를 없애는 것이라고는 생각되지 않습니까?

어쨌든 이젠 한텀에서도 유니코드 지원하나요? 아직 안하나요?

ydhoney의 이미지

1.
그럼 euc-kr에서는 선택의 여지가 좀 있나요? -_-;

2.
euc-kr vs utf-8에 대한 활발한 논의가 이루어졌던 포스트를 찾아보세요.

3.
euc-kr을 유지해서 좋은 점은 단지 이전 자료들과의 코드 호환성뿐입니다.

khris의 이미지

ziolo wrote:
대세라서 유니코드 사용하자는 말씀은 말아주시길 바랍니다.

그리고 유니코드가 대세라는 증거는 없는 것 같은데요...?

한글표현에는 유니코드가 좋다는 어떤 타당한 이유가 있나요?

유니코드를 고집하는 것이 결국 우리같은 한글 사용자들의 선택의 여지를 없애는 것이라고는 생각되지 않습니까?

어쨌든 이젠 한텀에서도 유니코드 지원하나요? 아직 안하나요?

EUC-KR은 대세인가요 그럼?
유니코드를 쓰면 한글 중문 아랍어등의 멀티바이트 문자를 훨씬 많이 표현할수있습니다.
게임 한글화할때 뼈빠지게 고생 안해도되구요.
세계 모두를 위한 유니코드입니다.

───────────────────────
yaourt -S gothick elegant
khris'log

warpdory의 이미지

현재 쓰이는 완성형 한글 그러니깐 보통 euc-kr 로 알고 쓰고 있는(정확히 둘이 일치하는 것은 아니지만... ) 인코딩은 .. 한글을 제대로 쓰고 있지 못합니다. 폐기되어야 마땅한 놈이지만 ... 과거의 데이터들이 많은 경우 저걸로 되어 있기 때문에 어쩔 수 없이 쓰는 거죠.

11000 자 이상을 표현할 수 있는 한글중 2350 자만 쓰는 것도 억울하죠.

게다가 다른나라 말과 같이 쓴다든가.. (알파벳이 아닌 걸 얘기하는 겁니다. 알파벳 조차도 ... 영어가 아닌 경우 '특수문자'를 써야 하는 경우도 많습니다.) 하는 경우에는 euc-kr ... 좌절 그 자체입니다. 없어져서 마땅한 코드지요.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

다크슈테펜의 이미지

윈도우즈 상에서 소위 문자표라고 하는 곳의 특수문자를 많이 쓰는 편입니다.
문자표에서 찍어서 그 특수문자를 컴파일하게 되면 컴파일 시도전에 유니코드로 인코딩 전환 하라는 말이 나옵니다.
그만큼 euc-kr로는 사용할수 있는 문자가 적습니다.보통 쓰는 한글을 제외하고 멀티 바이트나 아니면 특수문자를 쓸려면 euc-kr에서는 고로운 점이 많습니다.
그리고 euc-kr같은 경우에는 어느정도 처음에는 정부에 의한 선택이었지만 현재는 마소에 의한 선택이 아니던가요....?
현재 맥오에스 사용자들은 애플고딕의 유니코드 지원미비에 분노하며 애플에 호소하고 있는 마당에 구시대에 유물을 지킨다는거는 조금 아이러니라고 생각합니다.그것도 자신에 의한 선택도 아니면서..

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

정태영의 이미지

ziolo wrote:
대세라서 유니코드 사용하자는 말씀은 말아주시길 바랍니다.

그리고 유니코드가 대세라는 증거는 없는 것 같은데요...?

한글표현에는 유니코드가 좋다는 어떤 타당한 이유가 있나요?

유니코드를 고집하는 것이 결국 우리같은 한글 사용자들의 선택의 여지를 없애는 것이라고는 생각되지 않습니까?

어쨌든 이젠 한텀에서도 유니코드 지원하나요? 아직 안하나요?

유니코드를 사용할 경우
1. 완성된 글자로써 11,172 자의 글자를 표현가능합니다 (AC00 영역)
2. 첫가끝 코드로 (예전엔 직결식이란 비슷한 게 있었던 듯 합니다) 한글을 표현할 경우 검색 시에 상당히 유리해질 수 있고, 또한 옛한글을 표현하는게 가능해집니다... 그리고 세벌식과 합쳐지면 입력기 없이도 키매핑 만으로 한글을 입력하는 것도 가능하구요 :)
3. 다른 언어와 혼합해서 쓸 경우에도 불편함이 없습니다 꽁수를 쓸 필요도 없구요

euc-kr 의 경우엔
1. 특정글자를 입력하기 위한 중간 글자가 없는 경우도 있고 -_-;;
2. 지원하는 글자도 많지 않기 때문에 모든 한글을 다 표현할 수 없습니다...
3. 때문에 유니코드처럼 간단한 규칙을 가지고 조합할 수 없게 되므로 입력기가 좀 더 복잡해집니다...

uhc (확장완성형)
1. 비는 영역을 사용해서 어찌어찌 남은 글자 중 어느정도를 꾸겨넣는데 성공은 했지만... -_-!! 넣어진 코드의 순서가 가나다라 순서를 벗어나게 됩니다... 그 외에도 여러가지 문제가 있지만 관련해선 그냥 노코멘트 =3=33

그리고 한텀-xf 가 아닌 한텀 은 유니코드를 지원합니다... 하지만 출력만을 제대로 지원하고 입력기는 여전히 euc-kr 에 있는 글자들 밖엔 입력할 수 없었던 걸로 기억합니다...

한글 사용자의 선택의 여지를 없앤다기 보다 ... 한글을 제대로 사용할 수 있도록 도와준다고 보는게 맞을겁니다 :p

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

권순선의 이미지

euc-kr, unicode의 장단점에 상관없이 일단 kldp.net의 경우는 ziolo님이 utf-8을 지원하는 브라우저를 사용하시면 문제가 해결되므로 utf-8을 지원하는 브라우저를 사용하여 접속해 주세요. kldp.net을 euc-kr로 전환할 계획은 없습니다.

ziolo의 이미지

예~
이러면 재미없겠죠?( :D )
재미를 위해서...

Quote:
딜로가 유니코드를 지원하지 않는 모양이군요.

Quote:
dillo의 개발자에게 utf-8을 지원하게 건의하는 것이 낫지 않을까요?

딜로는 원래 한글 지원 안합니다. 앞으로 라이브러리를 바꿔서 유니코드를 지원할 예정이랍니다.
Quote:
w3m 마저도 유니코드는 지원합니다

w3m 써보셨나요? 딜로처럼 1개의 로케일만을 지원할 뿐이죠. 따라서 유니코드로 설정하면 euc-kr 페이지를 볼 수 없습니다. 잉카에서 euc-kr 인코딩은 설정조차 안됩니다.
Quote:
dillo 보다 w3m 이 더 가벼우면 가볍지 무겁지는 않을거 같군요

그리고 더 느립니다. 얼마 전까지 PIII를 쓰고 있었기 때문에 속도차이는 확실히 알고 있죠.
Quote:
EUC-KR은 대세인가요 그럼?

대세가 무슨 뜻인지 모르세요? 한글싸이트 대부분이 EUC-KR을 씁니다. 유니코드 쓰는 곳은 많지 않죠. 앞으로는 어떨지 모르겠지만 아직까지는 EUC-KR로 설정해 놓고 큰 어려움 없이 씁니다.
Quote:
1.
그럼 euc-kr에서는 선택의 여지가 좀 있나요? -_-;

2.
euc-kr vs utf-8에 대한 활발한 논의가 이루어졌던 포스트를 찾아보세요.

3.
euc-kr을 유지해서 좋은 점은 단지 이전 자료들과의 코드 호환성뿐입니다.


1번의 답은 3번입니다. :)
원래 제가 했던 질문은 kldp싸이트중에서 유일하게 유니코드를 쓰는 KLDP.NET을 EUC-KR로 바꾸실 의향이 있는지 물어 본 것입니다. 2번 주제가 아니였죠.

Quote:
게다가 다른나라 말과 같이 쓴다든가.. (알파벳이 아닌 걸 얘기하는 겁니다. 알파벳 조차도 ... 영어가 아닌 경우 '특수문자'를 써야 하는 경우도 많습니다.) 하는 경우에는 euc-kr ... 좌절 그 자체입니다. 없어져서 마땅한 코드지요.

위의 정태영님을 비롯하여 많은 분들이 EUC-KR과 유니코드의 차이점을 잘 정리하셨지만 제 질문을 굳이 코드문제로 생각한다면 KLDP.NET이 그런 유니코드가 꼭 필요한 다중언어 환경인가 하는 것입니다.

사실 모든 한글 싸이트가 유니코드를 쓴다면 딜로도 웹페이지 파징하기 전에 iconv로 코드 컨버젼 시켜버리면 그만입니다.(어짜피 지금도 해킹해서 쓰고있는데 뭐 :twisted: ). 하지만 1) 아직은 EUC-KR이 대세고 2) KLDP 싸이트들의 통일성을 기하고 보다 많은 사용자들이 사용할 수 있도록 하기 위해서라도 KLDP.NET의 인코딩 방식을 바꿔줬으면 합니다. (저의 단순한 바람이니까 부담가지실 필요 없습니다.ㅎㅎㅎ)

추신) 참고로 유니코드와 EUC코드의 정통성문제는 잘못알고 계신분들이 의외로 많아서 한마디 합니다. 유니코드은 마소의 오랜 물밑작업의 산물입니다. 인터넷으로 확인하시면 처음 마소와 IBM, 애플들이 유니코드 콘소시엄 형성한 것이 1991년으로 나옵니다만 윈도우95 폰트체들중 대부분이 유니코드로만 인코딩되어 있음을 안다면 마소가 95년 이전부터 유니코드를 내부적으로 사용해왔음을 알 수 있습니다. 사실 정통성으로 따지면 마소등에 의해 주도된 유니코드보다는 UNIX환경에서 유저들로부터 만들어진 EUC코드가 더 정통성이 있을 것입니다. 완성형은 정부가 마지못해 받아들인 거죠. 대세였으니까...

추신2) 여전히 KLDP에서 글 올리는 연습중입니다. 지금까지는 보기만 했었는데... 앞으로 잘 부탁 드립니다.

khris의 이미지

그 누구도 정통성 얘기는 꺼낸적이 없는데요... 현재 EUC-KR등의 멀티바이트 체계가 MS에 의해 지속되고 있단것은 자명합니다.

하위호환성때문에 버리지 못하는것이니까요.

그마저도 .net Framework 안에서는 내부적으로 유니코드로 처리합니다.

그리고 대세는 유니코드 맞습니다.

통일성을 기하고 많은 사용자들이 이용할수있도록 유니코드로 바꿔야 하는거 아닐까요?

KLDP.net 은 국내에 국한되어서는 안됩니다.

P.S. 그나저나 단순한 바램을 참 부담갖게 쓰시네요.

───────────────────────
yaourt -S gothick elegant
khris'log

정태영의 이미지

ziolo wrote:
추신) 참고로 유니코드와 EUC코드의 정통성문제는 잘못알고 계신분들이 의외로 많아서 한마디 합니다. 유니코드은 마소의 오랜 물밑작업의 산물입니다. 인터넷으로 확인하시면 처음 마소와 IBM, 애플들이 유니코드 콘소시엄 형성한 것이 1991년으로 나옵니다만 윈도우95 폰트체들중 대부분이 유니코드로만 인코딩되어 있음을 안다면 마소가 95년 이전부터 유니코드를 내부적으로 사용해왔음을 알 수 있습니다. 사실 정통성으로 따지면 마소등에 의해 주도된 유니코드보다는 UNIX환경에서 유저들로부터 만들어진 EUC코드가 더 정통성이 있을 것입니다. 완성형은 정부가 마지못해 받아들인 거죠. 대세였으니까...

추신2) 여전히 KLDP에서 글 올리는 연습중입니다. 지금까지는 보기만 했었는데... 앞으로 잘 부탁 드립니다.

w3m 관련 해서는 제가 좀 잘못 알고 있었군요 :-)

마소에서 주도했는지 안했는지 얼마나 물밑작업을 했는지 안했는지가 중요한게 아닙니다 ... 한국어만을 혹은 어떤 언어만을 지원하려는게 아닌 국제적으로 쓸 수 있는 프로그램을 만들기 위해서는 유니코드가 대세입니다...

우리나라에서 교육조차 제대로 안된 웹개발자들이 euc-kr 로 작업을 해놓았는지... utf-8 로 작업을 해놓았는지가 대세가 아니란 얘기죠 :)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

ziolo의 이미지

정태영 wrote:

마소에서 주도했는지 안했는지 얼마나 물밑작업을 했는지 안했는지가 중요한게 아닙니다 ... 한국어만을 혹은 어떤 언어만을 지원하려는게 아닌 국제적으로 쓸 수 있는 프로그램을 만들기 위해서는 유니코드가 대세입니다...

우리나라에서 교육조차 제대로 안된 웹개발자들이 euc-kr 로 작업을 해놓았는지... utf-8 로 작업을 해놓았는지가 대세가 아니란 얘기죠 :)

역시 그런가요? 저같은 사용자들의 편리성 보다는 프로그래머들의 편리성이 개발 방향의 우선이라는 논리같아 보입니다만 아니겠죠? 더 좋은 오픈소스 프로그램으로 사용자들을 기쁘게 하려는 의도로 보겠습니다.

PS) 저의 글쓰는 기술이 나날이 발전하는 것 같아 기분은 좋습니다. :D

kall의 이미지

정태영 wrote:
kall wrote:
정태영 wrote:
w3m 마저도 유니코드는 지원합니다... dillo 보다 w3m 이 더 가벼우면 가볍지 무겁지는 않을거 같군요 ;)

어플리케이션의 문제라기 보다는..시스템의 문제가 아닐까 싶은데요.
coLinux 데비안에 램을 64메가 주고 locales를 설치했는데..
로케일 설정하는데서 euc-kr까지는 잘 되는데..utf-8 설정하다가 메모리가 모자르다면서 프로세스를 하나하나 죽이기 시작해서 locale-def(프로세스 이름이 정확히 기억이 안나는군요)이라는 프로세스까지 죽여서 패키지 설정이 실패로 끝나더군요.

결국 128로 늘리고 설정을 끝냈습니다. ;;

스왑 파티션을 설정하지 않으셨었나보군요 ;)


coLinux의 경우 스왑이 메모리 설정한것과 같은 크기로 가더군요.
64잡으면 스왑도 64, 128잡으면 스왑도 128 ;;
따로 어찌 설정하는지를 몰라서..-_-;

(실지론 웬만한 구형이라도 디스크에 여유가 있으니 스왑을 늘려 잡으면 그만이겠지만)스왑을 합쳐서 128이하의 메모리를 가진 저사양 시스템에선 UTF-8설치가 안될수도있다는 얘기를 하고 싶었던 거죠. ;)

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

kall의 이미지

아직 UTF-8이 대세라기 보다는 UTF-8로의 이전이 대세겠죠..

del.icio.us나 flickr같은 서비스들이 UTF-8을 사용하면서 특별한 작업 없이 자연스럽게 한글을 쓸 수 있는 것 처럼요 :)

이런저런 이유보다, 편리하다는 면에서 UTF-8로의 이주는 좋다고 봅니다.

제 홈피도 UTF-8로 엎으려고 계획만 하고 있고..;;
(테크노라티를 사용하려니 euc-kr로는 한계가..)

----
자신을 이길 수 있는자는
무슨짓이든 할수있다..
즉..무서운 넘이란 말이지 ^-_-^
나? 아직 멀었지 ㅠㅠ

ziolo의 이미지

khris wrote:
그 누구도 정통성 얘기는 꺼낸적이 없는데요... 현재 EUC-KR등의 멀티바이트 체계가 MS에 의해 지속되고 있단것은 자명합니다.

하위호환성때문에 버리지 못하는것이니까요.

그마저도 .net Framework 안에서는 내부적으로 유니코드로 처리합니다.


MS는 모두 유니코드 아니였나요? 그리고 EUC코드의 명맥을 이어가는 것은 리눅스 아니였던가요? 지금은 리눅스도 유니코드가 대세라지만 왠지 속는 느낌입니다. 저만 그런가요?

khris wrote:

그리고 대세는 유니코드 맞습니다.

통일성을 기하고 많은 사용자들이 이용할수있도록 유니코드로 바꿔야 하는거 아닐까요?


저도 KLDP가 통일성이 있어야 한다고 생각합니다. :lol:

khris wrote:

KLDP.net 은 국내에 국한되어서는 안됩니다.

그런데 영문 소개페이지 하나 없네요.
실력만 된다면 인트로 부분은 써드리고 싶습니다만
영어 실력이 뛰어나신 분들도 많으니...

khris wrote:

P.S. 그나저나 단순한 바램을 참 부담갖게 쓰시네요.

그게 보이나요? 사실 그렇게 썼습니다. :wink:
다크슈테펜의 이미지

마소한테는 적어도 두번의 기회가 있었습니다.한글 코드를 바꾸기위해서 첫번째는 도스에서 윈도우즈로 넘어가던 시점이고 두번째는 윈도우즈 95로 넘어가던 시점입니다.그때 확장 완성때문에 그시절 소위 네티즌 들이 발끈한 일도 있었지요...만약 그때 다른 코드로 전환할수 있었으면 지금의 문제는 별로 심각하지 않았을지도 모르겠지요..
현재 마소의 운영체제는 내부적으로는 유니코드로 돌아갈지 몰라도 외부적으로는 euc-kr입니다.물론 기본 한글 코드는 선택불가입니다.물론 유니코드는 지원합니다.하지만 기본이 아니라는게 문제라면 문제 겠지요.
대세라고 말씀하셨지만 웹디자이너나 개발자들이 웹페이지를 작성했을때 유니코드인지 아니면 euc-kr인지 생각은 안 했을것이라고 생각합니다.모양을 위해서 액티브 엑스나 플래쉬로 떡칠하는 웹디자이너 프로그래머 들이 많은 이 사회에서 그깟 기본 한글 코드는 생각에는 없었다고 생각합니다.물론 여기 오시는 분들중에 웹프로그래머나 아니면 디자이너 분들도 계실겁니다.그분들은 어쩔수 없이 하셨을 것 같습니다.(먼산보기 모드)
한글 코드에서 중요한거는 지금 현재 정통성 보다는 얼마나 많은 표현이 가능한가 얼마나 많은 다른 언어와 호환성을 지니느냐 얼마나 많은 유저가 세팅없이 한글을 볼수 있느냐 그리고 다른 특수 문자나 아니면 외국어를 쓸수 있느냐 문제 인것입니다.
이 기준에 비춰보면 euc-kr은 어느 한 구석도 유니코드보다는 훌륭한 점이 없습니다.
리눅스 상에서는 이제는 다국어 언어 코드도 선택할수 있습니다.기본 시스템에서 euc-kr이냐 아니면 utf-8이냐 사용자가 알아서라는 뜻입니다.설정후에 재부팅하면 끝입니다.마소는 이런것도 없지요.
영문인트로도 중요할수 있고 그리고 정통성도 중요합니다만 얼마나 많은 사람들에게 아무런 설정없이 한글을 보여 줄수 있느냐 표현해 줄수 있느냐가 더 중요한것 같습니다.
예전에 ㅤㄸㅗㅁ방각하나 코카콜라등을 쓰지 못했을때 네티즌들은 어떻게 생각했을지 한번 생각해봐주셨으면 합니다.
PS:아까 쓰신글 중에 보니 파이어폭스 사슴공원은 쓰실수 있으신것 같은데 이런곳에는 시스템 리소스를 한번 투자 해보는 것도 좋지 않을까 생각합니다.
PS To 순선님:이번기회에 전 사이트를 유니코드로 재구성 해주시는 것은 어떨전지요...?

인생이란게 다 그런게 아니겠어요....? 뭘(?)
http://schutepen.egloos.com

lifthrasiir의 이미지

ziolo wrote:
추신) 참고로 유니코드와 EUC코드의 정통성문제는 잘못알고 계신분들이 의외로 많아서 한마디 합니다. 유니코드은 마소의 오랜 물밑작업의 산물입니다. 인터넷으로 확인하시면 처음 마소와 IBM, 애플들이 유니코드 콘소시엄 형성한 것이 1991년으로 나옵니다만 윈도우95 폰트체들중 대부분이 유니코드로만 인코딩되어 있음을 안다면 마소가 95년 이전부터 유니코드를 내부적으로 사용해왔음을 알 수 있습니다. 사실 정통성으로 따지면 마소등에 의해 주도된 유니코드보다는 UNIX환경에서 유저들로부터 만들어진 EUC코드가 더 정통성이 있을 것입니다. 완성형은 정부가 마지못해 받아들인 거죠. 대세였으니까...

먼저 유니코드와 EUC를 동일 선상에 두고 비교하는 것 자체가 의미가 없습니다. 유니코드는 문자 집합(charset)이지만 EUC는 인코딩(encoding)이니까요. 그리고 유니코드가 마소의 산물이냐 아니냐를 따지기 전에 유니코드라는 체계 자체가 모든 문자에 하나의 고유한 숫자를 붙이기 위한 것이라는 것을 기억하셔야 할 것입니다. (이렇게 해서 얻는 이점은 정통성 같은 것과 전혀 비교가 되지 않죠.) 그런 의미에서 utf-8(유니코드를 위한 인코딩)은 충분히 대세가 될 이유가 있고, 이미 대세라고 볼 수도 있습니다.

ziolo wrote:
역시 그런가요? 저같은 사용자들의 편리성 보다는 프로그래머들의 편리성이 개발 방향의 우선이라는 논리같아 보입니다만 아니겠죠? 더 좋은 오픈소스 프로그램으로 사용자들을 기쁘게 하려는 의도로 보겠습니다.

프로그래머들의 편리성과는 별 상관이 없는 것 같습니다. euc-kr(사실 cp949)을 사용하는 사이트들과 utf-8을 사용하는 사이트들이 "아무튼" 공존하기 때문에, 사용자들의 편리성을 위해서는 utf-8도 지원해야 하는 게 더 합리적이지 않을까요? :) 제 생각에는 dillo에 utf-8을 지원하게 하는 패치(해킹해서 쓰고 계시다고 했죠?)를 공개하시는 것이 더 나은 선택이 아닐까 싶네요.

조금 더 쓰려고 했는데... 비유가 잘 안 맞는 것 같아서 생략합니다.

- 토끼군

덤: 개인적으로는 KLDP BBS도 utf-8로 고치는 것이 낫다고 생각합니다. 단 cp949만을 사용할 수 있는 환경을 위해서 뭔가 wrapper 같은 게 있으면 정말로 좋겠지만, 좀 무리일 듯 하네요 :S

정태영의 이미지

ziolo wrote:
역시 그런가요? 저같은 사용자들의 편리성 보다는 프로그래머들의 편리성이 개발 방향의 우선이라는 논리같아 보입니다만 아니겠죠? 더 좋은 오픈소스 프로그램으로 사용자들을 기쁘게 하려는 의도로 보겠습니다.

프로그래머의 편리성이 개발 방향의 우선이라는 얘기가 아니었습니다 ... :)

외국에서 한국이란 나라에서 "한글" 이라는 언어를 쓴다는 점을 전혀 몰라도 유니코드 기반일 경우 "한글" 을 입출력하는데 아무런 문제가 생기지 않을 수 있습니다 :)

그렇다가 개발자 입장에서 유니코드를 지원하도록 프로그램을 만드는 데 대단한 노력이 필요한 것도 아니구요 (사실 그다지 많은 노력은 필요하지 않습니다 ... 아주 작은 몇 가지만 유의하면 되죠)

ziolo wrote:
MS는 모두 유니코드 아니였나요? 그리고 EUC코드의 명맥을 이어가는 것은 리눅스 아니였던가요? 지금은 리눅스도 유니코드가 대세라지만 왠지 속는 느낌입니다. 저만 그런가요?

windows 2000 부터 유니코드를 사용하기 시작했고, 98까지는 유니코드를 지원하지 않습니다... 노트패드에서 유니코드를 지원한 것도 윈도우 2000 부터 입니다

하지만 그래도 노트패드 등에서 파일을 저장할 때 디폴트는 euc-kr 이죠 -_-!!

ziolo wrote:
khris wrote:

KLDP.net 은 국내에 국한되어서는 안됩니다.

그런데 영문 소개페이지 하나 없네요.
실력만 된다면 인트로 부분은 써드리고 싶습니다만
영어 실력이 뛰어나신 분들도 많으니...

한글판 모질라 / 익스플로러 등을 사용하시나 보군요... 영문판을 쓰면 설명이 영어로 나옵니다... 스샷 첨부를 ;)

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

ziolo의 이미지

어떤 분이 쓰신것 처럼 과도한 리소스를 요구하기 때문에 전 EUC-KR로 씁니다.

지금은 무리없이 파폭을 돌릴 수 있는 사양이 되지만 예전에 리소스 절약하던 버릇이 남아있어서 아직도 파폭과 딜로를 같이 씁니다. 보통은 딜로를 쓰다가 글을 쓰거나 스크립트 기능이 꼭 필요할 때만 파폭을 돌리죠. (제가 알기로는 KLDP는 스크립트와 CSS없이도 게시물 읽기/쓰기가 가능한 거의 유일한 싸이트입니다.)

Quote:

한글판 모질라 / 익스플로러 등을 사용하시나 보군요... 영문판을 쓰면 설명이 영어로 나옵니다... 스샷 첨부를

딜로는 스크립트와 CSS를 지원하지 않습니다. 그래서 이런 오해가 있었군요.

Quote:

제 생각에는 dillo에 utf-8을 지원하게 하는 패치(해킹해서 쓰고 계시다고 했죠?)를 공개하시는 것이 더 나은 선택이 아닐까 싶네요.

앞서 밝혔듯이 딜로에서 유니코드 지원 부분은 라이브러리 때문입니다. 딜로는 GTK 1.x기반이기 때문에 기본이 WCHAR죠. 차기 버젼부터는 FLTK로 바꿀 예정이랍니다. 유니코드 지원을 위해서...

EUC-KR을 반대하시는 분들이 제 생각보다는 많군요. 지금 당장은 아니겠지만 언젠가는 저도 유니코드로 바꾸게 되겠죠.

원래 질문에서 많이 벗어났지만 모든 분들의 의견 잘 들었습니다.(이모티콘을 수동으로 넣는 이 번잡스러움...음:))

정태영의 이미지

ziolo wrote:
Quote:

한글판 모질라 / 익스플로러 등을 사용하시나 보군요... 영문판을 쓰면 설명이 영어로 나옵니다... 스샷 첨부를

딜로는 스크립트와 CSS를 지원하지 않습니다. 그래서 이런 오해가 있었군요.

딜로가 스크립트나 css 를 지원하지 않는건 몰랐군요... 조금 더 부연설명을 하자면 :)

헤더를 통해 넘어오는 ACCEPT_LANGUAGE(?) 정보를 이용해서 어떤 언어로 보여질지를 이미 "서버"에서 결정해서 보여주는걸로 알고 있습니다

css 도 아니고 java-script 를 이용한 것도 아니구요 :evil: :evil:

혹시나 관심 있으시면... gtk-webcore 와 osb-browser 를 빌드해보세요 ... 확실히 아직 완성품이란 느낌은 들지 않지만... 파이어폭스보다는 훨씬 가볍습니다...

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

Stand Alone Complex의 이미지

저는 혼용에 한표!

갑자기 바꾼다는건 힘들어요.

이 세상 모든 프로그램에 utf-8이 될때까지, 그리고 euc-kr을 어쩔 수 없이 써야만하는 사람들을 위해서 혼용합시다.

혼용 만세~

RET ;My life :P

김정균의 이미지

권순선 wrote:
euc-kr, unicode의 장단점에 상관없이 일단 kldp.net의 경우는 ziolo님이 utf-8을 지원하는 브라우저를 사용하시면 문제가 해결되므로 utf-8을 지원하는 브라우저를 사용하여 접속해 주세요. kldp.net을 euc-kr로 전환할 계획은 없습니다.

뭐, 저도 솔직히 kldp.net 이 utf8 인것이 마음에 들지는 않습니다. 다만 문제 제기도 귀찮아서 그냥 쓰고 있기는 하지만..

일단, 제가 겪는 불편함은, kldp.net 의 cvs 에 들어 있는 euc-kr 문서들입니다. 다 깨져서 나오기 때문에, 일일이 charset 을 맞추어 주어야 한다는 단점이 있습니다. 이런 문제를 해결할 wrapper 는 없는 것일까요?

그리고, utf8 이 대세라고 하지만, 제가 보았을 때는 선구자들에게만 대세일 뿐입니다. ms 운영체제를 사용하고 있는 사람들에게는 아직도 utf8 은 먼길일 뿐입니다.

파일 내에서 utf8 을 사용하는 것은 에디터의 도움을 받을 수도 있지만 command line 상에서의 utf8 을 해결할 길이 없으니까요.

그리고, 호환성을 상당히 무시하는데, utf8 의 그 어느 장점 보다 더 중요한 것이 euc-kr 의 호환성입니다. 이전의 것을 모두 다 버린다는 중대한 결심 없이는 쉽지 않은 문제 입니다.

일례로, people.kldp.org 의 예를 들어 보겠습니다.

people.kldp.org 의 mysql 을 4.1 로 업데이트를 하면서 경험했던 사항입니다. mysql 4.1 은 default charset 이 utf8 입니다. 하지만 people server 에서 사용하고 있는 site 들의 대부분은 euc-kr 을 사용하고 있고, 또한, euc-kr 과 utf8 을 한 db 에서 혼용하고 있는 사이트도 있습니다.

그래서 euc-kr 또는 utf8 둘 중에 하나는 set names 를 실행해 줘야 하는 문제에 봉착 합니다. 그렇다면 이 경우에는 mysql 의 default charset 을 euc-kr 로 해야 할까요? 아니면 utf8 로 할까요? 전 당연히 euc-kr 을 선택했습니다. utf8 을 기본으로 하자면 euc-kr 로 선택했을 때 보다 월등히 많은 수정을 필요로 하니까요.

더군다나 더 문제는, euc-kr 과 utf8 을 혼용한 db 입니다. 이 경우는 백업 dump 를 뜰 경우 각 table 의 문자셋을 확인해서 각각 분리를 해서 dump 를 받아야 하니까요.

제 견해로는, utf8 의 장점이 아무리 두드러지더라도, euc-kr 을 포용하지 못하는 한은 장점은 살아나지 못한다는 것입니다. 세벌식이 아무리 두벌식 보다 뛰어나다 해도, 두벌식을 넘어서지 못하는 것과 비슷하겠죠. 물론 euc-kr 과 utf8 의 경우에는 이와 비교하는 것은 무리이겠지만, euc-kr 을 그냥 버려도 된다는 식은 무리라는 것입니다.

즉, utf8 이 대세라고 생각하시는 것은 상관없으나, 다른 사람에게 utf8 을 강요하는 것은 문제가 있다고 보이는 겁니다. 하고 싶어도 못하는 사람이 더 많기 때문이죠.

저 역시 현재 까지는 utf8 보다는 euc-kr 을 선호하기는 하지만 순선님께 kldp.net 을 euc-kr 로 변경해 달라는 요청을 하지는 않습니다. 왜냐, 직접 변경해 보시면 얼마나 노가다인줄 아실 테니까요. 그러기 때문에 euc-kr 을 utf8 로 변경해야 한다는 주장 역시, 직접 해 주시기 전에는 설득력이 없다는 얘기입니다.

그냥.. 주어진 대로 사용하세요.

cjh의 이미지

몇몇 리눅스 배포본에서 X 만 사용하고 계시다면 UTF-8이 기본 로케일인지 모르겠지만 아직도 저는 그런 환경을 써본적이 없군요. (저는 어떤 플랫폼이건 ko_KR.eucKR로 살고 있습니다) -_- 기본 로케일이 UTF-8로 바뀌면 기존 문서 보거나 변환하거나 한글 파일명으로 저장된 것들을 보는게 만만한 일이 아니라서서지요.

UTF-8이 여러모로 좋고 향후 대세가 되겠지만 현재 브라우저에서 어느정도 커버 가능하므로 당분간(3-5년 이상)은 호환성을 최대한 보장하는 방식으로 갈 수밖에 없습니다. 새로 개발될 사이트에 대해서는 고려해 볼 필요는 있겠지만 특이한 요구사항이 없다면 쉽게 utf-8로 전환할 이유가 대부분의 개발자에게 존재하지 않습니다.

그리고 새로 개발될 각종 사이트의 UTF-8로 전환하는 손쉬운 방법은 다음 버전 한국어 MS 윈도우의 기본 인코딩을 UTF-8로 하면 기존 개발자들은 무슨 수를 써서든 전환할 겁니다. :)

--
익스펙토 페트로눔

차리서의 이미지

집과 연구실의 개인 데스크탑을 공히 UTF-8로 쓰고있습니다만 (젠투/그놈) 별로 불편함이 없습니다. 호스팅을 받고 있는 개인 웹 사이트도 전부 UTF-8로 되어있으며, 사용하는 데에나 작업하는 데에 아무 지장이 없습니다. 최초에 UTF-8로 넘어갈 때에는 글타래에 이미 언급된 바와 같이 기존 자료와의 호환성 문제 등으로 꽤 불편을 겪게되지만, 일단 한 번 옮겨타고나면 의외로 이런 불편은 자주 발생하지 않더군요.

다만, 몇 달 전에 연구실 웹/메일 서버를 새로 갈아엎으면서 UTF-8로 옮겨가려고 시도했다가 실패했습니다. 기술적으로나 개인적인 활용 능률 상으로나 아무런 문제가 없었지만, 저 혼자 쓰는 장비가 아니라 연구실 연구원들이 모두 사용해야하는 장비이다보니, 이들 모두에게 어느날 갑자기 UTF-8로 갈아타라는건 현실적으로 무리더군요. (서버 세팅하는 김에 연구원들의 기존 웹 사이트 자료 등등을 UTF-8로 싹 변환해줄까 하다가, 한 번 해주면 두고두고 목매게 될 것 같아서 관뒀습니다.)

정태영 wrote:
한글판 모질라 / 익스플로러 등을 사용하시나 보군요... 영문판을 쓰면 설명이 영어로 나옵니다... 스샷 첨부를 ;)

정태영 wrote:
헤더를 통해 넘어오는 ACCEPT_LANGUAGE(?) 정보를 이용해서 어떤 언어로 보여질지를 이미 "서버"에서 결정해서 보여주는걸로 알고 있습니다

css 도 아니고 java-script 를 이용한 것도 아니구요


KLDP.net에 쓰고있는 GForge의 다국어 구현이 어떻게 되어있는지는 정확히 모르겠지만, 만일 두번째 글에 쓰신 것처럼 Accept-Language 헤더를 이용하고 있다면 굳이 영문판 브라우저를 쓰지 않더라도 브라우저의 언어 설정만 ‘영어 우선’으로 바꿈으로써 영어로 볼 수 있습니다. 게다가 이런 경우에는, 오히려 영문판 브라우저를 쓰되 언어 설정을 ‘한국어 우선’으로 맞춤으로써 한국어로 나오게 할 수도 있겠죠. 이 글타래의 중요 참고인인 dillo에도 사용자 언어 설정 기능이 있는지 모르겠지만, 대부분의 브라우저에서 기본적으로 지원하는 언어 설정 기능을 존중하여 사용자가 원하는 언어로 보여주는 방식입니다. 즉, 클라이언트 측 스크립트 실행기나 CSS 렌더링 엔진이 필요한 것이 아니라 언어 설정 기능만 있으면 되는거죠. (게다가, 이 헤더는 HTTP 1.1 표준 헤더인 것으로 알고 있습니다. 만일 브라우저에 이 헤더의 내용을 사용자 임의로 설정하는 기능이 없다면 그 브라우저가 문제인 것이지 웹 사이트의 문제가 아닙니다.)

지금 제가 쓰고 있는 불여우의 언어 설정을 PHP로 읽어서 뿌려보면 다음과 같이 나옵니다:
ko-kr, ko; q=0.8, en-us; q=0.6, en-gb; q=0.4, en; q=0.2
RFC에 나와있듯이 “언어[; q=우선순위]”들이 쉼표로 나열된 형식입니다.

(간혹 브라우저 언어 설정 대신 클라이언트의 IP 주소로부터 지역 정보를 대응시켜서 다국어를 구현한 사이트도 있는데, 딱히 나쁜 방법이라고 할 수는 없겠지만 그래도 역시 조금 갸우뚱스럽긴 합니다. 예를 들어 영국에 유학간 한국인은 죽었다 깨어나도 그 사이트를 한국어로는 읽을 수 없다는 뜻이니까요.)

PS: 정태영님의 스샷은 충격입니다. 젠투 신을 곁에서 모시는 추기경으로 알고있었는데, 혹시 개종하셨습니까? :shock:

--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!

죠커의 이미지

1년 이내에 블로그를 비롯한 상당 수의 사이트들이 utf-8 기반으로 교체될 것이라고 예상합니다. 국내에서 널리 쓰이고 있는 테터 툴즈도 곧 utf-8 체계가 될 것이고 수정이나 워드프레스를 쓰는 유저들은 이미 utf-8을 쓰고 있습니다. 그리고 xml-rpc나 rest 등의 인터페이스를 제공하는 사이트들은 이미 utf-8이 대세입니다.

CN은 2년 이내에 한국 내의 대부분의 사이트가 utf-8을 쓸 수밖에 없을 것이라 예상합니다.

ziolo의 이미지

정태영 wrote:

딜로가 스크립트나 css 를 지원하지 않는건 몰랐군요... 조금 더 부연설명을 하자면 )

헤더를 통해 넘어오는 ACCEPT_LANGUAGE(?) 정보를 이용해서 어떤 언어로 보여질지를 이미 "서버"에서 결정해서 보여주는걸로 알고 있습니다

css 도 아니고 java-script 를 이용한 것도 아니구요 evil evil

혹시나 관심 있으시면... gtk-webcore 와 osb-browser 를 빌드해보세요 ... 확실히 아직 완성품이란 느낌은 들지 않지만... 파이어폭스보다는 훨씬 가볍습니다...

역시나 딜로로는 모든 스크립트, CSS, 일부 헤더정보를 제대로 처리할 수 없습니다.(확인해보니 통과더군요) 하지만 무지 빠르죠.(거의 lynx수준) 그래서 씁니다.

유니코드에서 딜로를 쓰지 못하는 것이 아닙니다. 여기 UTF8 페이지로된 KLDP.NET 스샷 올립니다.

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트
kelven의 이미지

꽤 오래 전에 이런 논의가 오갔었군요..

제가 생각하기에도 UTF-8은 지금부터라도 써 주어야 하는 charset이라고 생각합니다.

다국어 지원 홈페이지를.. 위에서 시키는대로 euc-kr 기반으로 만들다가 지압발판에 헤드스핀하는 느낌이 들어서 제맘대로 UTF-8기반으로 변경해버렸는데, 시킨데서는 그게 utf인지 uhc인지 euckr인지 구분도 안하더군요.

지금 윈도우나 임베디드 개발쪽에서도 utf8에 슬슬 관심을 가져주는것 같습니다.

요새 청소년들 휴대폰으로 문자 보내는데 'ㅤㅂㅞㄺ'같은 것도 안되면 안 쓰니까요.

'원래 가지고 있던 소스가 euckr이라서 어쩔 수 없이 쓴다. 다시 작성할 수는 없는 노릇 아닌가?' 라고 하신다면,

아파치서버에 default-charset, html헤더, 소스의 charset, db의 charset..

뿌려주는 화면(html) 등은 ultraedit같은 툴로 변환해주면 금방 끝납니다만..

문제는 db연동이겠죠..

저도 전에 phpschool에 같은 문제로 얘기를 꺼낸적이 있습니다만..

역시 호환성 때문에 섣불리 바꾸기는 힘들어하는듯 하였습니다.

그래도 mysql이 4.1로 버전업하면서 많이들 바꾸는듯 합니다.

거기서 들었던 euckr의 문제점 하나를 추가하자면,

검색시, '가나다'순일 때, 'ㅤㅂㅞㄺ', 'ㅤㄸㅗㅁ' 등 순서가 뒤죽박죽이 된다는 것이었습니다.

뭐 요즈음.. 꽤 많은 홈페이지가 utf8기반으로 재구축되고 있는것 같습니다.

Linux를 쓰면서 하면 안 될 것들
1. 데스크탑을 윈도우나 맥스럽게 꾸미지 말자.
2. 리눅스가 최고라고 떠들지 말자.
3. 윈도우 잘 쓰는 사람한테 리눅스 쓰라고 강요하지 말자.
4. 명령어 몇개 안다고 잘난체 하지 말자.
5. 리눅스니까 어렵게 쓰지 말자.

tinywolf의 이미지

각 국의 언어 코드를 제각각 다 지원하기 보다 utf8 하나만 만들면 되니까 좋은 것아닐까요?

저도 연구실 홈피 하면서 UTF-8을 꾸준히 주장해서 지금은 UTF-8로 제작되고 있지만..
처음엔 진짜 욕 많이 들었다죠..
제로보드 안된다고.. ㅡ_ㅡ;;

결국은 제로보드의 모든 파일을 UTF-8로 변환해서.. 쿨럭..

그보다는 연구실 홈피의 영어 버전과 일어 버전의 번역을 어떻게 할지가 더 걱정입니다만.. ㅡ_ㅡ;;

ㅡ_ㅡ;