Arbeiten mit Zeichenfolgen
Windows unterstützt nativ Unicode-Zeichenfolgen für Ui-Elemente, Dateinamen usw. Unicode ist die bevorzugte Zeichencodierung, da es alle Zeichensätze und Sprachen unterstützt. Windows stellt Unicode-Zeichen mit UTF-16-Codierung dar, in denen jedes Zeichen als ein oder zwei 16-Bit-Werte codiert ist. UTF-16-Zeichen werden als Breitzeichen bezeichnet, um sie von 8-Bit-ANSI-Zeichen zu unterscheiden. Der Visual C++-Compiler unterstützt den integrierten Datentyp wchar_t für breite Zeichen. Die Headerdatei WinNT.h definiert auch den folgenden Typdef.
typedef wchar_t WCHAR;
Beide Versionen werden im MSDN-Beispielcode angezeigt. Um ein Breitzeichenliteral oder ein Breitzeichen-Zeichenfolgenliteral zu deklarieren, legen Sie L vor das Literal.
wchar_t a = L'a';
wchar_t *str = L"hello";
Hier sind einige andere Zeichenfolgenbezogene Typbeschreibungen, die Angezeigt werden:
TypeDef | Definition |
---|---|
CHAR | char |
PSTR oder LPSTR | char* |
PCSTR oder LPCSTR | const char* |
PWSTR oder LPWSTR | wchar_t* |
PCWSTR oder LPCWSTR | const wchar_t* |
Unicode- und ANSI-Funktionen
Als Microsoft die Unicode-Unterstützung in Windows eingeführt hat, erleichterte es den Übergang, indem zwei parallele Sätze von APIs bereitgestellt wurden, eine für ANSI-Zeichenfolgen und die andere für Unicode-Zeichenfolgen. Beispielsweise gibt es zwei Funktionen, um den Text der Titelleiste eines Fensters festzulegen:
- SetWindowTextA nimmt eine ANSI-Zeichenfolge an.
- SetWindowTextW verwendet eine Unicode-Zeichenfolge.
Intern übersetzt die ANSI-Version die Zeichenfolge in Unicode. Die Windows-Header definieren auch ein Makro, das in die Unicode-Version aufgelöst wird, wenn das Präprozessorsymbol UNICODE
definiert ist oder andernfalls die ANSI-Version.
#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif
In MSDN wird die Funktion unter dem Namen SetWindowText dokumentiert, obwohl dies tatsächlich der Makroname und nicht der tatsächliche Funktionsname ist.
Neue Anwendungen sollten immer die Unicode-Versionen aufrufen. Viele Weltsprachen erfordern Unicode. Wenn Sie ANSI-Zeichenfolgen verwenden, ist es unmöglich, Ihre Anwendung zu lokalisieren. Die ANSI-Versionen sind auch weniger effizient, da das Betriebssystem die ANSI-Zeichenfolgen zur Laufzeit in Unicode konvertieren muss. Je nach Ihren Vorlieben können Sie die Unicode-Funktionen explizit aufrufen, z. B . SetWindowTextW, oder die Makros verwenden. Der Beispielcode auf MSDN ruft normalerweise die Makros auf, aber die beiden Formulare sind genau gleichwertig. Die meisten neueren APIs in Windows verfügen nur über eine Unicode-Version ohne entsprechende ANSI-Version.
TCHARs
Wenn Anwendungen sowohl Windows NT als auch Windows 95, Windows 98 und Windows Me unterstützen mussten, war es hilfreich, je nach Zielplattform denselben Code für ANSI- oder Unicode-Zeichenfolgen zu kompilieren. Zu diesem Zweck stellt das Windows SDK Makros bereit, die Zeichenfolgen je nach Plattform Unicode oder ANSI zuordnen.
Makro | Unicode | ANSI |
---|---|---|
TCHAR | wchar_t |
char |
TEXT("x") oder _T("x") |
L"x" |
"x" |
Beispielsweise folgender Code:
SetWindowText(TEXT("My Application"));
löst eine der folgenden Aktionen auf:
SetWindowTextW(L"My Application"); // Unicode function with wide-character string.
SetWindowTextA("My Application"); // ANSI function.
Die Makros TEXT und TCHAR sind heute weniger nützlich, da alle Anwendungen Unicode verwenden sollten. Möglicherweise werden sie jedoch in älteren Code und in einigen MSDN-Codebeispielen angezeigt.
Die Header für die Microsoft C-Laufzeitbibliotheken definieren einen ähnlichen Satz von Makros. Beispielsweise wird _tcslen in strlen aufgelöst, wenn _UNICODE
undefiniert ist, andernfalls wird es in wcslen aufgelöst, was die breitzeichenige Version von strlen ist.
#ifdef _UNICODE
#define _tcslen wcslen
#else
#define _tcslen strlen
#endif
Seien Sie vorsichtig: Einige Header verwenden das Präprozessorsymbol UNICODE
, andere verwenden _UNICODE
ein Unterstrichpräfix. Definieren Sie immer beide Symbole. Visual C++ legt beide standardmäßig fest, wenn Sie ein neues Projekt erstellen.
Nächste
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für