Hallo! Ich stehe vor folgendem Problem, und zwar weiß ich nicht, wie ich in C aus einer kml-Datei Daten auslesen und in ein einfache verkette Liste speichern soll. Lese ich aus einem binary-File, dann verwende ich ja den Befehl *fopen( const char *fname, const char *mode ); wobei ich für *mode "rb" einsetze, also "Read Binary File". Was muss ich machen, um eine KML-Datei (keyhole markup language) öffnen zu können und anschließend in eine Liste zu speichern?
Gast
#2466328
Keinen binary mode verwenden, sondern Text lesen. Und dann das XML parsen.
Danke für die super schnelle Hilfe! d.h. ich brauch für nur "r" statt "rb" schreiben
Gast
#2466407
Kommt drauf an. Mir ist außer Windows kein produktiv eingesetztes Betriebs-/Dateisystem bekannt, wo 'b' einen Unterschied ergibt. Das ist bei Windows wieder saudämlich gelöst. 'b' (Binärmodus) und 't' sind natürlich plattformspezifisch. Bei 't' (Testmodus) pfuscht Windows dazwischen und ersetzt '\n' in der Ausgabe durch '\r\n' und '\r\n' in der Eingabe durch '\n'. Außerdem wird ein Dateiendezeichen interpretiert, was schlimmstenfalls die Performance drückt. Wenn weder 'b' noch 't' angegeben werden, dann -- ganz Windows-typisch -- ist der Modus nicht eindeutig, sondern hängt von einer globalen Variablen (_fmode) ab. Und diese Variable ist natürlich auch wieder plattformspezifisch. Der richtige (portable) Weg ist also, unter Windows immer 'b' mit anzugeben und sich selbst um die Zeilenenden zu kümmern. Was KML angeht: Das ist doch XML, warum benutzt du nicht eine XML-Bibliothek?
Ich darf bei meiner Aufgabe nur alle Standard-C-Bibliotheken verwenden und da gehört ja diese XML-Bibliothek nicht dazu. Danke nochmals für die ausführliche Beschreibung, anhand dessen werd ich das schon schaffen! :) Gruß Fux
Gast
#2466543
Gut, dann an das 'b' denken. Und ja, das ist Standard-C :-)
Sven P. schrieb: > Der richtige (portable) Weg ist also, unter Windows immer 'b' mit > anzugeben und sich selbst um die Zeilenenden zu kümmern. Das würde ich so nicht unterschreiben. Der Modus 't' ist genau aus dem Grund eingeführt worden um der Plattform eine andere Filedarstellung für Textfiles zu ermöglichen. 't' hat dann dafür zu sorgen, dass die plattformspezifische Darstellung in die 'c-Form' übersetzt werden muss, in der ein Zeilenende als \n, und zwar nur als \n, ausgedrückt wird und zb auch ein eventuell im File selbst kodierter EOF Mechanismus entsprechend ausgewertet wird, so dass die Lesefunktionen diese nicht sehen. Edit: d.h. genau genommen, ist alles was nicht 'b' ist, automatisch Text-Modus. 't' ist dazu gar nicht notwendig. Und nur weil in Unix 'b' und 't' identisch sind, ist das nicht wirklich ein Argument. Gerade wenn man portabel sein möchte, fährt man am besten wenn man eben nicht 'b' und Eigenbehandlung benutzt, sondern es der Runtime-Lib überlässt, plattformspezifische Ersetzungen zu machen, falls dies notwendig ist.
Gast
#2466650
Karl Heinz Buchegger schrieb: > Sven P. schrieb: > >> Der richtige (portable) Weg ist also, unter Windows immer 'b' mit >> anzugeben und sich selbst um die Zeilenenden zu kümmern. > > Das würde ich so nicht unterschreiben. > > Der Modus 't' ist genau aus dem Grund eingeführt worden um der Plattform > eine andere Filedarstellung für Textfiles zu ermöglichen. Jein, das ist an sich eine gute Idee. Das Pferdefuß daran ist, dass 't' leider nicht standardisiert ist (wohl aber 'b', C99 §7.19.5.3 Abs. 3). > Edit: d.h. genau genommen, ist alles was nicht 'b' ist, automatisch > Text-Modus. 't' ist dazu gar nicht notwendig. Und genau das ist eben nicht der Fall; Zitat MSDN(1): >> If t or b is not given in mode, the default translation mode is >> defined by the global variable _fmode Nach Standard hast du ja Recht, aber was hilfts :-} > Und nur weil in Unix 'b' und 't' identisch sind, ist das nicht wirklich > ein Argument. Gerade wenn man portabel sein möchte, fährt man am besten > wenn man eben nicht 'b' und Eigenbehandlung benutzt, sondern es der > Runtime-Lib überlässt, plattformspezifische Ersetzungen zu machen, falls > dies notwendig ist. ...was ja leider wieder nicht funktioniert. Man muss _fmode testen und ggf. ja doch selber wieder auf die Zeilenenden achten. (1) http://msdn.microsoft.com/de-de/library/yeby3zcb%28v=vs.80%29.aspx
Ich glaube, daß der Threadstarter ein ganz anderes Problem haben dürfte, als die Zeilenendecodierung, nämlich das Interpretieren einer XML-Datei in C ohne zusätzliche Bibliotheken.
Gast
#2466752
Nun, winzige XML-Parser sind schon erfunden. Aber wenn es denn so sei. Entweder besteht die Aufgabenstellung in der Programmierung eines eigenen XML-Parsers oder es wird wieder einmal mehr unnötig das Rad neu erfunden...
Gast
#2466815
Du studierst nicht zufällig auf der TU-Graz? https://palme.iicm.tugraz.at/wiki/ESP/Ass3_WS11
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.