Miglior parser XML per Java [chiuso]


387

Ho bisogno di leggere piccoli file XML (pochi MB al massimo, codificati UTF-8), frugare guardando vari elementi e attributi, forse modificarne alcuni e riscrivere l'XML di nuovo sul disco (preferibilmente con una formattazione piacevole e rientrata) .

Quale sarebbe il miglior parser XML per le mie esigenze? Ci sono molte tra cui scegliere. Alcuni di cui sono a conoscenza sono:

E ovviamente quello nel JDK (sto usando Java 6). Conosco Xerces ma lo trovo goffo.

Raccomandazioni?


6
Penso che puoi trovare più giocatori qui: xml.com/lpt/a/1703
dma_k

1
penso che ci siano problemi reali con questa domanda. 1 è che sta confrontando totalmente diversamente dalle cose, raggruppando parser (xerces, crimson) insieme a librerie di manipolazione dom (dom4j, xom, jdom). anche le risposte tendono alla difesa e non sono così costruttive.
Nathan Hughes,

51
+220 e non costruttivo. Chiaramente, i moderatori e gli utenti hanno prospettive diverse su ciò che è costruttivo.
tbroberg,

5
Sì, sembra che le mod siano miopi quando si tratta di domande come questa. Sì, le risposte sarebbero motivate ma sicuramente basate sull'esperienza e il più delle volte le risposte sono quantificate. Le mod devono creare probabilmente un tag diverso per spostare queste domande che sono aperte alla discussione, il che si traduce in critiche costruttive e risultati.
Ashraff Ali Wahab,

@dma_k il tuo link non funziona.
gaurav,

Risposte:


81

Se la velocità e la memoria non sono un problema, dom4j è davvero un'ottima opzione. Se hai bisogno di velocità, usare un parser StAX come Woodstox è il modo giusto, ma devi scrivere più codice per fare le cose e devi abituarti a elaborare XML nei flussi.


6
dom4j è abbastanza buono, ma sicuramente non senza problemi. Per buone alternative DOM4J, vedere stackoverflow.com/questions/831865/...
Jonik

@zehrer sono thread-safe?
gaurav,

257

Penso che non dovresti considerare alcuna implementazione specifica del parser. L'API Java per l'elaborazione XML consente di utilizzare qualsiasi implementazione parser conforme in modo standard. Il codice dovrebbe essere molto più portabile e quando ti rendi conto che uno specifico parser è diventato troppo vecchio, puoi sostituirlo con un altro senza cambiare una riga del tuo codice (se lo fai correttamente).

Fondamentalmente ci sono tre modi per gestire XML in modo standard:

  • SAX Questa è l'API più semplice. Si legge l'XML definendo una classe Handler che riceve i dati all'interno di elementi / attributi quando l'XML viene elaborato in modo seriale. È più veloce e più semplice se prevedi di leggere solo alcuni attributi / elementi e / o riscrivere alcuni valori (il tuo caso).
  • DOM Questo metodo crea un albero degli oggetti che consente di modificarlo / accedervi in ​​modo casuale, quindi è meglio per manipolazioni e manipolazioni XML complesse.
  • StAX Si trova nel mezzo del percorso tra SAX e DOM. Devi solo scrivere il codice per estrarre i dati dal parser che ti interessa quando viene elaborato.

Dimentica le API proprietarie come JDOM o Apache (ad esempio Apache Xerces XMLSerializer ) perché ti legherà a un'implementazione specifica che può evolversi nel tempo o perdere la compatibilità con le versioni precedenti, che ti farà cambiare il tuo codice in futuro quando desideri eseguire l'aggiornamento a una nuova versione di JDOM o qualsiasi parser che usi. Se ti attieni all'API standard Java (usando fabbriche e interfacce) il tuo codice sarà molto più modulare e gestibile.

Non c'è bisogno di dire che tutti (i non ho controllato tutti, ma sono quasi sicuro) dei parser proposti sono conformi a un'implementazione JAXP in modo che tecnicamente tu possa usare tutto, indipendentemente da quale.


11
In realtà, 3 modi: StAX (javax.xml.stream) è il terzo standard.
StaxMan,


@kitokid Chrome mi dice che la pagina contiene cose brutte. Ho usato questo invece: sce.uhcl.edu/yue/courses/xml/notes/xmlparser/IntroDOM.asp
Ryan Shillington

Buona panoramica: solo una cosa su cui non sarei d'accordo - mentre per incrementale / streaming, SAX e Stax sono buoni, API standard sufficiente, per DOM non è questo il caso (IMO): ci sono ragioni valide per take specifici di Java come XOM, JDOM e DOM4J: il DOM indipendente dal linguaggio è piuttosto complicato da usare.
StaxMan

130

Ecco un bel confronto su DOM, SAX, StAX e TrAX (Fonte: http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/1.6/tutorial/doc/SJSXP2.html )

Caratteristica StAX SAX DOM TrAX

Tipo di API                 Pull, streaming Push, streaming Nell'albero della memoria Regola XSLT

Facilità d'uso           Alta Media Alta Media

Capacità XPath    No No Sì Sì

CPU e memoria     Buono Buono Varia

Solo avanti        Sì Sì No No

Leggi XML              Sì Sì Sì Sì

Scrivi XML              Sì No Sì Sì

CRUD                      No No Sì No


7
Puoi scrivere XML con SAX. Il sink fornisce un'implementazione del gestore che l'utente può chiamare eventi SAX per generare output XML. (Vedo che il tavolo è di provenienza e non materiale originale, ma il tavolo è sbagliato)
Dev


4

Oltre a SAX e DOM è disponibile l'analisi STaX tramite XMLStreamReader che è un parser pull XML.


3

Ho trovato dom4j lo strumento per lavorare con XML. Soprattutto rispetto a Xerces.


2

Non lo consiglierei se hai un sacco di "pensieri" nella tua app, ma usare XSLT potrebbe essere migliore (e potenzialmente più veloce con la compilazione da XSLT a bytecode) della manipolazione Java.


3
Meglio, possibile: più veloce, molto improbabile.
StaxMan,

Leggere, manipolare e scrivere XML è esattamente ciò che XSLT è progettato per fare. Questa è una bella risposta pronta all'uso.
james.garriss,

1

Se ti preoccupi meno delle prestazioni, sono un grande fan di Apache Digester, dal momento che essenzialmente ti consente di mappare direttamente da XML a Java Beans.

Altrimenti, devi prima analizzare e quindi costruire i tuoi oggetti.


Non ho bisogno di creare Java Beans, basta manipolare un po 'gli elementi XML grezzi e rivedere alcuni elementi per ottenere dati da essi, quindi un parser in stile DOM è probabilmente la mia soluzione ideale.
Evan,

Sì, dom4j probabilmente sarebbe una soluzione migliore lì ... Lo usavo pesantemente, fino a quando non sono salito di livello fino al digestore
Uri,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.