himXML (gesprochen himix ML)

[Zwoetzen]

Das mit der Kodierung muss ich ein andern mal in Ruhe anschauen, auf Anhieb hatte es grad nicht geklappt.


Aber zu dem "Fehler":
Sollte XHTML nicht eigentlich valides XML sein? (Dass HTML keins ist, ist klar, dachte bisher, dass XHTML eigentlich gültiges XML sein sollte.)

Und mal von dem valide abgesehen: Sollte nicht das, was "reingetan" wird, bei .XMLText auch 1:1 wieder rauskommen? Denn ich würde es so verstehen, dass .XMLText den Inhalt eben 1:1 wiedergibt. (Ok, wenn der Testcode nicht erlaubt ist, ist die Korrektheit natürlich nichtmehr garantiert.)

[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?