나는 Sascha에 동의해야합니다. TCHAR/ _T()/ etc. 의 기본 전제 는 “ANSI”기반 응용 프로그램을 작성한 다음 매크로를 정의하여 마술처럼 유니 코드 지원을 제공 할 수 있다는 것입니다. 그러나 이것은 몇 가지 나쁜 가정을 기반으로합니다.

소프트웨어의 MBCS 및 유니 코드 버전을 모두 적극적으로 빌드해야합니다.

그렇지 않으면, 당신은 것 까지 미끄러 보통 사용하는 char*많은 장소에서 문자열을.

_T ( “…”) 리터럴에서 ASCII가 아닌 백 슬래시 이스케이프를 사용하지 않습니다.

“ANSI”인코딩이 ISO-8859-1 이 아니면 결과 char*와 wchar_t*리터럴은 동일한 문자를 나타내지 않습니다.

UTF-16 문자열은 “ANSI”문자열처럼 사용됩니다.

그들은 아니야. 유니 코드는 대부분의 레거시 문자 인코딩에 존재하지 않는 몇 가지 개념을 도입합니다. 대리. 문자 결합. 표준화. 조건부 및 언어 구분 대소 문자 규칙.

그리고 아마도 가장 중요한 것은 UTF-16이 디스크에 저장되거나 인터넷을 통해 전송되는 경우가 드물다는 사실입니다. UTF-8은 외부 표현에 선호되는 경향이 있습니다.

애플리케이션이 인터넷을 사용하지 않는다는 사실

(이제,이에 대한 올바른 가정 할 수있다 당신의 … 소프트웨어 만)

웹은 UTF-8 과 더 희귀 한 인코딩으로 실행 됩니다. 이 TCHAR개념은 “ANSI”( UTF-8 일 수 없음 )와 “유니 코드”(UTF-16) 두 가지만 인식 합니다. Windows API 호출이 유니 코드를 인식하도록 만드는 데 유용 할 수 있지만 웹 및 전자 메일 앱이 유니 코드를 인식하도록 만드는 데는 쓸모가 없습니다.

타사 라이브러리를 사용하지 않음

다른 누구도 TCHAR. Poco 는 std::stringUTF-8을 사용합니다. SQLite 에는 UTF-8 및 UTF-16 버전의 API가 있지만 TCHAR. TCHAR표준 라이브러리에도 없으므로 std::tcout직접 정의 하지 않는 한 없습니다 .

TCHAR 대신 내가 추천하는 것

유효한 UTF-8이 아닌 파일을 읽어야하는 경우를 제외하고 “ANSI”인코딩이 존재한다는 사실을 잊어 버리십시오. TCHAR너무 잊어라 . 항상 Windows API 함수의 “W”버전을 호출하십시오. #define _UNICODE실수로 “A”함수를 호출하지 않도록하기 위해서입니다.

문자열에는 항상 UTF 인코딩을 사용합니다. 문자열에는 UTF-8, char문자열에는 UTF-16 (Windows) 또는 UTF-32 (Unix 계열 시스템)를 wchar_t사용합니다. typedef UTF16및 UTF32문자 유형은 플랫폼의 차이를 방지 할 수 있습니다.