출처: http://blog.naver.com/wondo21c?Redirect=Log&logNo=30043174174

앞으로 문자열을 코딩할 때, char 대신에 TCHAR을 사용해야겠다.


확장성과 이식성을 위해서 앞으로 그렇게 습관을 들여야겠다.


Visual Studio 2005 프로젝트 속성 ->구성속성을 보면


문자 집합으로 2가지를 사용할 수 있다.

1. 멀티바이트 문자 집합

2. 유니코드 문자 집합




아스키코드는 모든 문자 하나가 1byte를 차지한다.


하지만, 아스키 문자 코드 만으로는 한글이나 일어 등의 다른 문자를 표시할 수 없다.


그래서 아스키 문자 코드에다가 다른 문자(2byte)들을 포함한 문자 집합이 멀티바이트 문자 집합이다.


정확히는 모르겠지만, 한 문자가 2byte를 넘는 문자도 존재할 것이다.


그래서 용어 자체가 멀티바이트 문자 집합이 아닐까 생각한다.


그런데 멀티바이트 문자 집합은 특정 문자 집합마다의 코드페이지가 존재한다.


예를 들어, 같은 코드 번호 일지라도 한글 코드 페이지로 해석하면 한글이 나오지만,


일어 코드 페이지로 해석하면 일어가 나온다.


그래서 이상하게 깨지는 문자 등을 우리는 목격할 수 있다.




이것의 방안으로 탄생한 것이 유니코드!


유니코드는 아스키 문자 코드 뿐만 아니라, 한글, 일어 등등 어떠한 문자들을 총 망라하여


각 한 문자에 2byte씩으로 할당하여 만든 문자 집합이다.


그리하여 각각의 특정 문자는 고유의 유니코드값을 가진다.




우리의 문제는 코딩 시에, 어떻게 해야 하는가!


너무나도 초보인 나는 아직 ANSI 표준 문자열을 쓰는데도 익숙치 않다.


하지만 메모리를 다루는 프로그래머로써 1bit의 메모리라두 잘못된 경우에는


프로그램 전체를 뻑(Crash)하는 우려를 범하곤 한다.


나같은 게임 프로그래머로서는 게임 실컷 만들어 놓고, 유저들에게 버그 많다고 욕들어 먹는다. ^^;;




게임뿐만 아니라 어떤 프로그램도 요새는 세계화가 아닌가!


그래서 한글과 영어만으로는 완벽하다고 안심해서는 안된다.


대만어, 프랑스어 등등 어떠한 문자 앞에서도 굴하지 않아야 된다.


그렇다고 우리가 각각의 나라별로 게임을 개별적으로 만들어 줄 수는 없지 않은가!


그래서 소스 상에서 유연성이 필요한 것 같다.




일단, 나는 자주 쓰는 몇 개의 습관부터 고치고자 노력해야 겠다.


 char  TCHAR
 strcat_s()  _tcscat_s()
 strcpy_s(), strncpy_s()  _tcscpy_s() , _tcsncpy_s()
 strlen()  _tcslen
 sprintf_s()  _stprintf_s


 


그리고 문자열을 바로 쓸 때,


"" 대신에 TEXT("")을 쓰자.


TEXT 매크로는 유니코드의 설정에 따라 상수의 타입을 달리 한다.


예를 들어 유니코드로 컴파일 할 경우, TEST("a")를 16bit(2byte) 문자로 인식하고,

아닐 경우, 8bit(1byte) ANSI 문자로 인식한다.






밑의 표는 인터넷에서 구한 것.



 



 
 
 
 

AND