VS 2005 부터는 프로젝트 생성시 기본적으로 유니코드 문자집합을 선택하게 되어 있습니다.
처음엔 속성에서 일일이 멀티 바이트 문자집합으로 바꿔주기도 했지만 곧 그것도
귀찮더군요. 그래서 현재는 그냥 유니코드에 맞는 코딩을 하고 있습니다.
윈도우 프로그래밍에선 유니코드나 멀티바이트나 별 차이는 없습니다.
단지 문자나 문자열 앞에 L 또는 TEXT() 매크로를 사용해주는 것만으로도 충분합니다.
그 외엔 운영체제에서 자체 지원하는
lstrcpy(strcpy)
lstrcmp(strcmp)
lstrcat(strcat)
lstrlen(strlen)
정도만 기억하시면 충분합니다.
제 경우는 문자열엔 TEXT()를 문자엔 L을 붙여서 코딩하고 있습니다.
둘의 차이는 거의 없기에 어떻게 사용하든 본인의 자유겠죠.
(int 를 제외한 변수를 선언할때도 주의해주셔야 합니다만...
주의할 거래봐야 char 를 TCHAR로 선언해주는 것 정도죠)
하지만 콘솔 프로그래밍으로 넘어가면 이건 그렇게 만만치가 않습니다.
VS 2005 이전에 유니코드를 지원하던 앞에 w가 붙는 함수가
2005로 넘어오면서 w..._s 형으로 다시 바뀐 겁니다.
_s 형으로 바뀐 건 좋은데 가끔은 받아들이는 인수의 수조차 바뀐 것들이
있어서 사람을 미치게 합니다.
예를 들면
wstrcat_s
예전엔 2개의 인수만을 받던 strcat 함수가 3개의 인수를 받도록 바껴버린거죠.
물론 여전히 2개의 인수를 받고 유니코드를 지원하는 lstrcat을 사용하면 그만이죠
하지만 어딘가 제가 모르는 저런 식의 함수가 분명 있을 겁니다.
(콘솔 프로그램의 의미가 거의 바닥을 치는데 이런 예기는 사실 별 의미가 없죠.)
그래도 혹시나 콘솔 프로그램을 작성하시다가 유니코드를 지원하는 함수를
알 필요가 있을 땐 MSDN을 이용해 보십시오. 영어를 몰라도
대충보면 어떤 함수를 사용해야 하는지 찾으실 수 있으실 겁니다.
서론은 여기까지 하고 이 글을 적는 본론으로 들어가죠
제가 콘솔 프로그램을 하나 만들었습니다. 물론, 유니코드를 사용했죠.
그런데 막상 실행해보니 도스창에 한글이 찍히지 않는 겁니다.
에러 경고 하나도 뜨지 않는데 한글을 안 찍히니 미칠 지경이더군요.
미친듯이 찾아 본 결과 답을 찾았습니다. 물론, 어째서 그런지는 모릅니다.
전혀요;
_wsetlocale(LC_ALL,TEXT("Korean"));
이걸 적어줘야 하더군요. 함수 이름만으로는 지역변경 - 한국 쯤 되는군요;
위 함수의 정의는 locale.h 안에 들어 있습니다.
위 함수를 적어주고 컴파일 하니 한글 출력이 되더군요.
(망할 유니코드...)
그 외에 이런 경우도 있습니다. 멀티바이트 유니코드 안 따지는 함수들이
가끔 있습니다. 그 형태 그대로 유지해서 어느 쪽에나 적응가능하죠.
그런데 가끔 이 함수들이 인수로 받아들이는 데이타형이 유니코드에 맞지 않을때가 있습니다.
예를 들면 소켓 프로그래밍의 send,recv 함수 같은 게 있죠
send,recv 함수는 두번째 인수로 (const char*) 형을 받습니다.
이 경우
TCHAR a[10];
send(socket,(char*)a,......);
//에러
send(socket,(char FAR*)a,......);
//성공
이런 식으로 적어주어야 합니다. recv 역시 마찬가지로 char FAR*
형으로 캐스팅해주면 유니코드 문자열을 넘겨줄 수 있습니다.
지금까지 제가 유니코드를 사용해 코딩하면서 겪은 문제점은 이걸로 대충 다 적었습니다.
아... 마지막으로 강조해야 할 부분 유니코드는 한 문자가 1바이트가 아니라 2바이트란 거죠.
(멀티바이트는 1바이트 문자셋과 2바이트 문자셋이 섞여 있죠)
유니코드에선 심지어 영어도 2바이트를 차지합니다.
크게 중요해 보이지 않는 거 같지만 이걸 깜박하면 자신도 모르게 에러를
내 버릴 수가 있습니다. (특히 메모리 활당 부분)
그럼, 별 의미 없는 글이나마 읽어주셔서 감사합니다.
p.s : wprintf 함수의 경우 유니코드 문자열을 출력할때는 %s 가 아니라 %S를 써야 합니다
안 그럼 알 수 없는 외계어가 출력되죠
출처 : http://cafe.naver.com/teacheryun
처음엔 속성에서 일일이 멀티 바이트 문자집합으로 바꿔주기도 했지만 곧 그것도
귀찮더군요. 그래서 현재는 그냥 유니코드에 맞는 코딩을 하고 있습니다.
윈도우 프로그래밍에선 유니코드나 멀티바이트나 별 차이는 없습니다.
단지 문자나 문자열 앞에 L 또는 TEXT() 매크로를 사용해주는 것만으로도 충분합니다.
그 외엔 운영체제에서 자체 지원하는
lstrcpy(strcpy)
lstrcmp(strcmp)
lstrcat(strcat)
lstrlen(strlen)
정도만 기억하시면 충분합니다.
제 경우는 문자열엔 TEXT()를 문자엔 L을 붙여서 코딩하고 있습니다.
둘의 차이는 거의 없기에 어떻게 사용하든 본인의 자유겠죠.
(int 를 제외한 변수를 선언할때도 주의해주셔야 합니다만...
주의할 거래봐야 char 를 TCHAR로 선언해주는 것 정도죠)
하지만 콘솔 프로그래밍으로 넘어가면 이건 그렇게 만만치가 않습니다.
VS 2005 이전에 유니코드를 지원하던 앞에 w가 붙는 함수가
2005로 넘어오면서 w..._s 형으로 다시 바뀐 겁니다.
_s 형으로 바뀐 건 좋은데 가끔은 받아들이는 인수의 수조차 바뀐 것들이
있어서 사람을 미치게 합니다.
예를 들면
wstrcat_s
예전엔 2개의 인수만을 받던 strcat 함수가 3개의 인수를 받도록 바껴버린거죠.
물론 여전히 2개의 인수를 받고 유니코드를 지원하는 lstrcat을 사용하면 그만이죠
하지만 어딘가 제가 모르는 저런 식의 함수가 분명 있을 겁니다.
(콘솔 프로그램의 의미가 거의 바닥을 치는데 이런 예기는 사실 별 의미가 없죠.)
그래도 혹시나 콘솔 프로그램을 작성하시다가 유니코드를 지원하는 함수를
알 필요가 있을 땐 MSDN을 이용해 보십시오. 영어를 몰라도
대충보면 어떤 함수를 사용해야 하는지 찾으실 수 있으실 겁니다.
서론은 여기까지 하고 이 글을 적는 본론으로 들어가죠
제가 콘솔 프로그램을 하나 만들었습니다. 물론, 유니코드를 사용했죠.
그런데 막상 실행해보니 도스창에 한글이 찍히지 않는 겁니다.
에러 경고 하나도 뜨지 않는데 한글을 안 찍히니 미칠 지경이더군요.
미친듯이 찾아 본 결과 답을 찾았습니다. 물론, 어째서 그런지는 모릅니다.
전혀요;
_wsetlocale(LC_ALL,TEXT("Korean"));
이걸 적어줘야 하더군요. 함수 이름만으로는 지역변경 - 한국 쯤 되는군요;
위 함수의 정의는 locale.h 안에 들어 있습니다.
위 함수를 적어주고 컴파일 하니 한글 출력이 되더군요.
(망할 유니코드...)
그 외에 이런 경우도 있습니다. 멀티바이트 유니코드 안 따지는 함수들이
가끔 있습니다. 그 형태 그대로 유지해서 어느 쪽에나 적응가능하죠.
그런데 가끔 이 함수들이 인수로 받아들이는 데이타형이 유니코드에 맞지 않을때가 있습니다.
예를 들면 소켓 프로그래밍의 send,recv 함수 같은 게 있죠
send,recv 함수는 두번째 인수로 (const char*) 형을 받습니다.
이 경우
TCHAR a[10];
send(socket,(char*)a,......);
//에러
send(socket,(char FAR*)a,......);
//성공
이런 식으로 적어주어야 합니다. recv 역시 마찬가지로 char FAR*
형으로 캐스팅해주면 유니코드 문자열을 넘겨줄 수 있습니다.
지금까지 제가 유니코드를 사용해 코딩하면서 겪은 문제점은 이걸로 대충 다 적었습니다.
아... 마지막으로 강조해야 할 부분 유니코드는 한 문자가 1바이트가 아니라 2바이트란 거죠.
(멀티바이트는 1바이트 문자셋과 2바이트 문자셋이 섞여 있죠)
유니코드에선 심지어 영어도 2바이트를 차지합니다.
크게 중요해 보이지 않는 거 같지만 이걸 깜박하면 자신도 모르게 에러를
내 버릴 수가 있습니다. (특히 메모리 활당 부분)
그럼, 별 의미 없는 글이나마 읽어주셔서 감사합니다.
p.s : wprintf 함수의 경우 유니코드 문자열을 출력할때는 %s 가 아니라 %S를 써야 합니다
안 그럼 알 수 없는 외계어가 출력되죠
출처 : http://cafe.naver.com/teacheryun
