Mein lieber Valigator

[dedlfix]

Hi!

Also meiner Meinung nach, spielt die Kodierung beim erstellen einer Datei null eine Rolle. Ein Byte ist einfach eine Zahl von 0 bis 255.
Warum soll die Kodierung keine Rolle spielen? Irgendwo muss doch festgelegt sein, wie ein Zeichen in Bytes repräsentiert werden soll.
Genau, repräsentiert => dargestellt werden.

Darstellen kann man auf zwei Arten verstehen. Einmal im indirekten Sinne von "ein Stellvertreter/Repräsentant von etwas" (zum Beispiel Schauspieler) und einmal das Schreiben, Zeichen, Ausgeben auf einem Medium (Papier, Bildschirm).

Ich habe hin und her überlegt, wie ich es am besten formuliere, weil es letztlich doch das gleiche ist. Ich meine beim indirekten Darstellen etwas, das man erst noch (mit gewissem Aufwand) interpretieren muss, um den Sinn zu verstehen und beim direkten Darstellen, etwas das man "nur lesen muss", weil man Lesen mittlerweile perfekt kann.

Wenn du solche Sätze wie den folgenden schreibst, welches Darstellen soll man da nun annehmen, das indirekte wie bei repräsentieren oder das Zur-Anzeige-Bringen?

Also für mich sind Dateien Folgen von Bytes mit keinerlei Kodierung. Diese kommt erst bei der Darstellung zum tragen.

In der Reihenfolge "Datei -> Darstellung" lese ich das als Zur-Anzeige-Bringen. Du willst es aber als Repräsentieren verstanden wissen? Und wenn du dann auch noch weiter vorn im Thread die andere Bedeutung nimmst, ...

das was du siehst, also die Darstellung

... ist man möglicherweise, so wie ich, beim Interpretieren erst mal auf dem Holzweg.

Aber zurück zum Thema. Ich verstehe nicht, warum du dem Dateiinhalt eine Bedeutung absprechen willst, wenn du doch nicht nur Transporteur sondern Interpretierender bist.

Aber, um dein Beispiel fortzuführen, wenn ich die obige [Text-]Datei mit meinem Editor einlese kann er versuchen zu erkennen in welcher Kodierung diese vorliegt, das wird aber bei dem Zeichen 80 schwer fallen. Im DOS Fenster ist es ein Ç in einem utf-8 HTML Dokument ein Fragezeichen. Die Datei enthält im Prinzip keinerlei Informationen über die Kodierung.

Ich habe nicht gemeint, die Datei enthielte eine Information über ihre Kodierung sondern nur, dass sie mit Hilfe einer Kodierung(svorschrift) ihr Inhalt erstellt worden ist.

Die ergibt sich erst aus dem Kontext, wie du es in deinem Artikel auch schriebst.

Die Kodierung ergibt sich auch nicht, sie ist bereits da, weil sie beim Schreibvorgang verwendet wurde. Was hat eigentlich mein Artikel damit zu tun? Konkret: welche Stelle? Er ist ja nicht gerade kurz. Und eigentlich ignoriert er das Thema Kodierung, weil es einerseits zu komplex ist und andererseits damit das Verständnis seines eigentlichen Themas nicht einfacher wird.

Man dekodiert/interpretiert einen Dateiinhalt gemäß einer Kodiervorschrift. ("Kodiervorschrift" steht hier für eine Vorschrift die den Prozess in beide Richtungen beschreibt).
Also für mich sind Dateien Folgen von Bytes mit keinerlei Kodierung. Diese kommt erst bei der Darstellung zum tragen.

"Mit keinerlei Kodierung" soll man so lesen, dass lediglich keine Information zur verwendeten Kodierung vorliegt? Und bei Darstellung ist Interpretation (sinnerhaltendes Lesen) gemeint, nicht das Zur-Anzeige-Bringen-Darstellen? Bei der Lesart könnte ich dem zustimmen.

Diese Folge von Bytes ist doch aber nicht willkürlich. Die Bytes repäsentieren Text, sie sind kodierter Text. Wenn ich sie sinnerhaltend weiterverarbeiten will - vielleicht zum späteren Ausgeben - muss ich die Kodierung (in umgekehrter Richtung) berücksichtigen, so dass wieder das Zeichen daraus wird, was beabsichtigt war.
genau: Die Darstellung, du  sprichst ja nur von Texten, es gibt aber auch z.b. Bilder, auch diese Dateien kannst du mit deinem Editor öffnen und bekommst je nach dem was der Editor macht eine laut piepsende Ausgabe. Es ist aber nicht erkennbar, dass es ein Bild ist.

Bilder und andere Nicht-Text-Inhalte sind eigentlich nicht im Fokus meiner Argumentation. Aber ja, wenn ich einen Inhalt falsch interpretiere, kann ich ihn nicht sinnerhaltend wiedergeben / zur Anzeige bringen (darstellen).

Willst du etwa den Sinn und die Bytefolge voneinander trennen?
Natürlich, es spielt ja auch keine Rolle, du kanst auch jedes Textdokument in irgendeiner Kodierung darstellen lassen, siehst halt andere Zeichen. Obn es richtig ist, erkennt erst der Mensch der sie lesen muss.

Die Formulierung "jedes Textdokument in irgendeiner Kodierung darstellen lassen" missfällt mir, weil ich damit assoziiere, dass der Text _in_ eine Kodierung gebracht wird, und nicht die Datei _als_ etwas interpretiert wird oder gemäß $kodierung gelesen/interpretiert/dekodiert wird. Und dass die Bytefolge keine Rolle spiele, leuchtet mir immer noch nicht ein. Denn dann könnte ich eine Datei mit lauter FF-Bytes füllen und dem Leser sagen, er müsse es einfach nur richtig interpretieren. Ich muss als Quelle schon sinnerhaltend kodieren und am anderen Ende gleichermaßen dekodieren.

Nach dem Satz glaube ich wir meinen doch das gleiche, drücken es nur anders aus. Das Programm, dass eine Bytefolge darstellen muss braucht eine Dekodierungsvorschrift.
Eben. Die Umkehrfunktion zur verwendeten Kodierung.
Die aber nicht notwendigerweise in der Datei ersichtlich ist.

Ja, ihr Name oder ein anderer Hinweis auf die Kodierung ist oftmals nicht in Dateien enthalten, in einfachen Text-Dateien praktisch gar nicht, jedenfalls nichts standardisiertes. Aber ihr Inhalt ist etwas, das sich aus dem Ausgangstext und der Kodierung ergibt.

Wenn ich in meinem Editor eine Datei öffne gibt es erstmal keine Kodierung, sie spielt also beim lesen keine Rolle. Sie spielt erst eine Rolle, wenn die Zeichen interpretiert werden sollen und das ist für mich darstellen.

An dieser Stelle trennst du Dinge unnötig auf, scheint mir. Die allgemeine Betriebssystemfunktion zum Lesen aus Dateien liest natürlich Bytes ohne deren Sinn zu "hinterfragen". Das passiert aber einer Ebene, die unterhalb der betrachteten liegt. Der Editor, der den Bytestrom entgegennimmt, muss selbstverständlich die Datei dekodieren um sie in eine Form zu bringen, mit der er intern arbeiten kann. Er kann sie auch noch dreimal uninterpretiert im Speicher umlagern, aber das bringt uns als außenstehender Betrachter nicht weiter. Er muss jedenfalls schon für die interne Verarbeitung den Sinn der Zeichen kennen, und nicht erst dann, wenn er sie an die (Bildschirm-)Ausgaberoutine weitergibt. Wie soll er sonst Wortgrenzen oder Zeilen oder sowas erkennen?

Das tut er, weil entweder er weiß, das z.b. eine .txt Datei in diesem windows-1252 Kodierung vorliegt oder du musst es dem Editor explizit sagen.

Also spielt es doch eine Rolle, in welcher Kodierung der Dateiinhalt vorliegt, denn genau die brauche ich, um den Inhalt zu interpretieren.

Schreib mal einen Text mit Umlauten in einem DOS Editor und schon merkst du, dass es dem Bytestrom an sich egal ist, du musst dem Editor sagen wie er zu dekodieren hat, damit die Darstellung dem entspricht was du erwartest.

Dem Bytestrom ist es egal, weil er nur Transporteur ist. Mit ist es aber nicht egal, wie er aussieht, weil ich ihn wieder lesen muss. Zunächst muss ich dem Editor sagen, wie er den Text beim Schreiben zu kodieren hat. Und sei es, dass der Progammierer ihm das in Form einer Default-Einstellung implementiert hat. Dann kann ich auch beim Öffnen sagen, was er zum Dekodieren zu nehmen hat, damit ich den Text wiederbekomme und keinen Zeichensalat. Zur Not nimmt der Editor wieder die gleiche Default-Einstellung. Wenn es egal wäre, was der Editor schreibt, könnte er ja auch nur FF-Bytes schreiben. Da werde ich aber kaum eine Chance haben, den Text wiederzusehen, egal welche Kodierung ich dem Editor zum Interpretieren nenne.

Lo!