멀티바이트 프로젝트를 유니코드 프로젝트로 변경하면서 주의할 점들

멀티바이트로 작성된 오래된 코드를 유니코드로 변환하는 작업을 하면서 알게된 사실들. 느낀 점들을 정리해 보고자 한다.  

1. 형변환

멀티바이트 코드를 유니코드로 변환하게 되면 가장 먼저 마주치는 문제가 엄청나게 쏟아지는 워닝과 에러들이다. 이 문제들은 대략 다음과 같이 해결하면 되고 사실 이 부분들은 워낙 인터넷에도 자료가 많아서 쉽게 해결할 수 있는 부분들이다. 

1) 기본적으로 모든 스트링은 TCHAR 형으로 변환한다.  

2) 가급적 CString 을 사용한다. CString 은 내부적으로 프로젝트 속성에 따라서 유니코드와 멀티바이트에 맞게 자동으로 형 변환을 해 준다. 
CString 을 사용할 경우 내부적으로 멀티바이트 / 유니코드에 상관없이 통합적으로 쓸수 있으므로 매우 편리하다. 

3) 스트링과 관련되어 Deprecate 관련 Warning 이 뜰 경우 두가지 방법이 있다. 컴파일 옵션으로 워닝이 뜨지 않게 하는 것 ( 권장하지 않음 ), 그리고 _s 타입의 함수를 사용하는 것이다. 



2. 파일 저장시

유니코드 프로젝트에서 CFile 등을 이용해서 그냥 저장하면 파일 본문이 2 바이트씩 공백이 생기면서 이상하게 보이는 현상이 나타난다.
그리고 스트링 버퍼의 길이도 유니코드에 맞게 조절해 주어야 한다. 이를 위해서 아래의 두가지를 염두해 둔다. 

1) 파일을 열고 Write 하기 전에 맨 처음에 2 바이트의 BOM ( Byte Order Mark ) 를 추가해서 이 파일이 유니코드라는 것을 시스템에 알려줘야 한다. 

유니코드의 경우 이 값은 0xfeff 가 되며, 이 값을 파일의 제일 처음에 Write 해주면 된다. (아래 예제를 참고한다.)

2 ) CFile 로 Write 할 때 유니코드의 크기에 맞게 버퍼 스트링의 길이 * 2 만큼 Write 한다.

예제
CFile file; USHORT nShort = 0xfeff; // 유니코드 바이트 오더마크. if(file.Open("c:\\test.text", CFile::modeCreate | CFile::modeWrite | CFile::typeBinary)) { file.Write(&nShort,2); file.Write(pStrWideChar, nSize*2); file.Close();
 
3. 레지스트리 기록 시

레지스트리를 기록할 때에도 유니코드로 변환한 경우에는 이에 맞게 코드를 수정해 주어야 한다.

4. 소켓통신의 send / receive 함수를 사용하는 경우  

유니코드로 저장된 데이터 ( 예를 들면 TCHAR 배열 ) 를 send 등의 함수로 전송할 경우, send 함수의 파라미터 원형은 unsigned char (BYTE) 크기의 배열을 전달하므로  반드시 멀티바이트 타입으로 변환한 다음에 전송하고, receive 함수로 받을 때에도 unsigned char 배열을 TCHAR 배열로 변환하는 작업을 거쳐야 한다. 


멀티바이트 프로젝트의 프로젝트 속성을 유니코드로 변경하고 빌드해 보면 경고와 에러가 엄청나게 쏟아질 것이다. 이 때 경고와 에러를 없애는 것도 중요하지만 경고와 에러 없이 빌드에 성공했다고 해서 작업이 완료되는 것이 아니다. 오히려 이제부터 시작이라는 생각을 가져야 한다. 특히 파일 입출력이나 소켓 통신과 관련된 부분들의 코드들의 경우 빌드 에러로 나타나지는 않지만 실제로 테스트를 수행하다 보면 오작동하거나 프로그램이 비정상적으로 죽는 문제들이 발견되기도 하므로 주의깊게 테스트를 수행하면서 코드를 꼼꼼하게 수정해야 한다.