Ascii oder Ansi

[egal]

Wie kann man erkennen, ob eine Textdatei in Ansi oder Ascii gespeichert ist?

[shmia]

Zitat:

Zitat von egal

Wie kann man erkennen, ob eine Textdatei in Ansi oder Ascii gespeichert ist?

Gar nicht!!
Man könnte untersuchen, ob die Datei häufig die Ansi-Zeichen äöüÄÖÜß enthält und dann darauf schliesen, dass es wohl der Ansi Zeichensatz ISO 8859-1 sein könnte, das ist aber keineswegs sicher.

[egal]

Zitat:

Zitat von shmia

Zitat:

Zitat von egal

Wie kann man erkennen, ob eine Textdatei in Ansi oder Ascii gespeichert ist?

Gar nicht!!
Man könnte untersuchen, ob die Datei häufig die Ansi-Zeichen äöüÄÖÜß enthält und dann darauf schliesen, dass es wohl der Ansi Zeichensatz ISO 8859-1 sein könnte, das ist aber keineswegs sicher.

Das ist schlecht. Ich habe eine Ascii-Datei und aus dieser Datei soll ich einige Sätze in eine neue Ascii-Datei speichern und am Ende wird der Text von neuer Datei in die Datenbank übertragen.
Bei der alten Datei umwandele ich Ascii in Ansi und meine Umlaute sind in der DB richtig gespeichert. Aber bei meiner selbsterzeugenen Ascii-Datei klappt es nicht, die Umwandlung hilft nicht, ich kriege meine Umlaute nie wieder.

[shmia]

Hier ist mal eine Hilfsunit, um diese Umwandlung in beide Richtungen zu bewerkstelligen:
http://www.delphipraxis.net/internal...=560752#560752
Jetzt kommt es darauf an, auf welche Art du die Datei einliest und speicherst (TStringList, TFileStream, readln/writeln).

[himitsu]

Wenn du selber für das Speichern der Dateien, oder zumindestens einer der Dateiversionen, verantwortlich bist, dann könntrst du dir ja ein Markerbyte an den Dateianfang setzen, welches dir eine unterscheidung ermöglicht ... so wie es z.B. bei UTF8-, UCS2-/UCS2LE-, UCS2BE- ...-Dateien der Fall ist.

[Olli]

Keine Ahnung was shmia's Antworten sollen, sie sind jedenfalls falsch. Umlaute sind in keinem Fall ein Teil von ASCII!

ASCII sind alle Zeichencodes von 0..127 womit du auch deine Antwort hast. Prüfe ob ein Zeichen mit Code größer 127 in der Datei enthalten ist. Ob dieses oder jenes drin ist, kann man nicht unterscheiden:

• ANSI hat 256 Zeichen und ASCII nur 128
• ANSI und ASCII sind auch kodierungsunabhängig für den ASCII-Bereich, den sie sich teilen, identisch.
• Nähmen wir mal an du meinst EASCII mit ANSI vergleichen: dann kommt es immer auf die Kodierung an, also darauf wie du es anzeigst (Kodierung ist eine Interpretationssache deines Programms!). Logischerweise haben die Zeichen alle noch Werte zwischen 0..255. Wie willst du die denn unterscheiden? Vielleicht mit OCR um herauszubekommen wie unterschiedliche Programme den jeweiligen Code ziwschen 0..255 anzeigen?

Du siehst, die Kodierung ist absolut deine Implementationssache und nichts was dir hier jemand irgendwie vorschreiben kann oder will. himitsu hat ganz recht mit seiner Empfehlung, entweder speicherst du einen Marker mit, oder du nimmst gleich einen der Unicode-Standards um deine Zeichen zu kodieren und bist dir damit sicher, daß sie von jedem (also auch deinem) Programm eineindeutig interpretiert werden.

[egal]

Zitat:

Zitat von shmia

Hier ist mal eine Hilfsunit, um diese Umwandlung in beide Richtungen zu bewerkstelligen:
http://www.delphipraxis.net/internal...=560752#560752
Jetzt kommt es darauf an, auf welche Art du die Datei einliest und speicherst (TStringList, TFileStream, readln/writeln).

Wie man umwandelt, das weiß ich, aber trotzdem danke für Link.
Ich arbeite mit readln/writeln, ist es falsch?

[egal]

Zitat:

Zitat von himitsu

Wenn du selber für das Speichern der Dateien, oder zumindestens einer der Dateiversionen, verantwortlich bist, dann könntrst du dir ja ein Markerbyte an den Dateianfang setzen, welches dir eine unterscheidung ermöglicht ... so wie es z.B. bei UTF8-, UCS2-/UCS2LE-, UCS2BE- ...-Dateien der Fall ist.

Ich könnte was in Dateiinfo schreiben(Titel, Kategorie usw.), aber wie, das weiß ich leider nicht :oops:

[egal]

Zitat:

Zitat von Olli

himitsu hat ganz recht mit seiner Empfehlung, entweder speicherst du einen Marker mit, oder du nimmst gleich einen der Unicode-Standards um deine Zeichen zu kodieren und bist dir damit sicher, daß sie von jedem (also auch deinem) Programm eineindeutig interpretiert werden.

Sieht so aus, dass ich auch Einleseprogramm ändern muss, das wollte ich eigentlich vermeiden, aber egal.
Mich interessiert eigentlich auch, warum werden meine Ascii-Datensätze in die Textdatei nicht richtig gespeichert.
Ich habe zuerst keine Umwandlung gemacht:

Delphi-Quellcode:

 var cZeile: string;
readln(txtFileAlt, cZeile);  // txtFileAlt-Ascii-Codierung
writeLn(txtFileNeu,cZeile);

Das hat nicht geholfen, beim Einlesen habe Ascii nach Ansi umgewandelt, aber statt Umlauten war Müll.
Dann habe ich zuerst nach Ansi konvertiert und beim Schreiben wieder nach Ascii:

Delphi-Quellcode:

 var cZeile: string;
readln(txtFileAlt, cZeile);  // txtFileAlt-Ascii-Codierung
cZeile := Ascii2Ansi(cZeile); // Ascii -> Ansi
cZeile := Ansi2Ascii(cZeile); // Ansi -> Ascii 
writeLn(txtFileNeu,cZeile);

Hat auch nichts gebracht.
Und jetzt die Frage, was mache ich falsch: Readln/Writeln oder vielleicht String-Variable schuld?

[Olli]

Zitat:

Zitat von egal

Mich interessiert eigentlich auch, warum werden meine Ascii-Datensätze in die Textdatei nicht richtig gespeichert.
Ich habe zuerst keine Umwandlung gemacht:

Delphi-Quellcode:

 var cZeile: string;
readln(txtFileAlt, cZeile);  // txtFileAlt-Ascii-Codierung
writeLn(txtFileNeu,cZeile);

Das hat nicht geholfen, beim Einlesen habe Ascii nach Ansi umgewandelt, aber statt Umlauten war Müll.
Dann habe ich zuerst nach Ansi konvertiert und beim Schreiben wieder nach Ascii:

Delphi-Quellcode:

 var cZeile: string;
readln(txtFileAlt, cZeile);  // txtFileAlt-Ascii-Codierung
cZeile := Ascii2Ansi(cZeile); // Ascii -> Ansi
cZeile := Ansi2Ascii(cZeile); // Ansi -> Ascii 
writeLn(txtFileNeu,cZeile);

Hat auch nichts gebracht.
Und jetzt die Frage, was mache ich falsch: Readln/Writeln oder vielleicht String-Variable schuld?

Ähem, irgendwie kapiere ich noch immer nicht, wo es hängt. Warum kannst du nicht verstehen, daß in deiner Datei auch für jedes Zeichen 8bit benutzt werden und damit jedes Zeichen einen Wert von 0..255 hat?! ... und daß die Darstellung dieser jeweils 256 unterschiedlichen Entitäten allein dem lesenden Programm obliegt (bzw. beim Lesen und Speichern die "Abbildung" von Code zu darzustellendem Zeichen und umgekehrt).

Nur weil █ (Unicode-Zeichen $2588, EASCII-Zeichen $DB bei westeuropäischer DOS-Kodierung) unter DOS als "voller Block" erscheint, heißt das nicht, daß es unter einer anderen Kodierung (ANSI-westlich $DB == Û) genauso sein muß. Nochmal: nimm Unicodezeichen, wenn du das Erscheinungsbild der Zeichen eineindeutig festlegen willst.

Nebenbei gibt es dir "Bearbeiten"-Funktion für Beiträge, man muß also nicht jedes Mal einen neuen Beitrag verfassen (insbesondere so zeitnah).

[egal]

Zitat:

Zitat von Olli

Ähem, irgendwie kapiere ich noch immer nicht, wo es hängt. Warum kannst du nicht verstehen, daß in deiner Datei auch für jedes Zeichen 8bit benutzt werden und damit jedes Zeichen einen Wert von 0..255 hat?! ... und daß die Darstellung dieser jeweils 256 unterschiedlichen Entitäten allein dem lesenden Programm obliegt (bzw. beim Lesen und Speichern die "Abbildung" von Code zu darzustellendem Zeichen und umgekehrt).

Nur weil █ (Unicode-Zeichen $2588, EASCII-Zeichen $DB bei westeuropäischer DOS-Kodierung) unter DOS als "voller Block" erscheint, heißt das nicht, daß es unter einer anderen Kodierung (ANSI-westlich $DB == Û) genauso sein muß. Nochmal: nimm Unicodezeichen, wenn du das Erscheinungsbild der Zeichen eineindeutig festlegen willst.

Irgendwie verstehe ich deine Antwort nicht, was hat es mit meiner Frage zu tun?

[himitsu]

Es ist doch einfach.
Nur das Programm, welches die Daten erstellt (und vielleicht wieder ließt) entscheidet/weiß 100%ig was für ein Format die Daten in der Datei haben.

ANSI und ASCII sind halt nur Interpretationen der BYTEs (8-Bit-Daten).

Wenn also keine Definition (um welche Daten es sich genau handelt) in der Datei vorhanden sind, dann gibt es keine sichere Möglichkeit zu prüfen um was es sich handelt.


Für reine Textdateien sind aber auch schon verschiedene Markerbytes definiert:
kein Markerbyte am Dateianfang = ANSI
$FF $FE am Dateianfang = UniCode (Low Endian)
$FE $FF am Dateianfang = UniCode (Big Endian)
$FF $FE $00 $00 am Dateianfang = UniCode4 (Low Endian)
$00 $00 $FE $FF am Dateianfang = UniCode4 (Big Endian)


Du kannst es dir so vorstellen ... man nehme Byte, aber wie willst du entscheiden, was in diesem Byte steckt?
ShortInt, Byte, AnsiChar, ASCII-Char, UTF8-Char, Boolean, Set ...

[xaromz]

Hallo,

Zitat:

Zitat von himitsu

Für reine Textdateien sind aber auch schon verschiedene Markerbytes definiert:
kein Markerbyte am Dateianfang = ANSI
$FF $FE am Dateianfang = UniCode (Low Endian)
$FE $FF am Dateianfang = UniCode (Big Endian)
$FF $FE $00 $00 am Dateianfang = UniCode4 (Low Endian)
$00 $00 $FE $FF am Dateianfang = UniCode4 (Big Endian)

Da fehlt noch:
$EF $BB $BF am Dateianfang = UTF8

Gruß
xaromz

[himitsu]

Jupp, hatte es nur nicht mehr im Kopf -.-''
Und natürlich gibt es noch mehr, aber das sind dann wohl erstmal die Markerbytes, welche von den meisten Programmen erkannt werden (abgesehn vom UCS4)

[Olli]

War UCS nicht inzwischen zugunsten von UTF "deprecated" deklariert worden (also alle UCS)?!

Nachtrag: Hah, ich habe eine Idee. "egal", versuche mal folgendes: öffne eine Bitmap-Datei mit deinem Lieblings-Bildbetrachter. Danach öffne die gleiche Datei mit Notepad und danach, insofern vorhanden, mit einem Hexeditor. Was siehst du? Richtig, die gleichen Daten, aber unterschiedlich repräsentiert. Und die Repräsentation ergibt sich daraus wie die Informationen/Daten dekodiert wurden.

[Olli]

Das habe ich in einer PM an himitsu geschrieben:

Ich glaube deswegen meine Aussage. Allerdings trog mich wohl meine Erinnerung. Die Aussage gilt nur für UCS-2 in Relation zu UTF-16 (macht ja Sinn). Also nicht UCS sondern UCS-2 sollte nicht mehr benutzt werden, weil ja in UTF-16 die Surrogates (zusammengesetzte Codes) dazugekommen sind.

Meine obige Aussage zu "allen UCS" trifft also nicht zu. Gemeint ist, daß UCS-2 nicht mehr benutzt werden soll (auch als Begriff), weil in UTF-16 Surrogates eingeführt wurden, die eben dann mehr als 2 Byte pro Zeichen lang sind ... deswegen wäre "Unicode Character String 2 Byte" (UCS 2) falsch.