|
Anzeige
|
Speicherung in Textdatei
Gast
#4729123
Hallo, mal eine doofe Frage bzgl. einer Speicherung von Daten in einer Textdatei. Liegen da einfach Bytes hintereinander weg, oder wie funktioniert das? Vermutlich belegt dann ein \n sowie \cr ebenfalls eine 1 Byte große Speicherzelle? Wie erkennt man das Ende einer Textdatei bzw. die Länge?
Gast
#4729125
Da gibt es viele Möglichkeiten. Z.B. als Hexadezimalzahlen, die man einfach hintereinander schreibt. Will man auch mal drin lesen, kann man sie mit Leerzeichen voneinander trennen und nach einer gewissen Anzahl \r\n einfügen. Beim Lesen der Daten wird alles, was nicht '0'...'9' und 'a'...'f', oder 'A'...'F' ist, ignoriert. Die Länge erkennen? Ist vom Betriebssystem und dessen Standardroutinen für den Umgang mit Dateien abhängig...
Gast
#4729131
Nachsatz: Zur Erkennung des Endes kann man natürlich auch ein spezielles Zeichen verwenden. Ansonsten gibt es auch einige Standard-Dateiformate dafür: AVR-Programmer haben dafür die *.hex Datei.
Gast
#4729133
Textus schrieb: > Wie erkennt man das Ende einer Textdatei bzw. die Länge? Über die entsprechende Funktion des Betriebssystems. zB fstat und feof unter Linux.
Gast
#4729134
Textus schrieb: > Liegen da einfach Bytes hintereinander weg, oder wie funktioniert das? Vergiß nicht, daß es auch noch UTF-8 und so gibt. Also pro Buchstabe ein Byte, das war im letzten Jahrtausend mal so, als man noch ASCII und Codepages und sowas hatte. Und dann nicht beispielweise griechische Schrift zugleich mit hebräischer in einer Textdatei darstellen konnte, weil die Schriften in inkompatiblen Codepages waren. Wenn man das aber mal alles ignoriert, ebenso wie Umlaute und so, und so tut, als wäre man ein Ami im 20. Jahrhundert, für den alles außerhalb der USA eine Mischung zwischen weißen Flecken auf der Landkarte darstellt und allgemeinen Bildungslücken darstellt, dann ist jeder Buchstabe ein Byte. Mit Zeilenende - DOS/Windows macht das als \r\n, also zwei Bytes. Unix hingegen nimmt nur \n, also ein Byte. Das ist lustig, wenn man Unix-Dateien unter Windows mit Notepad liest, weil keine Zeilenumbrüche erkannt werden. Umgedreht ist das auch lustig, weil je nach Programm dann jeder Zeilenumbruch zweimal auftauchen kann, wenn man nicht vorher mit dos2unix konvertiert.
Gast
#4729137
ok, dann mal eine weitere Frage: Wo finde ich denn Material, welche Header(?) und für welche Dateitypen zulässig und ggf. notwendig sind und wie ich die Dateien damit aufbauen muss? Eine Textdatei erscheint mir da als einfaches Beispiel, aber auch hier muss ja z.B. irgendwie / irgendwo das Ende definiert sein, bzw. so eine Funktion Fopen und Fclose nd wie sie alle heißen müssen ja irgendwie definiert sein, was dann eigentlich passiert. Unter CP/M endet eine Datei mit ^Z, weil das Dateisystem nur Vielfache von 128 Byte-Sektoren abbilden kann. Das war um 1979 rum. Seitdem kennt dein Betriebssystem die bytegenaue Länge einer jeden Datei - die steht nämlich im Dateisystem. Eine Datei verhält sich wie ein Array aus Bytes. Es gibt keine Möglichkeit, den Typen einer Datei zu erfragen, ohne in die Datei hineinzuschauen. Und selbst, wenn du hineinschaust, wirst du keine 100%ige Sicherheit über den Typ haben. Einen Universalheader gibt es nicht.
Gast
#4729140
Wo? Früher nahm man schlaue Bücher, heute hilft auch oft eine Internetsuche mit schlau gewählten Suchbegriffen. Ganz ohne Hirnschmalz geht's leider auch heute noch nicht...
Gast
#4729199
Textus schrieb: > Wie erkennt man das Ende einer Textdatei bzw. die Länge? Was genau ist für dich alles eine Textdatei? Textus schrieb: > aber auch hier muss ja z.B. irgendwie / irgendwo das Ende definiert sein, Das Dateisystem verwaltet das. Das weiß aufs Byte genau, wie lang eine Datei ist, egal, was drinsteht. Archaische Dateisysteme wie das weiter oben schon angesprochene CP/M konnten das nicht, da brauchte man Dateieendesteuerzeichen. Aber solche Systeme sind schon ein paar Jahrzehnte lang faktisch tot. Textus schrieb: > mal eine doofe Frage bzgl. einer Speicherung von Daten in einer > Textdatei. > Liegen da einfach Bytes hintereinander weg, oder wie funktioniert das? Im Prinzip liegen doch in Dateien immer "einfach Bytes hintereinander weg". > Vermutlich belegt dann ein \n sowie \cr ebenfalls eine 1 Byte große > Speicherzelle? Das kommt auf die Codierung an. Stichworte für Google sind hier ASCII, UTF-8, UTF-16 und Unicode. UTF-16 beispielsweise nutzt immer zwei Byte pro Zeichen, während ASCII und UTF-8 mit einem Byte auskommen. Es gibt auch noch UTF-32, das nutzt sogar vier Byte pro Zeichen. Textus schrieb: > Wie erkennt man das Ende einer Textdatei bzw. die Länge? Im einfachsten Fall ließt man ein Zeichen nach dem anderen ein und schaut ob es sich dabei um ein "EOF" ("end of file") handelt. Das kommt eben aber auch auf die Codierung an. Textus schrieb: > Liegen da einfach Bytes hintereinander weg, oder wie funktioniert das? > Vermutlich belegt dann ein \n sowie \cr ebenfalls eine 1 Byte große > Speicherzelle? So ist es. Textus schrieb: > Wie erkennt man das Ende einer Textdatei bzw. die Länge? Wie bei jeder anderen Datei auch, aus den Informationen im Verzeichniseintrag. Das OS unterscheidet nicht, ob doc, zip, mp3, exe, bat usw. Windows enthält eine Liste, wie eine Datei mit welcher Endung vorzugsweise zu behandeln ist. Du kannst aber auch z.B. eine mp3 mit einem Texteditor öffnen, nur wirst Du dann nichts hören.
Gast
#4729530
Textus schrieb: > welche Header(?) und für welche Dateitypen > zulässig und ggf. notwendig sind Im Gegensatz zu vielen anderen Dateitypen haben Textdateien keinen Header, sie fangen einfach mit dem ersten Byte an (und hören mit dem letzten auf). Allgemeine Definitionen gibt es nicht, weil alle Dateitypen von irgendeinem Programmierer mal festgelegt wurden, das sind keine Normen, und viele Dateidefinitionen sind auch garnicht offengelegt (wahrscheinlich die meisten). Wenn du selbst ein Programm schreibst, das was speichert, steht es dir frei, dir den Aufbau der Datei ganz und gar selbst auszudenken. Für viele wichtige Dateitypen, z.B. .exe, findet man Unterlagen im Internet, für so etwas wie eine Word-Datei dagegen eher nicht oder jedenfalls nicht vollständig. Georg
Gast
#4729574
Vielleicht zielt die Frage auch darauf ab, wie Dateien im Filesystem gespeichert werden. Also Blöcke und so.
Gast
#4729711
Georg schrieb: > Im Gegensatz zu vielen anderen Dateitypen haben Textdateien keinen > Header, sie fangen einfach mit dem ersten Byte an (und hören mit dem > letzten auf). https://de.wikipedia.org/wiki/Byte_Order_Mark Man kann sich natürlich darüber streiten, ob das nun (auch) ein "Header" ist oder nicht.
Gast
#4729754
Textus schrieb: > Liegen da einfach Bytes hintereinander weg, oder wie funktioniert das? wie sonst, holistisch? > Wie erkennt man das Ende einer Textdatei bzw. die Länge? Markierungen Vorzählen/Mitzählen beim Einlesen Adressenbegrenzung/Arrays Datenformate manchmal auch gar nicht z.B. Pufferüberlauf, Stackoverflow (nicht die Internetseite) wertvolle Internetseite zu dieser Frage: http://www.torsten-horn.de/techdocs/ascii.htm
Gast
#4729759
rbx schrieb: > wie sonst, holistisch? Clusterweise. https://de.wikipedia.org/wiki/File_Allocation_Table lalala schrieb: > rbx schrieb: >> wie sonst, holistisch? > > Clusterweise. Kommt drauf an, auf welcher Ebene man's betrachtet. Im Dateisystem sind die Daten natürlich blockweise gespeichert. Für das Programm aber liegen tatsächlich "einfach Bytes hintereinander weg". "Textus" hat leider bisher nicht geschrieben hat, ob er auf Anwendungs- oder auf Systemebene unterwegs ist. Christopher J. schrieb: > Das kommt auf die Codierung an. Stichworte für Google sind hier ASCII, > UTF-8, UTF-16 und Unicode. UTF-16 beispielsweise nutzt immer zwei Byte > pro Zeichen, während ASCII und UTF-8 mit einem Byte auskommen. Es gibt > auch noch UTF-32, das nutzt sogar vier Byte pro Zeichen. Quark! Nur UTF-32 fixiert die Zeichenlänge auf 4 Bytes. https://en.wikipedia.org/wiki/UTF-8 > UTF-8 encodes each of the 1,112,064 valid code points [...] > using one to four 8-bit bytes https://en.wikipedia.org/wiki/UTF-16 >The encoding is variable-length, as code points are encoded > with one or two 16-bit code units. https://en.wikipedia.org/wiki/UTF-32 > It is a protocol [...] that uses exactly 32 bits per Unicode code point.
Gast
#4729818
Eric B. schrieb: > Es gibt >> auch noch UTF-32, das nutzt sogar vier Byte pro Zeichen. > > Quark! Nur UTF-32 fixiert die Zeichenlänge auf 4 Bytes. Genau das steht doch in dem von dir selbst zitierten Satz. Aber du musstest natürlich auch noch was dazu schreiben und dabei noch eine Beleidigung unterbringen, hoffentlich ist dir jetzt wohler. Georg Georg schrieb: > Genau das steht doch in dem von dir selbst zitierten Satz. Da hast du jetzt aber echt ganz geschickt von den zitierten Sätzen nur den übrig gelassen, der tatsächlich richtig war. Ich hole den relevanten Teil nochmal aus dem Grab zurück: Christopher J. schrieb: > UTF-16 beispielsweise nutzt immer zwei Byte pro Zeichen, während ASCII > und UTF-8 mit einem Byte auskommen. Und das ist falsch.
Gast
#4729972
Georg schrieb: > Im Gegensatz zu vielen anderen Dateitypen haben Textdateien keinen > Header, sie fangen einfach mit dem ersten Byte an (und hören mit dem > letzten auf). Nichtmal das stimmt 100%ig. Siehe "Unicode-BOM"...
Gast
#4729975
c-hater schrieb: > Georg schrieb: > >> Im Gegensatz zu vielen anderen Dateitypen haben Textdateien keinen >> Header, sie fangen einfach mit dem ersten Byte an (und hören mit dem >> letzten auf). > > Nichtmal das stimmt 100%ig. Siehe "Unicode-BOM"... klar stimmt das, jede Datei fängt mit dem ersten Byte an. Auch wenn eine BOM vorhanden ist, dann steht das erste Byte an erster stelle.
Gast
#4729981
Rolf M. schrieb: > Christopher J. schrieb: >> UTF-16 beispielsweise nutzt immer zwei Byte pro Zeichen, während ASCII >> und UTF-8 mit einem Byte auskommen. > > Und das ist falsch. Genau so sieht's aus. Die Unicode-Codierung, die immer nur genau zwei Byte pro Zeichen benutzt, heisst UCS-16. Die UTF-Codierungen benutzen variable Codelängen.
Gast
#4729986
Peter II schrieb: > klar stimmt das, jede Datei fängt mit dem ersten Byte an. > > Auch wenn eine BOM vorhanden ist, dann steht das erste Byte an erster > stelle. Haha. Es ging natürlich um das erste Byte des Payload, falls du das nicht begriffen hast.
Gast
#4730240
Textus schrieb:
>Liegen da einfach Bytes hintereinander weg, oder wie funktioniert das?
Zum Beispiel unter Linux:
Schreibe einfach mal mit einem Editor eine Textdatei,
vieleicht mit nur einem Wort. Dann Abspeichern (Test.txt).
Dann anschauen mit:
xxd -g1 Test.txt
Da siehs du dann jedes einzelne Byte in Hex-Zahlen.
Nop schrieb: > Vergiß nicht, daß es auch noch UTF-8 und so gibt. Also pro Buchstabe ein > Byte, das war im letzten Jahrtausend mal so, als man noch ASCII und > Codepages und sowas hatte. Und dann nicht beispielweise griechische > Schrift zugleich mit hebräischer in einer Textdatei darstellen konnte, > weil die Schriften in inkompatiblen Codepages waren. Reine ASCII Zeichen belegen auch in UTF8 nur ein Byte, es ist ein einfacher 'Trick' ein 7Bit ASCII Zeichen bekommt vorne eine NULL verpasst und bleibt damit als ASCII Zeichen ein Byte lang. Wenn der 'Interpreter aber vorn eine 1 findet ist es ein 'nicht ASCII Zeichen' und wird nach dem UTF8 Standart decodiert. c-hater schrieb: > Rolf M. schrieb: > >> Christopher J. schrieb: >>> UTF-16 beispielsweise nutzt immer zwei Byte pro Zeichen, während ASCII >>> und UTF-8 mit einem Byte auskommen. >> >> Und das ist falsch. > > Genau so sieht's aus. Die Unicode-Codierung, die immer nur genau zwei > Byte pro Zeichen benutzt, heisst UCS-16. Sie heißt UCS-2, nicht UCS-16, gehört eigentlich nicht zu Unicode, und sie ist offenbar kein Bestandteil der UCS-Norm mehr. Siehe https://de.wikipedia.org/wiki/Universal_Coded_Character_Set c-hater schrieb im Beitrag #4730887: > Rolf M. schrieb: > >> Sie heißt UCS-2, nicht UCS-16, gehört eigentlich nicht zu Unicode, und >> sie ist offenbar kein Bestandteil der UCS-Norm mehr. Siehe >> https://de.wikipedia.org/wiki/Universal_Coded_Character_Set > > Man sollte nicht alles glauben, was man in der deutschsprachigen > Wikipedia lesen kann... > > Zumindest... nicht den Link zum > entsprechenden Artikel der englischsprachigen Wikipedia gekillt. Dort > stehen nämlich die wahren Sachverhalte. Und die lesen sich dann doch ein > wenig anders... Ja? Ich lese da das gleiche, nur etwas ausführlicher. Es gibt sogar ein eigenes Kapitel, das sich mit den Unterschieden zwischen UCS und Unicode beschäftigt: https://en.wikipedia.org/wiki/Universal_Coded_Character_Set#Differences_with_Unicode Und https://en.wikipedia.org/wiki/UTF-16 sagt: > However, "UCS-2 should now be considered obsolete. It no longer refers to > an encoding form in either 10646 or the Unicode Standard." Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
