xml datei einlesen und in Textdatei umwandeln

google: c xml reader, c xml lib => tutorial der gefundenen quellen 
lesen..

Anton schrieb:
> den Inhalt von dieser Datei in einer Textdatei umwandeln, wobei der alle
> overhead rausgenommen werden muss.

Nun, sieh Dir mal eine XML-Datei mit einem einfachen Texteditor an (wie 
z.B. Notepad) und sieh Dir dann an, wie dieselbe Datei "ohne allen 
Overhead" laut Aufgabenstellung aussehen soll.

Ohne die Spezifikation, wie das von "allem Overhead" befreite Ergebnis 
auszusehen hat, brauchst Du auch gar nicht anzufangen.

Anton schrieb:
> Max schrieb:
>> Hast doch schon genügend Tips
>
> ich habe niemals gesagt, dass du die code für mich schreibt. sondern nur
> Hinweise


Ich denke der Hinweis gleich im ersten Antwortposting ist mehr als 
genug.

Welche XML Parser Libraries hast du dir den bisher angesehen?


> welche c Funktion braucht man dafür????

Nicht: Funktion
Sondern: Funktion_en_

eine XML Parser Library stellt dir einen Satz von Funktionen zur 
Verfügung, mit denen man komfortabel XML Files bearbeiten kann. Viele 
Funktionen müssen zusammenspielen, damit du dein Ziel erreichst.

Sonst wäre Programmieren ja auch banal und jeder könnte ein 
Schachprogramm schreiben

int main()
{
  play( "chess" );
}

Fertig.
Aber so einfach ist das nun mal nur auf der Enterprise.

Anton schrieb:
> sondern nur
> Hinweise

Also:
Schnapp dir eine Bibliothek zum parsen. SAX reicht, DOM wäre overkill. 
geeignet wäre z.B. das Urgestein "expat".

http://expat.sourceforge.net/

Dann Parser initialisieren,
einen character-data-handler setzen,
input reinstreamen,
fertig.

Anton schrieb:
> Karl Heinz Buchegger schrieb:
>> eine XML Parser Library
>
> ich muss kein XML Parser benutzen,

Du musst nicht, aber du sparst dir viiiieeeel Arbeit, wenn du es tust.

> sondern in C programmiern. kennst du
> funktionen die mir helfen kann

Wo liegt das Problem?
Deinem Arbeitgeber gegenüber den Mund zu voll genommen, dass du 
programmieren könntest?
Dann wärs besser, wenn du ihm jetzt reinen Wein einschenkst. Er wird dir 
sowieso drauf kommen.
Für einen geübten C-Programmierer ist das eine Sache auf ein paar 
Nachmittage (1 bis 2), wenn er noch nie mit einem XML-Parser gearbeitet 
hat. Hat er das schon mal, ist das eine Sache auf 1 oder 2 Stunden. D.h. 
du bist nach 3 Tagen sowieso schon mehr als überfällig.

Peter II schrieb:
> ausfüllen schrieb:
>> Ich habs gerade
>> ausprobiert, inkl. Debuggen (es ist noch früh...) keine Viertelstunde.
> und das Programm kommt mit xml-kommentaren und "<" im Text klar?

und mit Umlauten und Sonderzeichen? Zeilenumbrüche?
Kann Attribute auswerten, etc. etc.

Wenn man ein spezielles XML hat, bei dem man weiß, dass gewisse Dinge 
nicht vorkommen, ist das eine Sache. Aber ein XML-Parser macht solche 
Dinge eben aus dem Stand heraus richtig.

Was nicht heißt, dass man nicht einen einfachen XML Redaer selbst machen 
kann. Schon klar.

und mit UTF-8 / UFT-16 ;-)

solange nicht klar ist, was das Programm machen soll, wir man dem TO 
nicht helfen können

Robert L. schrieb:
> und mit UTF-8 / UFT-16 ;-)
>
> solange nicht klar ist, was das Programm machen soll, wir man dem TO
> nicht helfen können

Ich würds so formulieren:
So lange nicht klar ist, was das Programm machen soll, ist seine absolut 
beste Option, eine fertige XML Parser Lib zu benutzen.

Wenns allerdings eine Hausübung in seinem C-Kurs ist, die auf 
Stringverarbeitung und Filehandling abzielt, dann hat er ein Problem. 
Ein mächtiges Problem. Und das wird ihm hier keine lösen, denn recht 
viel mehr als Grundlagen in diesen beiden Bereichen braucht man dazu 
nicht. Ist einfach nur viel Arbeit.

ausfüllen schrieb:
> Karl Heinz Buchegger schrieb:
>> und mit Umlauten und Sonderzeichen? Zeilenumbrüche?
>> Kann Attribute auswerten, etc. etc.
> Ach menno, das war ne kleine Spielerei beim Frühstücken. maul ;-)

:-)
Ist schon klar.
(Ich möchte aber auch für den TO den Eindruck vermeiden, dass man sowas 
mal im Handumdrehen machen könne)

> Umlaute, Sonderzeichen und Zeilenumbrüche sollten gehen, ich sehe da
> jetzt kein Problem,

http://www.devtrain.de/artikel_296.aspx

ausfüllen schrieb:
> Karl Heinz Buchegger schrieb:
>> (Ich möchte aber auch für den TO den Eindruck vermeiden, dass man sowas
>> mal im Handumdrehen machen könne)
> Ok, verstehe ich. Ob Handumdrehen oder nicht ist halt die Frage ob man
> wirklich "komplettes" XML braucht oder nur sowas wie ich oben gepostet
> habe.

Wenns wirklich eine Firmenarbeit ist, gehe ich jede Wette ein, dass es 
da noch so nette Nebenbedingungen gibt, wie zb Umstrukturieren der 
Eingabe in eine Record-Struktur im Textfile. Damit dann eben aus

1

<Lager>

2

  <Bauteil>

3

    <Name>M8-Schraube</Name>

4

    <Bestand>2850</Bestand>

5

    <Einkauf>Aldi Hamburg</Einkauf>

6

  </Bauteil>

7

  <Bauteil>

8

    <Name>Gabelschl&#252;ssel</Name>

9

    <Bestand>55</Bestand>

10

    <Einkauf>H&M Nord</Einkauf>

11

  </Bauteil>

12

</Lager>

so was wird (zb ein CSV File)

1

"M8-Schraube"; "Aldi Hamburg"; 2850

2

"Gabelschlüssel"; "H&M Nord"; 55

Karl Heinz Buchegger schrieb:
> Wenns wirklich eine Firmenarbeit ist, gehe ich jede Wette ein, dass es
> da noch so nette Nebenbedingungen gibt, wie zb Umstrukturieren der
> Eingabe in eine Record-Struktur im Textfile

Wenns aber eine Firmenarbeit ist, dann ist dem Scheffe egal, ob's mit C 
oder z.B. mit xslt gelöst wird.

Notfalls : Per "system" o.Ä. einfach xsltproc aus C heraus ausführen ;)

> dann ist dem Scheffe egal,

sollte es ihm aber nicht sein (ich mein jetzt allgemein, nicht in diesem 
Zusammenhang..)

wenn man für jeden "sch.." eine neues "Werkzeug" verwendet hast du 
irgendwann so einen Haufen an unterschiedlichen Sachen zu warten (bzw. 
brauchst auch leute die sich auskennen usw.)

deshalb ist es sicher oft besser, man nimmt etwas das man schon in 
Verwendung hat (auch wenn es nicht 100% passt)

Robert L. schrieb:
> wenn man für jeden "sch.." eine neues "Werkzeug" verwendet

Naja, XML ist aber mittlerweile weit davon entfernt, unter "jeder
Sch..." zu rangieren, und XSL ist die erste Wahl, wenn man XML-Daten
nachbearbeiten will.  Das Problem des TE ließe sich damit nämlich
gänzlich ohne Programmierung mit folgendem Einzeiler lösen:

1

echo '<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"></xsl:stylesheet>' |\

2

xsltproc - myxmfile.xml

Jörg Wunsch schrieb:

> Naja, XML ist aber mittlerweile weit davon entfernt, unter "jeder
> Sch..." zu rangieren, und XSL ist die erste Wahl, wenn man XML-Daten
> nachbearbeiten will.

Allerdings.

Drum werd ich auch aus dem Urposting nicht wirklich schlau

Zum einen passt das Beharren auf "ich MUSS C benutzen" nicht wirklich zu 
einer beruflichen Situation. Warum muss er? In einer Firmensituation 
kommt es auf das Ergebis an.
Auf der anderen Seite ist das für einen Studenten, der gerade mit C 
angefangen hat, viel zu schwer (wenn man es ordentlich macht). Und wenn 
ein Student schon einigermassen programmieren kann, dann sollte das 
eigentlich nicht zur Frage "Wie fange ich an?" führen.

Wie ich anfangen würde, weiß ich - wenn ich das selber ausprogrammieren 
müsste. Ich würde das erst mal als Syntaxparsing Problem auffassen, EBNF 
für XML aufstellen und meine Compilerbautools drauf loslassen um einen 
Parser zu generieren :-)

Karl Heinz Buchegger schrieb:
> Auf der anderen Seite ist das für einen Studenten, der gerade mit C
> angefangen hat, viel zu schwer (wenn man es ordentlich macht).

Wenn man aber nicht auf 23000 Sonderfälle wie absurde encodings und
dergleichen achten muss (weil's eh' nur eine Übungsaufgabe ist), dann
ist es natürlich eine relativ einfache Übung zur Datei- und simplen
Textverarbeitung in C:

1

int main(){int f=0;while(read(0,&f,1))if((f&255)=='\74')f=01000;else if(f==0x23e)f=0;else write(1,&f,1);}

(Ich hoffe mal, dass der Lehrer dieses Geschreibsel nicht durchgehen
lassen würde. :-)  Randbedingung: muss auf einer little-endian
Maschine laufen; wird als Filter benutzt, also mit stdin/stdout.)

<we<it>er> ist kein gültiges XML, insofern ist es OK wenn da ein ">" 
stehen bleibt... Eigentlich müsste das Program die "Annahme verweigern", 
wenn es sich "XML-Konform" schimpfen möchte...

ich glaub es sollte f=010000 lauten

und hier:
f==0x23e

müsste doch f==0x13e

oder ?

ausfüllen schrieb:
> Das Flag was du
> da setzt (=01000 - oktal kommt selten vor!) wird ja von read wieder
> flachgebügelt...

Sollte nicht: read liest ja nur ein Byte, aber 01000 liegt im zweiten
Byte.  Aber du hast natürlich Recht, ein Logikfehler war noch drin.
Hier also meine korrigierte Version:

1

int main(){int f=0;while(read(0,&f,1))if((f&255)=='\74')f=01000;else if(f==0x23e)f=0;else if(f<255)write(1,&f,1);}

Aber ich muss neidlos zugeben, deine ist noch schöner geworden. ;-)

ausfüllen schrieb:

>> Aber ich muss neidlos zugeben, deine ist noch schöner geworden. ;-)
> :-) Mal sehen ob Karl-Heinz auch noch dazukommt, bin gespannt.

War grad in einer Besprechung.

Uff. Da hast du ja schon ganz schön was vorgelegt. Mal sehen ob mir da 
noch was dazu einfällt :-)

Karl Heinz Buchegger schrieb:
> ausfüllen schrieb:
>
>>> Aber ich muss neidlos zugeben, deine ist noch schöner geworden. ;-)
>> :-) Mal sehen ob Karl-Heinz auch noch dazukommt, bin gespannt.
>
> War grad in einer Besprechung.
>
> Uff. Da hast du ja schon ganz schön was vorgelegt. Mal sehen ob mir da
> noch was dazu einfällt :-)

Das ist natürlich schon verdammt kreativ

1

(l+=(i==60)-(v=(i==62)))?0:!v?write(1,&i,1):0;

(wozu du das v brauchst hab ich noch nicht durchschaut)

Hmm. Ausnutzen der Shortcut-Evaluation von && bzw. ||

1

(l+=(i==60)-(v=(i==62)))?0:!v&&write(1,&i,1);

Karl Heinz Buchegger schrieb:

> (wozu du das v brauchst hab ich noch nicht durchschaut)

ok, habs

Karl Heinz Buchegger schrieb:


> Hmm. Ausnutzen der Shortcut-Evaluation von && bzw. ||
>

1

> (l+=(i==60)-(v=(i==62)))?0:!v&&write(1,&i,1);

2

>

Das müsste aber auch mit dem ersten ? gehen

1

!(l+=(i==60)-(v=(i==62)))&&!v&&write(1,&i,1);

Schaut aber besser noch mal drüber. 100% sicher bin ich mir nicht.

(&& ist ein Sequence Point, die Änderung und Abfrage von v ist daher 
legal und definiert)

ausfüllen schrieb:

> Passt. Verflixt, ein Zeichen besser/kürzer. Irgendwann krieg ich dich
> mal!


Ach, das ist nicht schwer. So gut bin ich nicht.

Dafür müsste man noch was kürzeres finden
l+=(i==60)-(v=(i==62))

Ich geh jetzt erst mal eine rauchen :-)

Wird wenn kein return-type angegeben wird nicht implizit int angenommen? 
Würde nochmal 4 Zeichen sparen ;)

ausfüllen schrieb:

> Aber das Ganze ist sowieso nicht ganz koscher, der GCC beschwert sich
> vollkommen zu Recht dass kein Rückgabewert angegeben ist.

Klar, es gibt ja noch genügend weitere Schweinereien da drin, wie
die Benutzung nicht deklarierter Funktionen.  Aber wir wolltem dem
OP ja auch hier nicht seine Hausaufgaben abgabefertig erledigen. :-)

Ja lustig. Aber wäre Kranke oder sagen wir 'auffällig' nicht besser?
Wird euer Code dann auch entsprechend kurz an Laufzeit und 
Assemblercode?

Jedenfalls auch ne Form von Verschlüsselung. Schön zippen vielleicht 
noch.


Habe gerade mal ausprobiert was der Web-Browser dazu sagt: Der machts 
anscheinend von ganz alleine. Wiki meinte er bräuche dafür ein extra 
Tag.

Ersa schrieb:
> Übersichtlicher als die heutzutage gerne gescholtenen
> goto-BASIC-Kauderwelsch-Konstrukte der Fans unlesbaren Spaghetticodes
> ist das aber wahrlich auch nicht!

Das war ja auch nicht der Sinn der Übung. ;-)  Das überlassen wir
gern dem TE, der bitteschön seine Hausaufgaben selbst lösen möge.
Letztendlich laufen all diese "kranken" Lösungen ja auf das in
diesem Posting schon gegebene Kochrezept hinaus:

Beitrag "Re: xml datei einlesen und in Textdatei umwandeln"

Als Übung für die Programmiersprache C taugt so ein Wettbewerb
natürlich allemal (der IOCCC wurde ja nun schon ein paar Jahre lang
nicht mehr ausgetragen), auch wenn natürlich niemand, der bei Trost
ist, in der Realität sowas hinschreiben würde.

Auf die Idee, die Argumente von main() als Variablen zu missbrauchen,
war ich auch schon gekommen, allerdings war mir nicht mehr bewusst,
dass man diese bei K&R-Style-Funktionsköpfen ja nicht zwingend
deklarieren muss.  Damit spart man natürlich dann nochmal. ;-)

Peter, bitte benutze künftig [c]-Markierungen.  Ich habe die mal
nachgereicht.

wieso? ist doch lesbar? Allerdings werden einige Compiler da ein wenig 
mosern :-)

1

main(i,t)

2

{

3

  for(; read(0, &i, 1); write(1, &i, t), t |= i==62)

4

    t &= i!=60;

5

}

---
Ich stand nach Experimenten mit dem MS Managed XML Reader (schweinelahm, 
ok, auch wegen der Marshal-Funktionen, um wieder nach C (char *) zu 
kommen) auch mal vor der Entscheidung: "Xerces oder was eigenes?" und 
hab mich dann entschieden, nen eigenen XML reader zu schreiben. Das ist 
gar nicht mal schwer. Der ist so kompakt, dass er weniger Code braucht, 
als für die Initialisierung von Xerces benötigt wird **LOL**.

Falls es jemandem was sagt, der Reader steckt im SVDConv und liesst 
CMSIS - SVD xml Dateien ein, interpretiert sie, und generiert C 
Headerfiles und was proprietäres.


VG,
/th.

1

  ..... write(1,&i,t) ....

geniale Idee, die Entscheidung ob geschrieben werden muss oder nicht, 
dem write mit dem Argument t selbst zu überlassen.

Erinnert mich irgendwie an Assembler-Code, der den nachfolgenden Code 
als Daten hinter sich reinschreibt. Kein Cache-Dirty gesetzt und die 
68040 beschwerte sich...
Der Anwender sah dann 'effektiven' Absturz.

> auch wenn natürlich niemand, der bei Trost ist, in der Realität
> sowas hinschreiben würde.

Natürlich nicht.
Aber das wirklich geniale an solchen Spielereien besteht darin, dass man 
die Sprache mit all ihren Feinheiten und manchmal auch obskuren 
Nebeneffekten bis in den letzten Winkel beherrschen muss bzw. das 
'Decodieren' solcher Dinge einem recht schonungslos seine Schwächen 
desselben aufzeigt.

Zb muss ich mir hier

   .... i==60?x=1:x?i==62?x=0:0:putchar(i);

nochmal die ?: Syntax genauer ansehen. Es sieht alles logisch aus, dann 
aber rinnt mir eine Gänsehaut den Buckel runter, wenn ich die beiden : : 
da am Ende betrachte.

Und zu guter letzt sieht man dann so manchesmal auch einen "Trick", den 
man tatsächlich gut gebrauchen kann.