himXML (gesprochen himix ML)

[himitsu]

wollt eigentlich nur mal die ersten Fortschritte eines vor kurzem längerem begonnen Projektes vorstellen

es ist "nur" eine weitere kleine XML-Klasse.

der Grund war eigentlich, daß mir andere XML-Projekte zu rießig sind
und MSMXL (TXMLDocument) nicht grad schnell.

[info]
aktuell entwickle ich unter D2009 und direkt kompatibel düfte es bis Delphi 2006 / Turbo Delphi sein

und Aufgrund einiger Anfragen versuch ich, sobald es da "gut" läuft, eine Extraversion weiter abwärtskompatibel zu machen ... mal sehn, bis wie weit runter das geht
[/info]
[add 04.01.2001] aktuell sieht es so aus, als wenn es schonmal bis zu D7 läuft [add/]

aktueller Post: http://www.delphipraxis.net/internal...116416#1116416 #193

• aktuell ab Delphi 2006 bzw. Turbo Delphi und auch für Delphi2009
  ab Windows 2000 und öfters mal in Windows 7 getestet
• zu den möglichen unterstützten Delphi-Versionen gibt es, Aufgrund häufiger Nachfragen, in Beitrag #191 eine kleine Zusammenfassung.
• Lizenzen: MPL v1.1 , GPL v3.0 oder LGPL v3.0
  es sollte also hoffentlich mit vielen anderen Lizenzen kompatibel sein
• arbeitet weitetgehend nach XML-Standard 1.0 (Fifth Edition)
  und Extensible Markup Language (XML) 1.1 (Second Edition)
• ist nicht validierend
• ein einzulesendes Dokument sollte aber möglichst "Well-Formed" (wohlgeformt) sein
• es wird nur der "Standard" unterstützt ... andere DTDs oder ähnliche Informationen werden nicht unterstützt
• also <!xyz text> wird zwar ausgelesen, aber "text" wird nicht auswertet
• <![CDATA[text]]> wird dagen natürlich behandelt
• <?xyz text ?> wird unterstützt, allerdings wird "text" geparst und in Parameter zerlegt (also wird es Probleme geben falls sich "text" mal nicht in Parameter zerlegen läßt)
  (nach XML 1.0 wird "text" eigentlich nicht zuerlegt im XML-Baum abgelegt, sondern nur XML-Prozessor-intern verarbeitet oder ignoriert)
• unterstützte Kodierungen (teilweise auch via BOM):
  UTF-7, UTF-8, UTF-16, ISO-10646-UCS-2 (littel endian), Unicode (big endian)
  ISO-8859-1 bis ISO-8859-9, ISO-2022-JP, EUC-JP, SHIFT-JIS und WINDOWS-1250 bis WINDOWS-1258
• UCS-4 (4 Byte-Unicode) wird nicht unterstützt,
  denn leider kann man immernoch nicht mit UCS4Char und UCS4String richtig arbeiten, vorallem da sie vollkommen inkompatibel zu den anderen Strings sind (bauen intern nur auf LongWord auf, statt auf einen "Char")
• im Gegensatz zu MSXML (TXMLDocument) kann die Kodierung stärker umgeschaltet werden
  (auch von ANSI/UTF-8 nach Unicode ... MSXML kann z.B. nur umschalten, wenn sich die Zeichengröße in Byte nicht ändert)
• arbeitet nur mit Klassen
  (eine Variante für sehr große Dateien und mit Interfaces aufgebaut, welche die Dateninhalte vorwiegend direkt in der Datei liest, speichert und ändert, kommt vielleicht irgendwann mal)
• eine Thread-Absicherung wurde letztendlich doch nicht direkt integriert,
  aber die CriticalSection wurde dringelassen und kann direkt verwendet werden:
  
  Delphi-Quellcode:

  XML._Lock;
  Try
    ... mach was mit dem XML ...
  Finally
    XML._Unlock;
  End;

• es muß nur jeweils eine Datei eingebunden werden
  himXML, himXMLi, himXML_UseDLL oder himXML_UseDLLi,
  jenachdem mit welcher Schnittstelle man arbeitet
  > wichtige Typen und Konstanten werden in den Dateien weitergeleitet, falls sie nicht in der entsprechenden Unit definiert sind
• ein kleiner Benchmark ist aber schon lauffähig:
  
  Delphi-Quellcode:

  // inklusive Zeitmessung siehe FormCreate
  
  XML := TXMLDocument.Create(Self);
  XML.Active     := True;
  XML.Version    := '1.0';
  XML.StandAlone := 'yes';
  XML.Encoding   := 'UTF-8';
  XML.Options    := [doNodeAutoIndent];
  XML.AddChild('xml');
  For i := 0 to 100000 do XML.DocumentElement.AddChild('Node' + IntToStr(i));
  XML.SaveToFile('test2.xml');
  XML.Free;
  
  // versus
  
  XML := TXMLFile.Create(nil);
  For i := 0 to 100000 do XML.RootNode.Nodes.Add('Node' + IntToStr(i));
  XML.SaveToFile('test.xml');
  XML.Free;

  Delphi-Quellcode:

  //10.000 Nodes (ergibt ca. eine 150 KB-Datei)
  
  TXMLDocument = fill:6749  save:99
  TXMLFile     = fill:  10  save: 7
  
  // 100.000 Nodes (ergibt ca. eine 1,5 MB-Datei)
  
  TXMLDocument = fill:708145  save:348  load:331
  TXMLFile     = fill:   189  save:150  load:319

  Zeiten in Millisekunden
  
  weitere Tests und Vergleiche (auch mit anderen Libs), siehe demos\CheckLibs.dpr
  wer keine Lust hat, vorallem wegen MSXML 'ne halbe Stunde ein Programm laufen zu lassen ... auf den nächsten Seiten befinden sich sporatisch die Testergebnisse verteilt
• "wichtige" Grundfunktionen von .RootNode wurden direkt in die Basisklasse (TXMLFile) umgelegt, sowie von .Nodes in dessen Mutterklasse (TXMLNode)
  
  .Node (.Nodes.Node[], .RootNode.Nodes.Node[] bzw .Nodes[], .RootNode.Nodes[]), .NodeNF (.Nodes.NodeNF bzw. .RootNode.Nodes.NodeNF), .NodeList (.Nodes.NodeList bzw. .RootNode.Nodes.NodeList), .NodeListNF (.Nodes.NodeListNF bzw. .RootNode.Nodes.NodeListNF) und AddNode (.Nodes.Add bzw. .RootNode.Nodes.Add)
  (in Groß siehe Beitrag #65)
• Pfadangaben sind möglich
  in Kurz also XML['node1\node2'] statt XML.RootNode.Nodes['node1'].Nodes['node2']
  ebenso können Parameter und Indizes im Nodepfad angegeben werden (siehe Hilfesektion in himXMLi.pas)
• es kann direkt eine Inline-Verschlüsselung genutzt werden
  einfach für den gewünschten Knoden zusweisen und alles via .Text und .Text_S wird automatisch beim Zuweisen/Auslesen ver-/entschlüsselt
  
  Delphi-Quellcode:

  Node.Crypted := '*';         // Standardverschlüsselung nutzen (erstes in der Liste)
  Node.Crypted := 'RC4';       // RC4 verwenden
  Node.Text := X;              // zuweisen und automatisch verschlüsseln
  X := Node.Text;              // automatisch entschlüsseln und auslesen
  If Node.Crypted <> '' Then   // nur prüfen ob es verschlüsselt ist
  If Node.Crypted = 'RC4' Then // prüfen ob es RC4 verschlüsselt ist
  
  XML.CryptData['RC4'] := S; // anderen Key für RC4 festlegen

  da die Verschlüsselungsroutine Zugriff auf die Node-Attribute hat, könnte man auch eine eigene Verschlüsselung zuweisen, welche z.B. über ein weiteres Attribut jeden Node mit einem eigenem Key verschlüsselt.
  
  Delphi-Quellcode:

  XML.Cryptors       // listet alle registrierten Verschlüsselungen auf
  XML.SetCryptor     // setzt/lösche eine Verschlüsselung
  XML.CryptProc      // siehe SetCryptor
  XML.CryptData      // siehe SetCryptor
  XML.CryptAttrName  // der Name des Attributes, welcher die aktive Verschlüsselung enthält

• • himXML.pas
    - die ganzen Klassen
  • himXMLi.pas
    - die zugehörigen Interfaces (sie spiegeln auch die Funktionalität der Klassen wieder .. nur da halt über TXML... statt IXML...)
    - und enthält auch eine "kleine" Hilfe-Sektion
  • himXML_Tools.pas
    - kleine Zusatzmodule:
    TSimpleAssocVariantArray - sehr einfaches String-assoziatives Array of Variant
    TXMLSerializeRecord_Creator - erzeugt eine Record-Definition für .Serialize/.DeSerialize von Records
    TXMLIniFile - verwendet eine XML-Datei wie eine INI und läßt sich auch wie IniFiles.TIniFile nutzen
    TXMLRegistry - das Gleiche, nur halt mit Registry.TRegistry
    TXMLDatabase - noch unfertig, soll aber irgendwann mal eine XML-Datei wie eine kleine SQL-DB nutzbar machen
  • demos\CheckLibs.dpr
    - einige Tests/Benchmarks zum Projekt und anderen XML-Libs
  • demos\CheckLib_UseDLL.dpr und demos\CheckLib_UseDLLi.dpr
    - das Gleiche, nur über ein externes himXML via DLLs (siehe weiter unten)
  • demos\Demo_Serialize.dpr
    - zeigt einiges zu den (De)Serialisierungsfunktionsn
  • demos\Demo_Tree.dpr
    - 'ne kleine Demo, wo eine XML-Datei in eine TreeView geladen und angezeigt wird
  • demos\SAXParser.dpr
    - hier wird eine kleine XML-Testdatei sequentiel geladen
  • DLLs\himXML_UseDLL.pas und DLLs\himXML_UseDLLi.pas
    - dieses sind die Schnittstellen-Units für die DLLs
    einmal als Objekte und das Andere (mit dem i) als Interfaces
    bei der Objektversion sind die Exceptions noch nicht umgeleitet, also möglichst welche vermeiden
    in der Interfaceversion funktioniert das Freigeben nochn nicht
  • DLLs\himXML_DLL.dpr und DLLs\himXML_DLLi.dpr
    - die zugehörigen DLLs
  • other\*
    - einige andere XML-Libs (verwendet in demos\CheckLibs* )
  • test files\*
    - einige "XML"-Dateien zum Testen

ansonsten bin ich für Tipps und Vorschläge dankbar

[add 13.03.2009]
ach ja falls der Name jemandem nich gefällt ... Beschwerden bitte an Matze richten

[add]
im Beitrag #193 wird etwas über die im Download mit enthalenen anderen XML-Libs geschrieben.


[add]
Achtung, beim Forenupgrad der DP sind die Dateikommentare verschwunden und die Dateinamen sind unglücklich importiert wurden.

himxml_246.7z = v0.9 21.05.2009
himxml_164.7z = v0.99d 12.01.2010
other.7z = 30.12.2010 (only the "other" directory)

[himitsu]

.XMLText:
Also in himXML wird der eingelesene/geparste Text ja in seine Einzelteile zerlegt und nur die enthaltenen Informationen gespeichert.
Beim "Auslesen" dieser Eigenschaft wird der XML-Text dann neu zusammengebaut.

Klar könnte ich jetzt noch alle möglichen Zusatzinfos über die ursprüngliche Textformatierung mit speichern, aber das wollte ich nicht ... ist mehr Aufwand, benötigt mehr Speicher und vorallem bremst es alles aus.

Das ist gerade ein Vorteil gegenüber dem MSXML-DOM ... die Geschwindigkeit und der Speicher

Und außerdem kommt es hier ja mehr auf den Inhalt und nicht das Datenformat an.

XHTML ist ja "nur" ein Mischmasch aus HTML und XML,
aber wie gesagt, ich bin dabei einige "Restiktionen" zu lockern und "Umwege" einzubauen, aber alles werd' ich wohl nie hinbekommen, da ich vorwiegend nur Fehlererkennungen einbau und keine Fehlerbehebung (die Parser der großen Browsern könn ja nahezu jedes Problem gekonnt "ignorieren", was aber och blöd ist, da gerade deswegen viele Internetseiten eigentlich "defekt" sind, aber es läuft halt, drum läßt man es so)

[himitsu]

Zitat von Daniel G:

Hm... Aber Zahlen kann ich immer noch nicht als Knotenbezeichner benutzen, oder?

wie ich grad bemerke ... gib für den Node einen Namespace an und schon ginge ex

ich weiß allerdings grad nicht, ob der Name so auch noch der XML-Spec entspricht,
aber selbst wenn ich das ändern sollte ... ich leg grad eine neue Option an, wo man die Namensprüfung etwas lockern kann könnte.

z.B. "num:123" um es leicht wieder zu trennen oder es getrennt zu setzen, kannst du die Möglichkeiten für die Namespacebehandlung des Nodes nutzen (.Namespace und .NameOnly).

[himitsu]

ich weiß, es gab 'ne Weile kein Update, aber nun geht's weiter

hier mal der aktuelle Stand (abgesehn von einigen Problemchen läuft es erstmal/wieder)

• die Exceptions wurden alle fast komplett überarbeitet
  und liefern zusätzlich nun auch ein paar Infos mehr
  (z.B. den "falschen" Nodenamen, welcher bemängelt wurde)
  
• die DLL-Version läuft auch (anscheinend)
  - der Memory Manager der EXE wird zur DLL durchgeshleift
  - die Klassen der DLL sind in der EXE verlinkt (die RTTI wird zur Laufzeit übertragen)
  - die Behandlung von Exceptions in der DLL wird an die EXE weitergereicht
  
• die Pfade zu den Units werden jetzt nichtmehr in den Demos/Testprogrammen per IN-Statement angegeben, sondern über die Suchpfade
  - welche das sind (z.B. für ältere Delphi-Versionen) steht im Dateiheader
  
• die globalen Kompilerschalter werden nicht mehr in der Interfaceunit (himXMLi.pas) angegeben
  dieses kann jetzt für jedes Projekt einzeln in den Projektoptionen angegeben werden
  (bei Wechsel des aktiven Projektes sollte das Projekt neu erzeigt werden, da Delphi bei Änderung der Optionen sonst vergißt die Units neu zu kompilieren )
  - Infos zu den möglichen Kompilerschaltern siehe Hilfe-Abschnitt in himXMLi.pas
  
• der SAX-Parser und einige der neuen Klassen in den Tools sind noch nicht fertig
• und die Interface-Version der DLL muß ich demnächst auch mal überarbeiten und versuchen die Fehler in der Referenzzählung zu finden

Datei siehe Post #1



Bezüglich einiger der Probleme der letzen 2 Seiten, wie z.B. die Kodierung usw.,
werd' ich mich jetzt erstmal damit etwas beschäftigen und versuchen alles nachzuvollziehen.

Falls einer 'ne Testdatei hat, wo etwas nicht läuft, könnte er sie mir ja gern mal zur Verfügung stellen.

[himitsu]

hab grad die EXMLException überarbeitet

- ein netter Fehler in der Paremeterbehandlung in der Exceptionsklasse wurde behoben
('ne Exception in der Exception, welche den eigenentlichen Fehler verbarg)
- überlange Fehlertexte werden abgeschnitten (also hier z.B. eingeblendete Name)
- Steuer- und Unicodezeichen werden umgewandelt und Hexadezimal angezeigt

bei diesem

Delphi-Quellcode:

XML.Node['EDDH'].Node['2009'].Node['Juni'].Node['30'].Attribute['haha'] := 'Putzilein';
XML.Node['EDDH\2009\Juni\30'].Attribute['haha'] := 'Putzilein';
XML.Attribute['EDDH\2009\Juni\30\haha'] := 'Putzilein';

kommt also nun sowas raus (wenn NodeAutoCreate aktiviert ist)

Zitat:

---------------------------
Test
---------------------------
EXMLException (TXMLNodeList.Add):

invalid name ("2009")
---------------------------
OK
---------------------------

Wenn NodeAutoCreate nicht aktiv ist, dann würde Node[] ein nil zurückliefern,
darum hab ich mir grad überlegt noch eine weitere Option anzubieten, welche dann mit einer "Node existiert nicht"-Exception um sich wirft (dieses sollte dann die Zugriffsverletzung auf "nil" verständlicher machen) ... also beim nächsten Update vermutlich dann mit enthalten

[himitsu]

aus Post #108

Zitat von Zwoetzen:

Allerdings bin ich da schon auf einen nächsten Fehler gestoßen:

Test-Prozedur:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
const
  S: String = '<root>Some Text<child>Ding</child>Something else</root>'; // <-- Sollte gültiges XML sein
var
  XML: TXMLFile;
begin
  XML := TXMLFile.Create;
  try
    XML.asXML := S;
    ShowMessage(XML.RootNode.XMLText);
  finally
    XML.Free;
  end;
end;

Normalerweise würde man davon ausgehen, dass man nun als Ausgabe genau den Teil zwischen den <root>-Tags bekommt, allerdings erscheint:

Zitat von ShowMessage:

Some Tex
<child>Ding</child>
Something els

Das bedeutet, dass sowohl das letzte Zeichen vor dem öffnenden <child> als auch vor dem schließenden </root> fehlt. Habe es mit verschiedenen Werten probiert, es scheint immer genau ein Zeichen zu fehlen.

da war ein kleiner "Trim"-Fehler in Bezug auf den Nodetyp xtUnknown, welcher in der Prozedur AssembleTree jeweil ein Zeichen zuviel entfernte

beim Einlesen war alles noch OK und auch wärend man mit dem Bäumchen arbeitete ... es verschand also nur wärend des Speicherns

hab auch gleich mal die restlichen verbliebenen (langsameren) Suchschleifchen in ParsingTree ersetzt und ebefalls nach TXMLFile.ParsingTree._Search verlagert

Update siehe Beta in Post #1

[himitsu]

• [add] die Exceptions hab ich auch noch etwas umgebaut
  - z.B. wird jetzt bei allen Exceptions wärend des Parsens die aktuelle Dateiposition angezeit
  - aber was Kodierungsfehler angeht ... da wird nur die etwaige Position genannt, also den Start der aktuellen Leseposition entsprechende des Lesepuffers (standardmäßig 32 KB).
  eine genauere Positionsangabe ist derzeit noch nicht vorgesehn (bissl aufwendig) ... kümmere mich da erstmal um andere Dinge
  
• hab noch 'nen kleinen Fehler in ReadBOM behoben ... da wurden alle Vorgaben auf UTF-8 zurückgesetzt, wenn kein BOM gefunden wurde ... lso Vorgaben waren wirkungslos
  
• die Interface-Verion läßt sich schonmal wieder kompilieren und sieht garnicht soooo schlecht aus ...
  nun muß ich nur noch irgenwann mal das mit der defekten Referenzzählung hinbekommen
  
• dieses geht nun also
  
  Delphi-Quellcode:

  Var S: AnsiString;
  
  S := '<root>â</root>';
  XML.LoadFromXML(S, xeIso8859_1, False);
  
  XML.LoadFromXML('<root>â</root>', xeIso8859_1, False);
  
  // bzw. direkt für D2009 (sonst würde die UnicodeVersion aufgerufen
  // und Unicode nach ISO-8859 geht nicht mehr)
  XML.LoadFromXML(AnsiString('<root>â</root>'), xeIso8859_1, False);

• wollte eigentlich noch dieses unterstützen,
  XML.asXML[xeIso8859_1] := '<root>â</root>'; aber leider klappt das mit den Vorgabewerten bei den Parametern nicht
  und man müßte immer eine Kodierung angeben.
  also hab ich's weggelassen und es ist da immer UTF8
  
• die bisher freie Umschaltmöglichkeit der Kodierung wurde begrenzt und es kann nur noch umgeschaltet werden (via Prozessor-Style-Tag <?xml encoding="..."?> ), wenn der Zeichensatz mindestens eine gleich große Char-Size aufweist.
  
  also von Unicode nach UTF-8 umschalten geht nicht mehr
  - Grund dafür sind die Änderungen, welche einem nun erlauben das Encoding vorzugeben/abzuschalten
  und weshalb ich selber nicht mehr die volle Kontrolle über die Kodierung/Speicherbelegung hab.
  ein halbes Char in einem UnicodeString ist halt nicht möglich und darum mußte ich eine Sperre einbauen.
  
• dann hab ich mir mal erlaubt die Dateiheader und settings aufzuräumen
  
• da Delphi ja einige Probleme mit geänderten Compilerschaltern in den Projektoptionen hat:
  + mit der includen der himXMLCheck.inc, nach dem Usesabschnitt, kann nun im eigenen Projekt geprüft werden, ob die Units des himXML mit den selben Basisoptionen kompiliert wurden, wie das Projekt
  + in meinen Units wurde eine ähnliche "Selbstüberwachnung" ebenfalls integriert
  > es gibt dann eine Compilerwarnung, welche auffordert die Units neu zu compilieren

[himitsu]

Ups, da gab's nen größeren Fehler in der Encodierung

Der reichte von falscher Decodierung, über fälschlicher Beschuldigung einer falschen Codierung, obwohl sie womöglich doch korrekt war,
über einen Pufferüberlauf, bzw. einer Exception, weil außerhalb des Puffers lesend zugegriffen wurde

Grund: der Lesepuffer wurde bei Änderung der Codierung (via <?xml-Tag) falsch geleert und der Zeiger nicht zurückgesetzt

Update siehe Post #1 > v0.94

[holliesoft]

Hi,

ich nutze seit einigen Wochen himXML für einen kleinen RSS Feedreader und habe mit der neuesten (Beta)Version vom 18.07. leider das Problem, dass beim Parsen einiger Feeds (u.a. bei der DP) ein Fehler auftritt.

Hier der Text von der himXML Exception:

Delphi-Quellcode:

EXMLException (TXMLFile.ParsingTree):
invalid closing tag - node #0022description#22 is not opened

error at byte position 389 ("</description>#0A    <image>#0A#09   <title>Delphi-PRAXiS</title>#0A#09   <url>http://www.delphipraxis.net/misc/banner/banner_dp_130_100.g..." on line 1)

Anbei die XML-Datei...

Gruß
Patrick

[himitsu]

Also hier kann ich mal beruhigt die Schuld dem bösen Daniel R. Wolf in die Schuhe schieben,

denn die angehängte Datei ist nicht korrekt kodiert, bzw. enthält ungültige Zeichen.
z.B. das Markierte #$0F im Anhang Unbenannt.png .
Dieses Zeichen ist laut Spezifikation in XML-Dateien nicht als gültiges "Char" definiert.

Aber zum Glück hab ich für so'nen Fall schon vorsorglich vorgesorgt.

Lösung:
laß "ungültige" Zeichen in ein Leerzeichen umwandeln

Delphi-Quellcode:

XML.Options := XML.Options + [xoChangeInvalidChars];
XML.LoadFromFile('..\Feed_1242DP.xml');

Und ich überleg mir grad, ob ich diese Option nicht gleich mit in die Standardoptionen aufnehmen soll?

[himitsu]

eigentlich kaum erwähnenswert, aber da ich vorhin eine Nachricht bekam, daß etwas nicht mehr geht ...

• die Interfaces werden jetzt wieder richtig "deaktiviert", wenn sie nicht benötigt werden, da einige Compiler (D2006 & D2007) nicht mit überladenen Defaultproperties in Interfaces klar kommen.
• es wurden die Projektdateien für's "alte" BDS hinzugefügt (*.bdsproj & *.groupproj), damit auch diese Nutzer in den Demos die voreingestellten Suchpfade der Projektoptionen nutzen können.