ForumKWrite KEdit Kate und binäre Daten
Roland M. Egloff – Dienstag, 17. Juni 2008 23:08 Uhr

Das folgende gilt für Suse 10.2 (und älter).

Ich habe eine Frage welche immer wieder auftaucht und auf die ich
keine Antwort finde. Kann mich bitte jemand aufklären — ich wäre
sehr dankbar.

Es gibt Text Dateien (z.B. *.txt oder *.html) welche Bytes enthalten
(vielleicht nur eines) die einen Wert grösser als octal 177 haben.
Solche Bytes könnten zum Beispiel Unicode codierte Zeichen sein
(zwei oder mehr aufeinander folgende solche Bytes), oder etwa
einzelnes Byte welches für einen speziellen Font (nicht Unicode)
gebraucht werden (z.B. Griechisch).

Wenn ich eine solche Datei mit einem der K-Desktop Text Editoren
öffne (KWrite, KEdit, Kate), dann ist folgendes möglich:

-1- der Editor erkennt die Unicode Bytes, stellt diese auf dem
Bildschirm korrekt dar, und speichert die Datei auch ohne Probleme.

-2- der Editor öffnet ein popup Fenster und indormiert dass:

———————————————
The file file:///home/user0/xyz is a binary,
saving it will result in a corrupt file.
———————————————

-3- der Editor erkennt Bytes grösser als oct 177 nicht, stellt
solche Bytes auch nicht dar (wie wenn sie nicht existierten), und
beim abspeichern gehen diese Bytes verloren.

-4- der Editor verändert beim abspeichern solche Bytes (ohne irgend
welche Info an den User).

Sowohl -3- wie auch -4- sind natürlich echt problematisch und im
Fall -2- ist meine Frage: warum denn?

Ich habe solche “Problem Dateien” mit anderen Editoren geöffnet und
wieder abgespeichert — immer ohne Probleme (z.B. GEdit, Emacs, vim,
etc., sogar OpenOffice — kein Problem).

Also die Frage: warum können KWrite, KEdit und Kate (und nur
diese!!!) die Dateien beim abspeichern nicht so lassen wie sie sind?
Wie kommt es, dass ein Editor von sich aus Daten verändert? Wie
gesagt, nur K Editoren tun dies!

Falls jemand ein Beispiel ausprobieren möchte:

Einfach eine Datei erstellen welche etwa aus folgenden acht Bytes
besteht: (alle Werte sind octal)

141 316 243 316 246 142 252 143

141 = ascii ‘a’
316 243 = utf-8 codiertes Griechisches Sigma
316 246 = utf-8 codiertes Griechisches Phi
142 = ascii ‘b’ 251 = (hex a9, dez 169) = Copyright-Zeichen (c im Kreis)
143 = ascii ‘c’

Wenn diese Datei mit KWrite, KEdit oder Kate abgespeichert wird
(ohne irgend welche Edits) geht das ‘251’ Byte verloren. Warum?

Vielen Dank für jede Information (ich möchte einfach verstehen).

Gruss,
Roland

1 Antwort
Günter Frenz – Donnerstag, 19. Juni 2008 19:34 Uhr

Hallo,

du versuchst, in dieser Datei zwei verschiedene Zeichsatz-Codes zu mischen. Das Copyright-Zeichen wäre nach deiner Notation im ISO8859-1 Code, während die beiden griechischen Buchstaben im UTF-8 Code vorliegen. Das kann man so in einer Datei nicht speichern und erwarten das beim nächsten öffnen alles perfekt angezeigt wird. Der eingestellte Zeichensatz-Code gilt immer für eine ganze Datei, bei Einstellung UTF-8 werden eben nur die dort definierten Zeichen korrekt angezeigt, alles andere produziert Fehler, in deinem Fall eben die fehlende Anzeige. Bei Einstellung ISO8859-1 würde das Copyright-Symbol korrekt dargestellt und für die beiden anderen Zeichen würden je zwei Zeichen aus dem ISO-Zeichensatz erscheinen.

Die anderen Editoren versuchen wahrscheinlich etwas mehr zu raten, welche Codierung gemeint sein soll, aber ob das immer gut geht, ist schwer vorher zu sagen.

Fazit: in einer Datei immer nur einen Zeichensatz verwenden, sonst gibt es immer nur Chaos. Es gibt auch Programme zum automatischen Umcodieren ganzer Dateien, wie z. B. recode

Günter

Roland M. Egloff – Donnerstag, 19. Juni 2008 20:48 Uhr

Hallo Günter,

Vielen Dank für Deine Erläuterungen.

Ich habe das Problem vielleicht zuwenig präzis beschrieben. Es geht
nicht darum ob ein Editor oder Browser irgendwelche Daten auf dem
Bildschirm korrekt anzeigt — natürlich hat dies mit dem jeweiligen
Zeichensatz zu tun und ob dieser (oder diese, falls eine Mischung)
vom Editor/Browser erkannt werden.

Das Problem welches ich angesprochen habe hat ausschliesslich damit
zu tun wie ein Editor Daten liest und wieder abspeichert. Dies hat
nichts mit etwelchem Zeichensatz zu tun.

Ein Editor soll Daten so lesen und auch wieder so abspeichern wie
sie eben sind. Das tun auch alle von mir getesteten Editoren (GEdit,
Emacs, vim, etc., auch OpenOffice, etc.) — alle ausser den KDE
Editoren KWrite, KEdit und Kate.

Wenn eine Datei ein Byte grösser als octal 177 hat, z.B.

octal 251 = (hex a9, dez 169) = Copyright-Zeichen (c im Kreis)

dann sollte der Editor dieses Zeichen auch so wieder abspeichern.
Ob der Editor das Zeichen auf dem Bildschirm darstellen konnte oder
nicht spielt keine Rolle. Ein Editor darf Daten beim abspeichern
nicht verändern! — genau dies tun aber die K-Editoren, und nur
diese!!!

Ich habe schon mehrmals Dateien vom Web heruntergeladen, dann mit
dem KWrite geöffnet (um z.B. die Herkunfts-Adresse hinein zu editieren),
und habe dann festgestellt, dass nach dem abspeichern die Datei
fehlerhaft war (z.B. alle Umlaute wurden durch nicht mehr
interpretierbare Bytes ersetzt — zu keiner Kodierung passend).

Das darf doch nicht sein! Ein Editor darf doch nicht selber Daten
verändern! Dies hat mit eingestelltem Zeichensatz nichts zu tun.

Ein Beispiel, diesmal ohne Unicode Zeichen:

141 252 142 (octal Werte)

141 = ascii ‘a’
251 = (hex a9, dez 169) = Copyright-Zeichen (c im Kreis)
142 = ascii ‘b’

Beim abspeichern mit K-Editoren geht das mittlere Byte verloren.

Viele Grüsse,
Roland.

Günter Frenz – Sonntag, 22. Juni 2008 13:29 Uhr

Hallo,

die K-Editoren bieten die Möglichkeit, den Zeichensatz zum Lesen und Schreiben von Dateien individuell einzustellen. Wenn ich also “a©b” in ISO-8859-15 gespeichert habe und die Datei mit Editor-Einstellung UTF-8 öffne, kann 0xa9 nicht interpretiert werden und wird durch ein Ersatz-Symbol dargestellt (bei mir ein leeres Quadrat). Beim Speichern mit Einstellung UTF-8 wird dann dieses Ersatz-Symbol in UTF-8-Codierung in die Datei geschrieben.

Wenn du eine Datei mit den falschen Einstellungen öffnest, ist dieses Verhalten natürlich unschön. Wenn du die Datei mit den richtigen Einstellungen öffnest, kannst du sie aber später mit veränderten Einstellungen wieder speichern und damit umcodieren. Wenn man dieses Verhalten der Software kennt, kann man das durchaus sinnvoll nutzen.

hth

Günter

Roland M. Egloff – Sonntag, 22. Juni 2008 14:51 Uhr

Hallo Günter

Danke für Deinen Beitrag.

Das Problem ist eben dass:

-1- wenn ich eine Datei vom Internet herunterlade weiss ich generell nicht
was dessen Codierung ist — ich kann also den Editor auch nicht entsprechend
einstellen.

-2- es gibt viele Dateien welche mehr als eine Codierung (gleichzeitig)
verwenden. Siehe zum Beispiel wiki Dateien welche Deutsch geschrieben sind
(ISO 8859-x) und zudem Griechischen Text enthalten (geschrieben in utf-8
und/oder Windows-1252 (od. ‘CP1252’) und/oder Delta-Code (Ref 1)
— Dateien mit gemischter Codierung sind nicht selten (Ref 2)!

-3- ich wiederhole mich: ein Editor darf Dateien nicht von sich aus verändern.
So wie die Datei original ist, so soll diese auch wiedr abgespeichert werden.
Da gibts (meine Meinung) kein wenn und aber. Eine etwelche Einstellung
(Konfiguration) des Editors sollte allenfalls dazu dienen die Bytes korrekt
darzustellen, aber keinesfalls deren Abspeicherung beeinflussen.

-4- das Problem existiert ja nur und ausschliesslich mit K-Editoren. Alle (!!!)
anderen Editoren verhalten sich so wie dies erwartet wird.

Danke nochmals,
Roland

———-
Refs.:

1: http://en.wikipedia.org/wiki/Beta_code

2: z.B. ein Byte mit dem Wert 913 (dezimal) ist ein griechisches ‘aplha’
oder 333 (dezimal) ist ein o mit Strich darüber (macron)
(solche Bytes machen Probleme mit K-Editoren — und nur K-Editoren).

-/-