2012-07-02 6 views
19

Ich kam in dieser in dem Buch:Was ist eine "breite Zeichenfolge" in C-Sprache?

wscanf(L"%lf", &variable); 

, wo die ersten Parameter des Typs von wchar_t * sind.

Dies unterscheidet sich von scanf("%lf", &variable);, wobei der erste Parameter vom Typ char * ist.

Also was ist der Unterschied als. Ich habe noch nie "breite Zeichenfolge" gehört. Ich habe etwas namens Raw String Literals gehört, das die Zeichenfolge so druckt, wie es ist (keine Notwendigkeit für Dinge wie Escape-Sequenzen), aber das war nicht in C.

+5

Beginnen Sie hier http://www.joelonsoftware.com/articles/Unicode.html –

+3

Der erste Parameter ist tatsächlich vom Typ 'wchar_t []', subtil anders als 'wchar_t *'. – dreamlax

Antwort

29

Die genaue Natur der breiten Zeichen ist (absichtlich) links Implementierung definiert.

Als sie das Konzept wchar_t erfanden, konkurrierten ISO 10646 und Unicode immer noch miteinander (während sie jetzt meistens kooperieren). Anstatt zu versuchen, zu deklarieren, dass ein internationales Zeichen das eine oder das andere (oder möglicherweise etwas ganz anderes) sein würde, stellten sie einfach einen Typ (und einige Funktionen) zur Verfügung, den die Implementierung definieren könnte, um internationale Zeichensätze zu unterstützen.

Verschiedene Implementierungen haben dieses Potenzial für Variation ausgeübt. Wenn Sie beispielsweise den Compiler von Microsoft unter Windows verwenden, ist wchar_t ein 16-Bit-Typ, der UTF-16-Unicode enthält (ursprünglich enthielt er UCS-2-Unicode, aber das ist jetzt offiziell veraltet).

Unter Linux ist wchar_t häufiger ein 32-Bit-Typ, der UCS-4/UTF-32-codierten Unicode enthält. Ports von gcc zu mindestens einigen anderen Betriebssystemen machen das gleiche, obwohl ich nie versucht habe zu bestätigen, dass es immer der Fall ist.

Es gibt jedoch keine Garantie dafür. Zumindest könnte theoretisch eine Implementierung unter Linux 16 Bit verwenden, oder eine unter Windows könnte 32 Bit verwenden, oder jeder könnte sich für die Verwendung von 64 Bit entscheiden (obwohl ich etwas überrascht wäre, dies in der Realität zu sehen).

In jedem Fall ist die allgemeine Idee, wie die Dinge vorgesehen sind zu arbeiten, ist, dass eine einzige wchar_t ist ausreichend, um einen Codepunkt darzustellen. Für I/O sollen die Daten von der externen Repräsentation (was auch immer es ist) in wchar_ts umgewandelt werden, was (relativ) sie relativ einfach zu manipulieren macht. Dann werden sie während der Ausgabe wieder in die Kodierung Ihrer Wahl transformiert (die von der Kodierung, die Sie lesen, völlig verschieden sein kann).

+0

was ist mit anderen Nicht-Linux-Unix? Ist dies nicht eine Eigenschaft von glibc und nicht von linux? –

+0

Wie gesagt, nein, dafür gibt es keine Garantie: "theoretisch könnte eine Implementierung unter Linux 16 Bit verwenden". Soweit nicht-Linux-Unix geht, habe ich nicht kürzlich genug geschaut, um intelligent zu kommentieren. –

7

"Wide Zeichenkette" bezieht sich auf die Codierung der Zeichen in die Saite.

Von Wikipedia:

Ein großen Zeichen ist ein Computer-Zeichendatentyp, der eine Größe größer ist als die traditionellen 8-Bit-Zeichen im Allgemeinen hat. Die erhöhte Datentypgröße ermöglicht die Verwendung größerer codierter Zeichensätze.

UTF-16 ist eine der am weitesten verbreiteten Zeichencodierungen.

Ferner ist wchar_t durch Microsoft als unsigned short(16-bit) Datenobjekt definiert. Dies könnte und ist wahrscheinlich eine andere Definition in anderen Betriebssystemen oder Sprachen.

vom Wikipedia-Artikel aus dem Kommentar unten genommen.

„Die Breite des wchar_t ist Compiler-spezifisch und kann als 8 Bits so klein Folglich Programme, die über eine beliebige C tragbar sein müssen oder C++ - Compiler sollte nicht wchar_t zum Speichern von Unicode-Text verwenden. Der wchar_t-Typ ist zum Speichern Compiler-definierten breiten Zeichen, , die Unicode-Zeichen in einigen Compilern sein können.

+1

Laut Wikipedia ist es nicht tragbar: http://en.wikipedia.org/wiki/Wide_character – nhahtdh

+0

Danke für die Antwort. – quantum231

+0

@ quantum231, die Wiki-Antwort ist wirklich nur wahr für MSFT. Lesen Sie Jerrys Antwort und den Blogeintrag von Joel –