[C] Escape-Sequenzen (\x041e) benutzen

[Olli]

Hallöchen,

kurze Frage, hoffentlich schnelle Antwort: Wenn man Escapesequenzen benutzt, kann man zB auch Unicodezeichen in Unicodestring einfügen:

Code:

const LPCWSTR lpwcXyz =
   L"\x041e\x043b\x043b\x0438";

wenn ich jetzt ein 'a' anfüge und nicht auf Stringzusammenfügung (string concatenation) vertraue, habe ich ein Problem, weil ich ja dann folgendes schreiben muß (was nicht funktioniert, daher die Frage):

Code:

const LPCWSTR lpwcXyz =
   L"\x041e\x043b\x043b\x0[b][u]438[color=red]a[/color][/u][/b]";

Wie man leicht sehen kann (fetter unterstrichener Bereich) wird daraus eine andere hexadezimale Zahl und die Ziffer 0 am Anfang wird ignoriert. Wie kann ich das umgehen, ohne daß ich folgendes schreiben muß (also string concatenation)?:

Code:

const LPCWSTR lpwcXyz =
   L"\x041e\x043b\x043b\x0438"[color=red]L"a"[/color];

[marabu]

Hi Olli,

meine Erfahrungen mit C stammen von Aztec C aus den 70/80er Jahren, aber ist es heute nicht so, dass man 4 digit unicode escape sequences mit \u1234 schreibt?

Grüße vom marabu

[Olli]

Zitat von marabu:

meine Erfahrungen mit C stammen von Aztec C aus den 70/80er Jahren, aber ist es heute nicht so, dass man 4 digit unicode escape sequences mit \u1234 schreibt?

Leider nein, dann kommt das

Code:

warning C4129: 'u' : unrecognized character escape sequence

.. verwechselst du das vielleicht mit U+ABCD (also der offiziellen Notation für Unicodezeichen?).

Im Anhang der Grund der Frage

[marabu]

Keine Verwechslung. Wenn dein Compiler (welcher eigentlich?) die \u escapes nicht kennen will, vielleicht kannst du ihn mit einem Schalter überreden? Oder ist dein Compiler zu alt und du simulierst UTF-16 durch doppelt lange \x Literale?

Der aktuelle IBM C/C++ Compiler kennt \u und ich glaube nicht, dass er der einzige Compiler ist: klick (page 24 of 362)

marabu

[Olli]

Okay, habe es gerade getestet. VS.NET 2003 unterstützt \u, welches offenbar mit dem C99-Standard einfegührt wurde. hingegen VS6 unterstützt es noch nicht. Ich werde es deshalb auch nicht benutzen können (wegen Inkompatibilität). Aber offenbar ginge

Code:

const LPCWSTR lpwcXyz =
   L"\u041e\u043b\u0438\u0432\u0435\u0440a";

, ohne daß es zu Problemen kommt.

Vermutlich werde ich das als weiteren Modus zu Uniconv hinzufügen.

Danke einstweilen. Sieht also so aus, daß ich beide Modi mitführen muß.

[Olli]

Siehe http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf ...

Seite 26/224 in Acrobat, beschriftet als Seite 19!

A new feature of C99: C99 adds the concept of universal character name (UCN) (see §6.4.3) in
order to allow the use of any character in a C source, not just English characters. The primary
goal of the Committee was to enable the use of any “native” character in identifiers, string
literals and character constants, while retaining the portability objective of C.

Seite 58/224 in Acrobat, beschriftet als Seite 51!

6.4.3 Universal character names
A new feature of C99: Note that, to allow for Universal Character Names (UCNs), a new
production has been added to the grammar that encompasses all forms of identifier elements
(basic letter, UCN, or extended character). There was some discussion about the need to require
5 an implementation to handle all digits, Arabic or otherwise, in a similar way. The general
feeling was that detecting the “extended digits” might be an undesirable burden for many
implementations and should be avoided if possible.
Note that a strictly conforming program may use in identifiers only the extended characters listed
in Annex I, and may not begin an identifier with an extended digit.

Seite 62/224 in Acrobat, beschriftet als Seite 55!

QUIET CHANGE IN C99
Character literals of the form ‘\unnnn’ and ‘\Unnnnnnnn’ now have different
meanings (see §6.4.3). Note that the escape sequence beginning with \U is reserved
in C99, but was not reserved in C89.