Verwirrung bei Chr und AnsiChar

[SebastianZ]

Hallo zusammen,

ich hab ein leichtes Verständnisproblem, vielleicht kann mir ja wer auf die Sprünge helfen.

Warum ist Chr(158) ungleich AnsiChar(158), aber Chr(160) ist gleich AnsiChar(160)

Chr liefert Char zurück, und die ersten 256 Zeichen sollten bei Char und AnsiChar ident sein?


Habs anhand einer Konsole kurz mal durchprobiert.

Delphi-Quellcode:

begin
  try
    writeLn(100);
    if AnsiChar(100) = Char(100) then WriteLn('ja')
    else WriteLn('nein');
//ja

    writeLn(155);
    if AnsiChar(155) = Char(155) then WriteLn('ja')
    else WriteLn('nein');
//nein

    writeLn(156);
    if AnsiChar(156) = Char(156) then WriteLn('ja')
    else WriteLn('nein');
//nein

    writeLn(157);
    if AnsiChar(157) = Char(157) then WriteLn('ja')
    else WriteLn('nein');
//nein

    writeLn(158);
    if AnsiChar(158) = Char(158) then WriteLn('ja')
    else WriteLn('nein');
//nein

    writeLn(159);
    if AnsiChar(159) = Char(159) then WriteLn('ja')
    else WriteLn('nein');
//nein

    writeLn(160);
    if AnsiChar(160) = Char(160) then WriteLn('ja')
    else WriteLn('nein');
//ja

    ReadLn;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

[mkinzler]

Zitat:

Chr liefert Char zurück, und die ersten 256 Zeichen sollten bei Char und AnsiChar ident sein?

Eigentlich nur bei alten Delphiversionen und auch nur die ersten 128 (ANSI) der 2 Teil ist abhängig von der Codepage.
Char bei den Unicodeversionen ist ein WideChar also 16Bit, bei denen die ersten 7 Bit mit den ersten 7Bit von AnsiChar identisch sind. Die letzen 8 Bits (welche es bei AnsiChar ja nicht gibt, da nur 8Bit) sind dann 0.

[SebastianZ]

Zitat:

Zitat von mkinzler (Beitrag 1366651)

Zitat:

Chr liefert Char zurück, und die ersten 256 Zeichen sollten bei Char und AnsiChar ident sein?

Eigentlich nur bei alten Delphiversionen und auch nur die ersten 128 (ANSI) der 2 Teil ist abhängig von der Codepage.
Char bei den Unicodeversionen ist ein WideChar also 16Bit, bei denen die ersten 7 Bit mit den ersten 7Bit von AnsiChar identisch sind. Die letzen 8 Bits (welche es bei AnsiChar ja nicht gibt, da nur 8Bit) sind dann 0.

Danke für die Antwort.

Damit ist mir aber immer noch nicht klar, warum 160 dann wieder gleich ist :?

Außerdem decken sich deine Aussage nicht mit dem DocWiki:
http://docwiki.embarcadero.com/Libra...ystem.WideChar

Zitat:

... Die ersten 256 Zeichen des Unicode-Zeichensatzes entsprechen den ANSI-Zeichen...

[Uwe Raabe]

Zitat:

... Die ersten 256 Zeichen des Unicode-Zeichensatzes entsprechen den ANSI-Zeichen...

Da irrt das DocWiki :warn:

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1366659)

Zitat:

... Die ersten 256 Zeichen des Unicode-Zeichensatzes entsprechen den ANSI-Zeichen...

Da irrt das DocWiki :warn:

Kommt drauf an.

Ich weiß grade nicht welche, aber es gibt eine ANSI-CodePage, wo die ersten 256 Zeichen mit denen des Unicode übereinstimmen.

PS: Ich finde grade den Docwiki-Eintrag nicht, aber bei # muß man aufpassen.
#160 oder #0160 (kann sein, dass es nur bei Hexadezimal war)
#$ee oder #$00ee
Hier entscheidet der Compiler anhand der führenden 0, ob diese Konstante als ANSI oder Unicode interpretiert wird.
Bei ANSI kann es bei einer späteren Unicode-Konvertierung zu Problemen kommen und andersrum.


#85 ist da ein gutes Beispiel, wenn ich mich noch recht erinnere, wo sich AnsiChar(85) und WideChar(85) unterscheiden.

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1366682)

Hier entscheidet der Compiler anhand der führenden 0, ob diese Konstante als ANSI oder Unicode interpretiert wird.

Ach der Compiler entscheidet?
Und wenn es dem Benutzer/Programmierer nicht auffällt geht das solange bis es knallt, und dann kommt das Gegreine "es hat bis jetzt aber immer funktioniert".
das ist doch genauso ein Eiertanz wie der Blödsinn mit 16/32/64Bit für ein Integer.
warum nicht char8 oder char16 oder int16,int32,int64 und dann weiß ein jeder worum es geht. Und verschon mich bitte mit der "Abwärtskompatibilität", das erinnert mich immer an den Film mit Götz George.

Gruß
K-H

[himitsu]

Du entscheidest, wie du es hinschreibst und der Compiler macht das dann so. :angle:

Im Docwiki von 2009 kann ja jemand mal die Unicode-Einführung durchblättern ... da dürfte die Hilfeseite verlinkt sein.


PS: Es gibt im windows doch auch 'ne Tastenkombination wie AltGr + 0 + 1 + 6 + 0 (auf'm Ziffernblock), um Unicodezeichen einzugeben. (geht hier im Terminal grade nicht)
Laut Windows-Hilfe gibt es da auch diesen Unterschied zwischen Alt+160 und Alt+0160 :zwinker:

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1366682)

PS: Ich finde grade den Docwiki-Eintrag nicht, aber bei # muß man aufpassen.
#160 oder #0160 (kann sein, dass es nur bei Hexadezimal war)
#$ee oder #$00ee
Hier entscheidet der Compiler anhand der führenden 0, ob diese Konstante als ANSI oder Unicode interpretiert wird.
Bei ANSI kann es bei einer späteren Unicode-Konvertierung zu Problemen kommen und andersrum.

Das hängt auch von einer Compiler-Direktive ab: HIGHCHARUNICODE-Direktive (Delphi)

[himitsu]

Stimmt, die gab es auch noch.


Wem fällt was auf?

Zitat:

Werden alle dezimalen #$xx-Literale mit n Ziffern als AnsiChar analysiert.
Werden alle hexadezimalen #$xx-Literale mit zwei Ziffern als AnsiChar analysiert.
Werden alle hexadezimalen #$xxxx-Literale mit vier Ziffern als WideChar analysiert.

[p80286]

Wo hast Du denn den Schwachsinn her?

Gruß
K-H