xmldom ist ein Javascript-Ponyfill, um die folgenden APIs, die in modernen Browsern vorhanden sind, für andere Laufzeiten bereitzustellen:
- Konvertieren Sie einen XML-String in einen DOM-Baum
new DOMParser().parseFromString(xml, mimeType) => DocumentNach dem Login kopieren
- Erstellen, Zugreifen und Ändern eines DOM-Baums
new DOMImplementation().createDocument(...) => DocumentNach dem Login kopieren
- Serialisieren Sie einen DOM-Baum zurück in einen XML-String
new XMLSerializer().serializeToString(node) => stringNach dem Login kopieren
Quelle: xmldom readme
Seit ich im Juni 2020 angefangen habe, zur geforkten xmldom-Bibliothek beizutragen, gab es 40 Veröffentlichungen.
Es ist ein sehr interessantes und herausforderndes Projekt und wird höchstwahrscheinlich noch eine ganze Weile so bleiben.
Laut GitHub haben seit der Abspaltung über 50 Personen dazu beigetragen.
Nochmals vielen Dank an alle Mitwirkenden.
Dabei sind noch nicht alle Personen gezählt, denen es gelungen ist, vom ursprünglichen xmldom-Paket ohne Gültigkeitsbereich auf das @xmldom/xmldom-Paket mit Gültigkeitsbereich Version 0.7.0 umzusteigen, um alle Sicherheitsfixes zu erhalten.
Die neueste Version, die unter dem LTS-Tag veröffentlicht wurde, ist 0.7.13.
Die letzte Version mit wichtigen Änderungen war 0.8.0, die am 22. Dezember 2021, also vor fast 3 Jahren, veröffentlicht wurde.
Die aktuellste veröffentlichte Version ist 0.8.10.
Aber worüber ich heute sprechen möchte, sind all die Dinge, die seit Oktober 2022 unter dem nächsten Tag veröffentlicht wurden.
Ich freue mich sehr über diese Änderungen, da sie eine klare Grundlage für mögliche zukünftige Änderungen bieten.
TLDR: Mehr Übereinstimmung mit den Spezifikationen und Unterschiede werden so deutlich wie möglich gemacht.
Ein Aspekt, der die Implementierung komplex macht, ist, dass es unterschiedliche Regeln für das Parsen von XML und HTML gibt.
xmldom „unterstützte“ (bis zu einem gewissen Grad) beide Varianten von Anfang an. Es war nicht einmal erforderlich, überhaupt einen mimeType zu übergeben: Welche Regeln anzuwenden waren, wurde basierend auf dem aktuellen Standard-Namespace der XML-Zeichenfolge/des XML-Knotens entschieden, der gerade analysiert wurde.
Dies endet mit 0.9.0: Von nun an ist der mimeType in DOMParser.parseFromString(xml, mimeType) obligatorisch und das einzige, was jemals überprüft wird, um zu entscheiden, ob XML- oder HTML-Regeln angewendet werden sollen. Basta.
Und diese Informationen bleiben im resultierenden Dokument (neue Typeneigenschaft) erhalten, sodass bei der Serialisierung erneut die richtigen Regeln angewendet werden.
Dies war eine gewaltige (und möglicherweise bahnbrechende) Änderung, aber ich freue mich wirklich, dass sie fertig ist, da sie eine Menge damit verbundener Fehlerkorrekturen ermöglicht/viel einfacher zu implementieren macht und außerdem die Komplexität der API und der Implementierung reduziert.
Außerdem akzeptiert es jetzt nur die angegebenen MIME-Typen und löst in allen anderen Fällen einen TypeError aus.
Ein Aspekt, der mich persönlich an der Fehlerbehandlung der nativen Browser-API verwirrt, ist, dass sie immer ein Dokument zurückgibt und wenn etwas schief gelaufen ist, ein Parsererror-Knoten das erste untergeordnete Element des Körpers ist:
Da die Fehlerbehandlung in xmldom nie auf diese Weise funktionierte, die vorhandene Fehlerbehandlung jedoch sehr komplex und verwirrend und schlecht dokumentiert war, vereinfacht 0.9.0 sie und weist nun ein (viel) konsistenteres Verhalten gegenüber potenziellen Fehlern auf, die beim Parsen auftreten:
Es wirft einen ParseError ?, z.B. in einem der folgenden Fälle:
Es gibt immer noch Fälle, die als Warnung (insbesondere beim Parsen von HTML) oder als Fehler gemeldet werden, die die Verarbeitung der Daten nicht stoppen, aber die neue Fehlerbehandlung macht es sehr einfach, zu entscheiden, wie streng der Code ist Verwendet xmldom muss sein.
Die (nicht spezifikationskonforme) Option, die an den DOMParser-Konstruktor übergeben werden kann, heißt onError.
Es benötigt eine Funktion mit der folgenden Signatur:
function onError(level:ErrorLevel, message:string, context: DOMHandler):void;
Es ist eine Empfehlung, eine davon anzuwenden, um die XML-Verarbeitung beim ersten Signal eines unerwarteten Ereignisses zu stoppen:
// prevent parsing of XML that has `error`s new DOMParser({onError: onErrorStopParsing}).parseFromString(...) // prevent parsing of XML that has `warning`s new DOMParser({onError: onWarningStopParsing}).parseFromString(...)
Another fork of the original xmldom repository made it's way back into our repo by extending the HTML entities to the complete set (also available in 0.8.x) and porting over the implementation of the compareDocumentPosition API. Thank you, and welcome @zorkow
Along the way several places where xmldom so far returned undefined instead of null, have been fixed to adhere to the spec.
And I discovered that the former author seems to have preferred iterating from the end of a list in so many places, that attributes were processed in the reverse order in multiple places, which is now fixed.
The implementation of the removeChild API changed quite a bit, to comply to the spec and throws a DOMException when it should.
And 3 related bugs were fixed in a way that clearly states what the future direction of xmldom is:
Support for lax HTML parsing rules will only be provided if proper strict XML parsing doesn't suffer from it.
The former (broken) "support" for automatic self closing tags in HTML is gone.
More recently @shunkica invested a huge amount of time end effort to fix tons of issues in the former handling of the internalSubset part of the !DOCTYPE.
It is now preserved as part of the internalSubset property of the doctype of a Document and many wrong doctype declarations are now correctly detected as such and reported as a fatalError.
Also thanks to @kboshold for the latest bug fix in this area.
Along the way we created a new module containing regular expressions for the relevant grammar, and correctness checks are based on those and they are properly covered by tests.
It is not the goal of xmldom to become a validating parser, but this a great step to support those documents that come with more complex DTDs.
Up to now development was done using Node v10, since this is also the lowest version xmldom currently supports. As part of the work on the upcoming version, I decided to switch to v18 for development, since more and more devDependencies also made this a minimum requirement. This will be the new minimum runtime version for the time being starting with this release.
I initiated a public poll / dicussion to ask people which version of Node or other runtimes they need support for.
The next breaking release will most likely drop support for some older Node versions, if there is no feedback indicating something different.
Along the way plenty of APIs have received jsdoc comments with proper types.
for taking the time to read through all of this.
Those are quite some changes, and I'm very excited to be able to ship those.
I hope you are as excited as I am :)
If you need more details you can go through the very detailed changelog, or head over to the repository and join or start a discussion or file an issue.
Das obige ist der detaillierte Inhalt vonGeben Sie .f „@xmldom/xmldom' frei. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Was sind die Python-Bibliotheken für künstliche Intelligenz?
So lösen Sie das Problem, dass kein Internetzugang möglich ist, wenn der Computer mit dem WLAN verbunden ist
Windows kann die Lösung für das Zertifikat nicht finden
An welcher Börse gibt es FIL-Münzen?
So verwenden Sie div-Tags
getmonth()-Methode
So entfernen Sie das Wasserzeichen des Douyin-Kontos aus heruntergeladenen Videos von Douyin
Welches Format ist PNG?
