소스코드를 유니코드로 작성하시니까?

ktd2004의 이미지
ktd2004의 이미지

대세는 유니코드라고 생각하고 있습니다만 실무에 소스코드를 유니코드로 작성하는게 어렵더군요.

윈도우/리눅스 모든 분야의 프래그램 작업을 통틀어서 소스코드를 유니코드로 작성하시는 분이 얼마나 되시나요?

송효진의 이미지

환경 자체가 UTF-8 이라 그냥 작성하면 UTF-8 입니다. 8)

리눅스는 LOCALE ko_KR.UTF-8 이면 그냥 UTF-8 이니 넘어가고,
윈도에선 드림위버, EmEditor 쓰면
디폴트 UTF-8 쓰는데 아무 불편함이 없습니다.

htna의 이미지

굳이 소스를 unicode로 작성할 필요를 느끼지 않습니다.
어짜피 프로그램이 알파벳으로 이루어져있는데..
unicode의 필요성이 있는지가 더 의심스럽습니다.

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

rainmon의 이미지

지금 진행하고 있는 모든 프로젝트가 utf-8이에요..

서지훈의 이미지

굳이 이렇게 까진 ...
필요한 경우는 iconv로 변경 해서 사용하고 있습니다.

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

서지훈의 이미지

htna wrote:
굳이 소스를 unicode로 작성할 필요를 느끼지 않습니다.
어짜피 프로그램이 알파벳으로 이루어져있는데..
unicode의 필요성이 있는지가 더 의심스럽습니다.

개발에 소스만 있는게 아니라 관련 문서...
그리고 주석도 있으니 이 부분의 필요성을 느끼시는 분들도 계신거죠.
C소스만 사용 한다면 굳이 필요 없겠지만...
다른 언어라면 희박하게 필요한 경우도...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

ktd2004의 이미지

제가 이문제를 고민한 이유는 그냥 소스코드(주석포함)를 작성할 경우에는 유니코드를 사용하지 않아도 전혀 문제가 되지 않았습니다. 리눅스나 윈도우에서 작업하는 저희팀의 모든 개발자들이 그냥 편한 에디터 써서 개발하면 되니까요.

그런데 TortoiseSVN이나 Trac같은 오픈소스 프로젝트들을 도입하면서 소스 코드가 유니코드가 아닌 경우에 가끔 문제가 발생합니다.(파일이 깨져보이는 것 같은 문제들이요)

그렇다고 유니코드를 사용하게 되면 기존에 유니코드에 대해 고민하지 않았던 개발자들이 편집툴을 바꾸어야 하는 것 같은 부하가 걸려버리니까요.

그래서

1. 실무에서 유니코드를 사용하시는지?
2. 왜 유니코드를 사용하게 되었는지?
3. 유니코드를 사용하면서 장점과 단점은?

이 궁금해서 글을 올리게되었습니다.
chadr의 이미지

저는 "필요한곳에 사용"입니다.

문자열을 네트워크로 전송하거나 단지 구분자나 이름과 같은 곳에는 멀티바이트를 사용하지만.. 사용자 문자열을 입력받아서 실제로 화면상에 보여져야 하는 곳은 나중에 다국어 지원을 위해서 유니코드로 작성합니다.(네트워크상에서 유니코드를 사용하지 않는 이유는 os마다 지원하는 유니코드 인코딩이 다른 것도 한 몫하지만요. :( )

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.

vacancy의 이미지

.. 다 영어입니다.

neosphere의 이미지

utf-8 사용합니다. 윈도우와 리눅스에서 eclipse 로 작업하다가 한번 왕창깨졌습니다. 그래서 그 다음부터 utf-8 으로 전부 번경했습니다. 그 이후부터는 별다른 문제점을 느끼지 못했습니다.

Gentoo. Bioinformatics, Protein Interaction.

htna의 이미지

제가
"unicode의 필요성이 있는지가 더 의심스럽습니다."
라고 글을 올린 이유는...
주석을 한글로 처리할 필요를 느끼지 못하기 때문입니다.
어느정도 간단한 주석의 경우에는 차라리 영어로 처리하는게 편하구요..
( 한영자판 누르는게 귀찮아서.. ^^;; )
주석이 간단하지 않을경우에는 소스에 주석을 넣는게 어려워집니다.
( 경우에따라 흐름도, 호출도, 함수생성배경, 혹은 수식자체가 필요하기 때문에...
간단한 설명형 주석은 이런경우에 너무 불편하고, 나중에 소스분석시에
더 어지러워지는 경우가 종종 있지 않나요??
내가 왜 이런말을 적었지..? 하고 내 가 작성한 한글암호(주석)을 다시 해석해야 하는 경우가...)

차라리...
vacancy님의 ".. 다 영어입니다." 가 더욱 정확한 말이네요...

저는 주석(보다는 설명 자체가)이 필요한 경우에,
소스에 주석을 달지 않고...
프로젝트에 차라리 워드화일을 넣습니다.

PS:
머 항상 그런다는 건 아니지만, 가능하면 주석을 적게...
필요하면 워드등 다른 표현수단을 이용하려는...
생각만인지는 모르겠지만요...

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

송효진의 이미지

Quote:
1. 실무에서 유니코드를 사용하시는지?
2. 왜 유니코드를 사용하게 되었는지?
3. 유니코드를 사용하면서 장점과 단점은?

1. 예.
2. 2바이트문자를 글자단위로 작업하기가 힘들었습니다.
MySQL 에서 LIKE %한글자% 가 정상동작 하지 않으며,
grep 한글자 * 가 정상동작 하지 않고,
perl -pi -e "s/([가-힣]+)/'\1'/g" * 가 동작하지 않았습니다.
UTF-8 에서는 이 모든게 가능합니다.
xml 처럼 아예 UTF-8 이 표준인것이 있고,
UTF-8 을 지원하지만,
CP949 를 지원하지 않는 소프트가 있고,
앞으로 개발되는 소프트들도 한글을 지원하지 않더라도
UTF-8 만큼은 지원할 것입니다.
3. 2에 열거한 것이 장점이고, 단점은 없습니다.

nainu의 이미지

그냥 "주석을 영어로 달면 되지 않느냐" 로 해결될 내용의 토론은 아닌 것 같습니다.

저는 웹프로젝트는 euckr로, 나머지는 전부 utf8로 커밋해 두었습니다..
html 파일에서 utf8로 출력하면 IE가 오동작을 할 때가 있더군요.;

송효진의 이미지

nainu wrote:
html 파일에서 utf8로 출력하면 IE가 오동작을 할 때가 있더군요.

100% header & meta 문제 입니다.
nainu의 이미지

송효진 wrote:
nainu wrote:
html 파일에서 utf8로 출력하면 IE가 오동작을 할 때가 있더군요.

100% header & meta 문제 입니다.

고맙습니다. (_ _)

서지훈의 이미지

htna wrote:
제가
"unicode의 필요성이 있는지가 더 의심스럽습니다."
라고 글을 올린 이유는...
주석을 한글로 처리할 필요를 느끼지 못하기 때문입니다.
어느정도 간단한 주석의 경우에는 차라리 영어로 처리하는게 편하구요..
( 한영자판 누르는게 귀찮아서.. ^^;; )
주석이 간단하지 않을경우에는 소스에 주석을 넣는게 어려워집니다.
( 경우에따라 흐름도, 호출도, 함수생성배경, 혹은 수식자체가 필요하기 때문에...
간단한 설명형 주석은 이런경우에 너무 불편하고, 나중에 소스분석시에
더 어지러워지는 경우가 종종 있지 않나요??
내가 왜 이런말을 적었지..? 하고 내 가 작성한 한글암호(주석)을 다시 해석해야 하는 경우가...)

차라리...
vacancy님의 ".. 다 영어입니다." 가 더욱 정확한 말이네요...

저는 주석(보다는 설명 자체가)이 필요한 경우에,
소스에 주석을 달지 않고...
프로젝트에 차라리 워드화일을 넣습니다.

PS:
머 항상 그런다는 건 아니지만, 가능하면 주석을 적게...
필요하면 워드등 다른 표현수단을 이용하려는...
생각만인지는 모르겠지만요...


영어를 다 영어로 하자고 한다면...
어느 정도의 영어 교육이 필요하지 않을지 ?
읽기와 작문을 위해...
설마... 모든 프로그래머가 이거 다 되는건 아니겠죠 ?

그리고, 전 소스에 주석은 풍부 할수록 좋다고 생각을 합니다.
언제 다시 볼때도 주석 없는 코드보다 있는 코드가 조금이라도 이해가 쉽잖아요.
그래서 전 주석에 장문도 마다하지 않습니다.
이해만 쉽다면...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

욱성군의 이미지

전 태희를 개발하고 있는 서버의 로케일이 euckr 이라 python 스크립트를 만들어서 iconv 로 utf8 로 바꾸어서 사용합니다.

happyjun의 이미지

KTD wrote:
그런데 TortoiseSVN이나 Trac같은 오픈소스 프로젝트들을 도입하면서 소스 코드가 유니코드가 아닌 경우에 가끔 문제가 발생합니다.(파일이 깨져보이는 것 같은 문제들이요)

Trac의 경우 설정파일에 인코딩 설정이 있습니다. UTF-8이 아닌 경우도 잘 나옵니다.

----------------------------------------
http://moim.at
http://mkhq.co.kr

cmoh1110의 이미지

굳이 유니코드를 써야할 필요를 못 느낍니다.

Quote:

3. 유니코드를 사용하면서 장점과 단점은?

장점은 거의 모든 문자표현이 가능하다는 거,
정렬같은 거 할 때 편할 거 같다는 거..정도..

단점은 크기가 늘어난다는 것.
UTF-8이면 한글인 경우 3-byte가 되는 거 아닌가요?
200GB 순수 한글 데이타가 있다면 UTF-8로 인코딩할 경우 최대 300GB
가 된다는 건데.. 좀 거시기한 듯 합니다.

Google/MS처럼 다국어버전으로 수출(?)할 소프트웨어가 아니면 굳이
UTF-8로 갈 이유가 있을런지요..

방랑자의 이미지

서지훈 wrote:
htna wrote:
제가
"unicode의 필요성이 있는지가 더 의심스럽습니다."
라고 글을 올린 이유는...
주석을 한글로 처리할 필요를 느끼지 못하기 때문입니다.
어느정도 간단한 주석의 경우에는 차라리 영어로 처리하는게 편하구요..
( 한영자판 누르는게 귀찮아서.. ^^;; )
주석이 간단하지 않을경우에는 소스에 주석을 넣는게 어려워집니다.
( 경우에따라 흐름도, 호출도, 함수생성배경, 혹은 수식자체가 필요하기 때문에...
간단한 설명형 주석은 이런경우에 너무 불편하고, 나중에 소스분석시에
더 어지러워지는 경우가 종종 있지 않나요??
내가 왜 이런말을 적었지..? 하고 내 가 작성한 한글암호(주석)을 다시 해석해야 하는 경우가...)

차라리...
vacancy님의 ".. 다 영어입니다." 가 더욱 정확한 말이네요...

저는 주석(보다는 설명 자체가)이 필요한 경우에,
소스에 주석을 달지 않고...
프로젝트에 차라리 워드화일을 넣습니다.

PS:
머 항상 그런다는 건 아니지만, 가능하면 주석을 적게...
필요하면 워드등 다른 표현수단을 이용하려는...
생각만인지는 모르겠지만요...


영어를 다 영어로 하자고 한다면...
어느 정도의 영어 교육이 필요하지 않을지 ?
읽기와 작문을 위해...
설마... 모든 프로그래머가 이거 다 되는건 아니겠죠 ?

그리고, 전 소스에 주석은 풍부 할수록 좋다고 생각을 합니다.
언제 다시 볼때도 주석 없는 코드보다 있는 코드가 조금이라도 이해가 쉽잖아요.
그래서 전 주석에 장문도 마다하지 않습니다.
이해만 쉽다면...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

저도 '하양 지훈' 님에 말에 전적으로 동의 합니다.
많은 오픈소스 프로그램들중 큰 프로그램들 보면 소스
맨 상단에 이 모듈이 하는 역활에 대한 대략적인 설명과
설명조차로 부족했는지 그림으로 설명까지 해 놓은 경우가
많습니다. 구체적인 예는 sqlite 나 glibc 에 malloc 를 구현한
부분입니다. 사실 이 두 경우는 소스만 보고 파악하기는 쉽지가
않습니다. 이러한 부분에 있어 전부 영어로 작성하는것은 무리입니다.

물론 영어작문이 뛰어나 다른 사람들이 보기에도 혼돈이 없는
심플한 문장을 작성할 수 있는 능력이 그 팀의 모든
개발자들에게 있다면 모르겠지만요.

서지훈의 이미지

maenani wrote:
굳이 유니코드를 써야할 필요를 못 느낍니다.

Quote:

3. 유니코드를 사용하면서 장점과 단점은?

장점은 거의 모든 문자표현이 가능하다는 거,
정렬같은 거 할 때 편할 거 같다는 거..정도..

단점은 크기가 늘어난다는 것.
UTF-8이면 한글인 경우 3-byte가 되는 거 아닌가요?
200GB 순수 한글 데이타가 있다면 UTF-8로 인코딩할 경우 최대 300GB
가 된다는 건데.. 좀 거시기한 듯 합니다.

Google/MS처럼 다국어버전으로 수출(?)할 소프트웨어가 아니면 굳이
UTF-8로 갈 이유가 있을런지요..


하나 참고 하실건...
지금 하는건 소스 코드(프로젝트)에 관한 논의 이라는 겁니다.
완성품이나 전체 관련 문서들을 총망라한 건 아니지 않은지 ?
하나의 프로젝트에서 일반 텍스트로 작성한게 몇 백G 가 될만한 프로젝트는 거의 없을듯합니다.
리눅스 커널도 소스코도 몇 십 메가에 정도가 아니든가요 ?

고리고, 요즘 백업 장비 값이 워낙 헐 값이라 백업을 위해서라면 테라급도 마다 하지 않을겁니다.
멀지않아 개인용으로도 테라급을 쓸날이 얼마 남지 않은듯...

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

ktd2004의 이미지

happyjun wrote:
KTD wrote:
그런데 TortoiseSVN이나 Trac같은 오픈소스 프로젝트들을 도입하면서 소스 코드가 유니코드가 아닌 경우에 가끔 문제가 발생합니다.(파일이 깨져보이는 것 같은 문제들이요)

Trac의 경우 설정파일에 인코딩 설정이 있습니다. UTF-8이 아닌 경우도 잘 나옵니다.

저 같은 경우는 편집기를 vim을 사용합니다. 그런데 vim에서는 입력이 가능한 문자들이 소스코드에 포함되었을 경우에 Trac에서 해당 소스파일을 보면 모든 한글이 깨져버립니다.

예를 들면 얼마전에도 "명명"으로 써야할 것을 "ㅤㅁㅕㅁㅤㅁㅕㅁ"으로 잘못쓰면 Trac에서 파일전체의 한글이 깨져버립니다. 그리고 "ㅤㅎㅑㄴ" 같은 글자도요. ㅠㅠ;

keizie의 이미지

KTD wrote:
"명명"으로 써야할 것을 "ㅤㅁㅕㅁㅤㅁㅕㅁ"으로 잘못쓰면 Trac에서 파일전체의 한글이 깨져버립니다. 그리고 "ㅤㅎㅑㄴ" 같은 글자도요.

인코딩 설정을 EUC-KR로 하셨나요? EUC-KR은 이른바 완성형에 해당하는 글자들을 다루고, UHC나 CP949라고 하는 것은 MS 윈도우 95에서 도입한 확장 완성형이라는 걸 다룹니다. (프로그램에 따라서는 호환을 위해 EUC-KR인데도 내부는 CP949로 동작하는 경우가 있긴 합니다만)

UTF-8나 CP949 환경에서 입력한 글자는 EUC-KR에서 표현하기 위해서는 HTML에서 하는 것처럼 십진수나 십육진수로 바꿔서(눈으로 보기엔 깨뜨려서) 저장해야 합니다.

말씀하신 게 바로 그런 경우인 것 같습니다. 인코딩 설정을 살펴보시고, EUC-KR이면 CP949로 바꿔서 해보세요.

소타의 이미지

기본적으로 UTF-8을 선호하고 UTF-8로 개발했습니다..
하지만 국내 포탈 같은곳에 서비스를 올리려니 헤더탑 부분이나 푸터 일치 때문에 EUC-KR로 바꿔야만 했습니다 -_-;;;

지금 새로 시작하는 프로젝트는 모두 UTF-8입니다 으하하~

hirameki의 이미지

일본에서 SI 하고 있습니다.
SI지만 코드는 될수있는한 UTF-8을 사용합니다. 물론 고객들도 유니코드에 거부감은 그다지 없습니다.
주석이 일본어 / 한글이 혼용되기 때문이기도 하지만, 예전 영문권 프로그래머들이 글자 하나당 2바이트씩이나배정하는것에 거부감을 느끼는것처럼 우리나라 사람들도한글에서 되면 다된다 식의 개념을 가진 사람들을 꽤 봐왔습니다.

하지만, 일본쪽에서는 코드가 다양하기 때문에 인코딩에 관해서 공부하지 않으면 코드가 제대로 돌아가지 않아서, 근본적으로 문제가 적은 유니코드쪽을 선호하고 있습니다.

저도 영문주석 & 워드파일(CVS) 방법은 지지하는 편이고요. 될수있으면 에디터를 유니코드 지원 에디터로 통일합니다.(eclipse같은) 어차피 WEB서비스도 아니고 개발 에디터기 때문에 개발자간에 통일하는것이 좋다고 생각하고요.

유니코드의 장점으로는
1. 문자셋 변환간 문제가 일어나더라도, 프로젝트의 근본적인 진행을 막을정도는 되지 않고
2. 환경에 따른 문자 미지원 문제가능성이 거의 없으며
3. 다국어 혼용이 가능합니다.

단점으로는
1. 프로그램은 메시지를 분리해두는 방식의 코딩을 하지 않고 기존의 방식을 고집하는 경우에 불편하고(메시지 수정 등)
2. 에디터가 개발자마다 제각기인경우 유니코드를 지원하지 않는 에디터가 존재하는 경우에 다른 사람의 주석등을 모조리 깨먹는 문제가 간간히 발생하고
3. 서버사이드 프로그램인경우 서비스 서버 등에서 프로그램 소스를 바로 열어서 VI등으로 보고 고치는것이 힘듭니다.

제가 위에서 열거한 단점은 모두 프로젝트 진행을 위한 이론등에서, 해서는 안되는 것들이기 때문에 실질적으로 단점은 코딩하는 사람이 인코딩에 대해서 올바른 인식만 가지고 있다면 전혀 문제가 되지 않는 것들이므로, 단점이라고 하기도 뭐하군요.
:roll:

--

LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Hirameki --X-
Mail : hirameki_krjp@yahoo.co.jp
God is not customer center. Do it yourself
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

ktd2004의 이미지

kz wrote:

인코딩 설정을 EUC-KR로 하셨나요? EUC-KR은 이른바 완성형에 해당하는 글자들을 다루고, UHC나 CP949라고 하는 것은 MS 윈도우 95에서 도입한 확장 완성형이라는 걸 다룹니다. (프로그램에 따라서는 호환을 위해 EUC-KR인데도 내부는 CP949로 동작하는 경우가 있긴 합니다만)

UTF-8나 CP949 환경에서 입력한 글자는 EUC-KR에서 표현하기 위해서는 HTML에서 하는 것처럼 십진수나 십육진수로 바꿔서(눈으로 보기엔 깨뜨려서) 저장해야 합니다.

말씀하신 게 바로 그런 경우인 것 같습니다. 인코딩 설정을 살펴보시고, EUC-KR이면 CP949로 바꿔서 해보세요.

감사합니다. cp949로 변경하니까 괜찮네요.. ^^;

rainmon의 이미지

euc-kr이든 utf-8이든 문제없다면 아무거나 골라 쓰면 되지 않나요?
굳이 남들이 유니코드 쓴다고 euc-kr을 써도 아무 문제없는 소스를 utf-8로 변경할 필요가 있는지 궁금합니다.

전 유럽, 중국, 일본등에서 사용되는 프로그램을 개발하고 있기때문에 utf-8을 쓰는게 유리하고 xml을 다루는 일이 많기때문에 역시 utf-8을 씁니다. 하지만 euc-kr이 아직은 편해요. 아직 모든 편집기들이 유니코드를 지원하는게 아니라서요. 특히 오래된 툴인 경우엔..

참고로 python의 경우엔 소스코드를 utf-8로 작성하는게 대세인것으로 보입니다. 그쪽은 아예 인코딩을 명시적으로 소스상단에 써주더군요.

소타의 이미지

아.. 로컬라이징 할 때 편하구요.. gettext만 하면 되니까여 문서의 메타나 헤더를 변경할 필요가 없어지죠..
그리고 클라이언트와 통신이 XML입니다. 미들웨어간 통신도 XML이고.. DBMS는 원래 유니코드로 저장하고 있었구요.. 그래서 유니코드를 많이 쓰게 되었습니다

maxnim의 이미지

회사에서는 유니코드를 사용할 수 없는, 정말로 불가능한 상황에다가
다국어 버전에 대한 이해가 좀 부족한 관계로 그냥 euc-kr로 작업하고
있습니다만...
이게 가끔씩 태국어, 키릴어 같은 이상한 인코딩으로도 저장이 되더군요... ㅡㅡ;

개인적으로는 무조건 utf-8로 작업합니다.