TCHAR은 아직 관련이 있습니까?

TCHAR은 아직 관련이 있습니까?

Windows 프로그래밍은 처음이라 Petzold 책을 읽은 후 다음과 같이 생각합니다.

이 기능을 사용하는 것은 여전히 좋은 관행입니까?TCHAR타입과_T()스트링을 선언하는 함수 또는 단순히 명령어를 사용해야 하는지wchar_t그리고.L""새 코드로 문자열을 입력하시겠습니까?

Windows 2000 이상만 대상으로 하고, 코드는 i18n으로 합니다.

간단한 대답은 "아니오"입니다.

이미 작성된 다른 모든 것과 마찬가지로, 많은 프로그래머들이 여전히 TCHAR과 이에 대응하는 함수를 사용하고 있습니다.내 겸손한 의견으로는 그 개념 전체가 나쁜 생각이었다.UTF-16 문자열 처리는 단순한 ASCII/MBCS 문자열 처리와는 크게 다릅니다.양쪽에서 같은 알고리즘/함수를 사용하는 경우(TCHAR 아이디어의 기반이 됩니다) 단순한 문자열 연결(파싱 등)보다 조금 더 많은 작업을 수행하면 UTF-16 버전에서 매우 나쁜 성능을 얻을 수 있습니다.주된 이유는 대리모입니다.

Unicode를 지원하지 않는 시스템에 대한 애플리케이션을 컴파일해야 하는 유일한 예외는 새로운 애플리케이션에 과거의 이 짐을 사용할 이유가 없다는 것입니다.

나는 사샤의 말에 동의해야 한다.의 기본 전제TCHAR/_T()/ etc는 "ANSI" 기반 응용 프로그램을 작성한 후 매크로를 정의하여 마법처럼 유니코드를 지원할 수 있습니다.그러나 이는 다음과 같은 몇 가지 잘못된 가정에 기초하고 있습니다.

소프트웨어의 MBCS 버전과 Unicode 버전을 모두 적극적으로 구축할 것

그렇지 않으면 실수해서 보통을 사용하게 됩니다.char*여러 곳에서 현악기를 연주합니다.

_T("...") 리터럴에서 ASCII 이외의 백슬래시 이스케이프를 사용하지 않는 경우

「ANSI」부호화가 ISO-8859-1이 아닌 한, 그 결과는char*그리고.wchar_t*리터럴은 같은 문자를 나타내지 않습니다.

UTF-16 문자열은 ANSI 문자열과 동일하게 사용됩니다.

아니, 그렇지 않아.Unicode는 대부분의 레거시 문자 인코딩에는 존재하지 않는 몇 가지 개념을 도입합니다.대리인.캐릭터 조합.정규화조건 및 언어에 민감한 케이스 규칙.

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

응용 프로그램이 인터넷을 사용하지 않는 경우

(이것이 소프트웨어에 대한 유효한 전제 조건일지도 모르지만...)

웹은 UTF-8과 더 희귀한 인코딩으로 작동합니다.그TCHARconcept 에서는 인식되는 것은, 「ANSI」(UTF-8은 불가)와 「Unicode」(UTF-16)의 2개 뿐입니다.Windows API 호출이 Unicode를 인식하도록 하는 데는 유용할 수 있지만 웹 및 이메일 앱이 Unicode를 인식하도록 하는 데는 전혀 도움이 되지 않습니다.

Microsoft 이외의 라이브러리를 사용하지 않는 경우

아무도 사용하지 않는다TCHARPoco는std::string및 UTF-8. SQLite에는 UTF-8 및 UTF-16 버전의 API가 있지만,TCHAR.TCHAR표준 라이브러리에도 없기 때문에std::tcout직접 정의하고 싶지 않다면요.

TCHAR 대신 추천하는 것

유효한 UTF-8이 아닌 파일을 읽어야 하는 경우를 제외하고 "ANSI" 인코딩은 존재하지 않습니다.TCHARWindows API 함수의 "W" 버전을 호출합니다. #define _UNICODE실수로 "A" 함수를 호출하지 않도록 주의하세요.

문자열에는 항상 UTF 인코딩을 사용합니다.UTF-8은char스트링 및 UTF-16(Windows) 또는 UTF-32(Unix 라이크시스템)에 대해wchar_t줄들. typedef UTF16그리고.UTF32플랫폼 차이를 피하기 위해 문자 유형을 지정합니다.

만약 당신이 그것이 아직 실행 중인지 궁금하다면, 그렇다 - 그것은 여전히 꽤 많이 사용되고 있다.TCHAR 및 _T("")를 사용하면 아무도 코드를 이상하게 보지 않습니다.현재 진행 중인 프로젝트는 ANSI에서 Unicode로 변환하고 있으며, 우리는 휴대용(TCHAR) 루트로 가고 있습니다.

하지만...

ANSI/UNICode 휴대용 매크로(TCHAR, _T(") 및 _tXXXX 콜 등)는 모두 잊어버리고 모든 곳에 Unicode가 있다고 가정하는 것이 좋습니다.ANSI 버전이 필요 없다면 휴대할 수 있는 이유를 잘 모르겠습니다.나는 모든 와이드한 문자 기능과 종류를 직접 사용할 것이다.모든 문자열 리터럴에 L을 붙입니다.

오늘 새로운 프로젝트를 진행하더라도 TCHAR 구문을 사용할 것입니다.WCHAR 구문과 실제적인 차이는 별로 없고, 문자 타입이 명료한 코드를 선호합니다.대부분의 API 함수 및 도우미 오브젝트는 TCHAR 타입(예:CString)을 사용하면 의미가 있습니다.또한 ASCII 앱에서 코드를 사용하기로 결정한 경우나 Windows가 Unicode32 등으로 진화하는 경우 등에 유연하게 사용할 수 있습니다.

만약 당신이 WCHAR 루트를 선택한다면, 나는 그것에 대해 분명히 말할 것이다.즉, TCHAR(CW2CT 등)로 변환할 때는 CString 대신 CStringW를 사용하여 매크로를 캐스팅합니다.

어쨌든 그건 내 의견이야.

MSDN의 Windows 프로그래밍 개요 기사에는 다음과 같이 기술되어 있습니다.

새로운 어플리케이션은 항상 Unicode 버전(API)을 호출해야 합니다.

TEXT 매크로와 TCHAR 매크로는 모든 응용 프로그램이 Unicode를 사용해야 하기 때문에 현재는 그다지 유용하지 않습니다.

난 계속 할 것이다.wchar_t그리고.L"".

나는 다른 접근법을 제안하고 싶다(둘 다) 다른 접근법을 제안하고 싶다.

요약하려면 UTF-8 인코딩을 전제로 char* 및 std::string을 사용하여 API 함수를 랩핑할 때만 UTF-16으로 변환합니다.

Windows 프로그램에서의 이 어프로치의 상세한 것에 대하여는, http://www.utf8everywhere.org 를 참조해 주세요.

TCHAR/WCHAR몇 가지 레거시 프로젝트에는 충분할 것 같습니다.하지만 새로운 어플리케이션의 경우 NO라고 대답합니다.

이 모든 것TCHAR/WCHAR역사적 이유 때문에 그런 게 있는 거예요 TCHAR는, ANSI Text Encoding(MBCS; 텍스트 부호화)과 Unicode Text Encoding(UTF-16)의 전환 방법을 깔끔하게 나타내고 있습니다.과거에 사람들은 세계의 모든 언어의 글자 수를 이해하지 못했다.그들은 2바이트가 모든 문자를 나타내기에 충분하다고 가정했고, 따라서 다음과 같이 고정 길이의 문자 인코딩 방식을 사용하였습니다.WCHAR그러나 1996년 Unicode 2.0이 출시된 이후 이것은 더 이상 사실이 아닙니다.

즉, 다음과 같습니다.어떤 용도로 사용하셔도CHAR/WCHAR/TCHAR프로그램의 텍스트 처리 부분은 국제화를 위해 가변 길이의 문자를 처리할 수 있어야 합니다.

그래서 사실 둘 중 하나를 고르는 것 이상을 해야 한다.CHAR/WCHAR/TCHARWindows 프로그래밍의 경우:

1. 응용 프로그램이 작고 텍스트 처리를 수반하지 않는 경우(즉, 텍스트 문자열을 인수로 전달하는 것)에는 그대로 사용합니다.WCHARUnicode를 지원하는 WinAPI를 사용하는 것이 이 방법으로 작업하기 쉽기 때문입니다.
2. 그렇지 않으면 UTF-8을 내부 인코딩으로 사용하여 텍스트를 char string 또는 std:: string으로 저장할 것을 권장합니다.WinAPI를 호출할 때 UTF-16으로 변환합니다.UTF-8은 현재 주요 인코딩이며 UTF-8 문자열을 처리하기 위한 편리한 라이브러리와 도구가 많이 있습니다.

자세한 내용은 이 멋진 웹사이트를 참조하십시오.http://utf8everywhere.org/

네, 물론이죠. 적어도 _T 매크로의 경우에요.하지만 글씨가 넓은 건 잘 모르겠어요

그 이유는 WinCE 또는 기타 비표준 Windows 플랫폼을 더 잘 지원하기 위해서입니다.코드가 NT에 남아 있는 것이 100% 확실하다면 일반 C-string 선언을 사용할 수 있습니다.다만, Windows 이외의 플랫폼에서는, 그 매크로를 #정의하는 것이, 수천줄의 코드를 참조해, Windows 모바일에 라이브러리를 이식할 필요가 있는 경우에 대비해 어디에서나 추가하는 것보다 훨씬 간단하기 때문에, 보다 유연한 어프로치를 선택하는 것이 좋습니다.

IMHO, 만약 당신의 코드에 TCHARs가 있다면, 당신은 잘못된 추상화 수준에서 일하고 있는 것입니다.

텍스트 처리를 할 때 가장 편리한 문자열 유형을 사용하세요.유니코드를 지원하는 문자열이 되었으면 합니다만, 그것은 여러분에게 달려 있습니다.필요에 따라 OS API 경계에서 변환을 수행합니다.

파일 경로를 다룰 때는 문자열을 사용하는 대신 사용자 정의 유형을 작성하십시오.이것에 의해, OS에 의존하지 않는 패스 구분자가 가능하게 되어, 수동으로 스트링을 접속하거나 분할하거나 하는 것보다 코드화하기 쉬운 인터페이스를 얻을 수 있어 다양한 OS(ansi, uc-2, utf-8 등)에의 적응이 훨씬 쉬워집니다.

명시적 WCHAR 이외의 것을 사용하는 유일한 이유는 휴대성과 효율입니다.

최종 실행 파일을 가능한 한 작게 만들려면 char를 사용합니다.

RAM 의 사용 상황에 개의치 않고, 국제화를 심플한 번역과 같이 간단하게 하고 싶은 경우는, WCHAR 를 사용합니다.

코드를 유연하게 하려면 TCHAR을 사용합니다.

라틴 문자만 사용할 계획이라면 ASCII/MBCS 문자열을 사용하여 사용자가 RAM을 많이 필요로 하지 않도록 하는 것이 좋습니다.

"i18n"을 처음부터 사용하는 사용자는 소스 코드 공간을 절약하고 모든 Unicode 함수를 사용합니다.

오래된 질문에 덧붙입니다.

아니요.

VS2010에서 새로운 CLR C++ 프로젝트를 시작하십시오.Microsoft 자체 사용L"Hello World",'nuff 말했다.

TCHAR항구에 새로운 의미가 있다WCHAR to CHAR.

https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page

Recent releases of Windows 10 have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, -A APIs operate in UTF-8.

ReferenceURL : https://stackoverflow.com/questions/234365/is-tchar-still-relevant