Neuer XML Parser!!!

  • Themenstarter Themenstarter Gelöschtes Mitglied 34033
  • Beginndatum Beginndatum
G

Gelöschtes Mitglied 34033

Gast
hallo
ich hab heut mir mal 2-3 stündchen zeit genommen und einen xml parser geschriben
download und tutorials hier
es ist ähnlich wie jdom es kann xml zu einem dom baum parsen und diesn auch schreiben (mir tabs, zeilenumbruch, etc)
ich hoffe er gefällt euch hat zwar nich soooo viele funktionen aber bin ja erst 12
ich wäre very very very happy wenn christian ullenboom noch was über diesen parser in eine 2. auflage von java 7 mehr als eine insel schreibt
 
Habe nur die API ein bisschen überflogen. Was mir aufgefallen ist: du verwendest eine Map um die Kinder eines Elementes darzustellen. Aber in einem xml-File ist es durchaus erlaubt, dass mehrere Kinder denselben Namen haben. Und die Reihenfolge wie die Elemente im File stehen, solltest du auch nicht durcheinander bringen (eine Map merkt sich normalerweise nicht, in welcher Reihenfolge sie befüllt wird).
 
@Noctarius kommt noch
@Beni
1. ich hab Map<String, List<Element>> genauer lesen
2. für die sortierung... mh.. mal gucken was ich mache eventuell eigene map proggen
 
Zuletzt bearbeitet von einem Moderator:
Irgendwo hab ich mal gelesen, dass Josh Bloch seine LinkedHashMap als eine seiner wichtigsten Implementierungen ansieht, oder besonders stolz darauf ist ;-) Bzgl. dessen, dass Maps im Normalfall ja nicht sortiert sind. Wenn es nicht die insertion order ist, bzw. auf einem Comparator basiert braucht man wohl eine Baumstrukture mit Knoten<K, V> wie etwa TreeMap. In dem Fall dürfte aber LinkedHashMap für einen preorder Durchlauf passen.
 
LinkedHashMap wäre da ggf. das richtige. Aber sonst... Viel indexOf und replaceAll.... es war schon fast zu erwarten, dass es ihn bei
[XML]<test>Contents <!--No comment--> of test </test>[/XML]
raushaut, komplexere Sachen hab' ich jetzt mal noch nicht ausprobiert (hab' auch keine Ahnung davon)
 
Wie angedeutet: Mit indexOf, replaceAll & Co wirst du noch deinen Spaß haben. Mögliche nächste Tests:
[XML]<test>"Contents <!--\"No comment\"--> of test"</test>[/XML]
[XML]<test>"Contents <!--\"No comment\"-- of test"</test>[/XML]
[XML]<test>"Contents <!--No comment\"-- of test"</test>[/XML]
....
 
Welche Vorteile bietet mir dieser Parser, der in wenigen Stunden geschrieben wurde, zu einem Jahrelang von Profis entwickelten?

Und warum sollte man über ein Projekt von mehreren Stunden, in einem Buch schreiben?

Ich finde es ja toll, als eine Art Freizeitprojekt um zu sehen, welche Hürden auf einen zukommen, wenn man sich damit beschäftigt. - Aber dann würde ich ja eher Wert auf den Quellcode legen, als über irgentwelche mini Funktionalitäten für Textdateien, die zufällig so aussehen wie eine XML Datei..

Lade bitte deinen Quellcode hoch, damit wir den Bewerten können.
 
XML-Parser...

Wir hätten da:

(J)DOM - DOM-basierter Zugriff, sehr schöne API um auf XML zuzugreifen, halt nicht geeignet für große XML-Bäume
SAX - Event-basiert, nicht so "schöner" Zugriff, dafür auch mit Gigabyte von XMLs möglich
STAX - guter Mittelweg, Cursor-basiertes navigieren durch XML u.s.w.

Wir haben mal eine Analyse gefahren (für SEPA, Gigabyteweise XML-Dateien..) welcher Parser für welche Größe taugt...und da frage ich mich halt: Was kann dieser Parser hier besser als die drei oben genannten?
 
Und deine Seite hat kein richtiges Impressum. Unter Impressum wird nur auf das Webbuilder Framework hingewiesen.
 
UPDATE IST RAUS
- Kommentare
- LinkedHashMap's
- Die Sources sind hochgeladen und auf dev-xgamespro.jimdo.com verlinkt (wenn du keinen bock hast das "Hier" zu finden klick hier)
 
Hatte ja schon einiges gesagt (das soll ja auch alles nicht zuuu demotivierend klingen) aber... Bei sowas wie
if (ds.matches("standalone=\"(.*?)\"")) {
würde er sich schon mit einem
[XML]standalone = true[/XML]
verschlucken
 
oh das muss noch geändert werden für is egal wie viele leers kann man [\\p{Blank}]* nehmen

EDIT:
so jetzt hab ichs geändert
 
Zuletzt bearbeitet von einem Moderator:
so jetzt hab ichs geändert

Wie schon angedeutet wurde solltest du dir nicht einreden, dass das in absehbarer Zeit ein Parser wird, der "alles, was gültiges XML ist" versteht, oder er in irgendeiner anderen, formal-kühl-technischen Sicht "gut" wird (RegEx ist BTW auch nicht das schnellste...), und das mit der Java Insel wird wohl auch nichts, aber ... als ich 12 war, habe ich mich gefreut, als
Code:
10 PRINT "64 * 46"
20 PRINT "ergibt"
30 PRINT 64*64
in der letzten Zeile wirklich 4096 ausgegeben hat 😀
(Wir brauchen unbedingt BASIC-Code-Tags!!! :reflect: )
 
@TO: Im Prinzip hast Du recht wenn Du einen neuen, eigenen XML-Parser schreiben willst denn was auf dem Markt an Parsern existiert ist überwiegend Schrott. Und diese Parser sind Schrott, weil XML für die real existierende Datenverarbeitung Schrott ist weil die Specs von gelangweilten Leuten geschrieben wurden die sich keine Gedanken darüber gemacht haben wie Datenverarbeitung "im wirklichen Leben" läuft.

Dein Problem ist, dass XML niemals perfekt verarbeitet werden kann (entweder ist das File zu gross oder zu schmutzig oder der Server für das DTD antwortet nicht).

Ich habe mittlerweile alle Vorkommnisse von XML wieder erfolgreich auf CSV reduziert und die Gegenseite(n) haben es mir gedankt.

Bernd
 
ich verwende auch überwiegend csv und eigene dateien formate für archive (zip, rar, 7z, gzip könnt ja jeder öffnen)
 
Code:
 CIP    	STARTFILE    Yn`rr>@P†}￾rq;￾…￾Yn`rr>@P†}￾rq ENDFILE
@Noctarius kannst du das entschlüsseln?
 
Zuletzt bearbeitet von einem Moderator:
Jetzt sag mir bitte nicht dein "Pack"-Format speichert Plaintext? Oo Wenn nicht, dann gib mir das Ding als File, ich will da mit nem Hexeditor ran.
 
das besteht aus DataOutputStream und jedes char in einer gepackten datei wird 13 weiter gemacht a -> n
 

Zurück
Oben