Laden...

UTF-8: Merkwürdigkeiten, je nachdem, wie Programm aufgerufen wird.

Erstellt von pollito vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.223 Views
pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren
UTF-8: Merkwürdigkeiten, je nachdem, wie Programm aufgerufen wird.

Hallo,

ein selbst erstelltes Programm verarbeitet eine Datei, welche beim Aufruf als Parameter übergeben wird.

Die Übergabedatei wird von einer anderen Anwendung erstellt – Team Developer 6.2 mit Ziel Win32 Application (Früher SQLWindows von Gupta).

Wenn ich mir die zu übergebende Datei anschaue, ist diese in UTF-8 mit BOM codiert, was auch richtig und gewollt ist.

Die selbst erstellte C#-Anwendung öffnet die Datei mit "Encoding.UTF8" zum Lesen, holt sich die darin befindliche Info in Variablen rein und schließt sie.

Unter bestimmten Bedingungen müssen an die Datei Informationen angehängt werden. Dazu wird sie erneut mit "Encoding.UTF8" geöffnet, diesmal aber zum Schreiben (Anhängen):

sw = new StreamWriter(new FileStream(ParFile, FileMode.Append, FileAccess.Write, FileShare.Read), Encoding.UTF8);

Nun werden Werte in die Datei geschrieben u. a. Umlaute und andere "Sonderzeichen". Schaue ich mir die Datei jetzt an, so ist sie immer noch in UTF-8 mit BOM codiert und alles sieht gut aus.

Und jetzt die Merkwürdigkeit:
1.Rufe ich das selbst erstellte Programm mit der Übergabedatei von der Kommandozeile oder von Visual Studo aus auf, wird diese richtig verarbeitet. Sowohl übergebende Umlaute als auch angehängte werden richtig dargestellt und alles ist OK.

1.Lasse ich das Programm von einer mit "Team Developer" erstellten Anwendung aufrufen, so sind die zurückgeschriebenen Umlaute falsch: Die Datei ist immer noch UTF-8 mit BOM codiert, aber die angehängten Umlaute und andere "Sonderzeichen" werden ANSI-Codiert dargestellt.

In beiden Beispielen ist die Übergabedatei dieselbe (von der "Team-Developer-Anwendung" erstellt)..

In beiden Beispielen wird die Übergabedatei vom gleichen C#-Programm verarbeitet.

Der einzige Unterschied besteht im Aufruf: 1) Im ersten Fall von der Kommandozeile bzw. VS aus und 2) im zweiten von der "Team Developer-Anwendung".

Wenn ich testhalber in einem beliebigen Editor die Codierung auf ANSI bzw. Windows 1252 umstelle, wird die angehängte Information richtig dargestellt, die Übergebende allerdings falsch. Um das zu zeigen, füge ich zwei Bilder hinzu, denn die Forensoftware filtert mir ein teil raus:

(Zweites Bild im nächsten Beitrag.)

Wie ist das zu erklären?

Danke und viele Grüße

René

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

Zweites Bild:

René

16.807 Beiträge seit 2008
vor 4 Jahren

Wird mit Sicherheit nicht so sein, wie Du denkst.
Encoding kann nicht sicher erkannt werden - auch nicht von VSCode oder Notepad.

Als wir das Forum migriert haben, hatten wir ähnliches (und haben an manchen Stellen auch noch nicht alles fixen können).
Die Dateien wurden zwar als UTF-8 angezeigt, waren aber mit Windows 1252 encodiert.

Wir haben mittlerweile die meisten Stellen gefunden, aber nicht alle.
Lösung war stehts: Datei nochmals mit einem anderen Encoding öffnen und neu speichern mit dem Zielencoding.
Grund: das Encoding war nicht das, was es suggeriert hatte.

Die Differenz der beiden Sections sieht für mich so aus, dass in der Datei selbst auch mit unterschiedlichen Encodings geschrieben wurde.
Dann passiert nämlich genau das.

pollito Themenstarter:in
314 Beiträge seit 2010
vor 4 Jahren

Ja, da gebe ich dir recht. In diesem Fall ist es aber so, dass die zu verarbeitende Datei immer dieselbe ist. Daher erwarte ich, wenn diese vom gleichen Programm verarbeitet wird, dass das Ergebnis auch immer gleich ist – das ist aber nicht der Fall.

Das Programm interpretiert die Datei nicht, sondern es verarbeitet sie explizit mit "Encoding.UTF8". Der einzige Unterschied ist der Programmaufruf, wie bereits beschrieben. So drehe ich mich gedanklich im Kreis.

Ich werde das mit Team Developer erstellte rufende Programm in den Debugger werfen und mich bis zum Programm durchstepen, das die Datei verarbeitet. Das kann aber etwas länger dauern. Dennoch geht mir das alles nicht in die Birne rein.

Nochmals schönen Dank!

René