mikrocontroller.net

Forum: PC-Programmierung Speicherung in Textdatei


Autor: Textus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Verschoben durch Moderator
Autor: Jalob (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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...

Autor: Jalob (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Textus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jalob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Textus schrieb:
> Wie erkennt man das Ende einer Textdatei bzw. die Länge?

Was genau ist für dich alles eine Textdatei?

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht zielt die Frage auch darauf ab, wie Dateien im Filesystem 
gespeichert werden. Also Blöcke und so.

Autor: Der kleine Clown (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rbx schrieb:
> wie sonst, holistisch?

Clusterweise.  https://de.wikipedia.org/wiki/File_Allocation_Table

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"...

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Günter Lenz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Heinz V. (heinz_v)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Char...

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."

: Bearbeitet durch Moderator

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.