Найкращий аналізатор XML для Java [закритий]


387

Мені потрібно прочитати невеликі (щонайменше декілька Мб, максимум закодовані UTF-8) XML-файли, перекопатися, переглянувши різні елементи та атрибути, можливо, змінити декілька і знову записати XML на диск (бажано, з приємним, відступним форматуванням) .

Що було б найкращим аналізатором XML для моїх потреб? Є з чого вибрати. Я знаю:

І звичайно той, що в JDK (я використовую Java 6). Я знайомий з Xerces, але вважаю його незграбним.

Рекомендації?


6
Я думаю, ви можете знайти більше гравців тут: xml.com/lpt/a/1703
dma_k

1
Я думаю, що з цим питанням є реальні проблеми. 1 це - це порівняння, абсолютно не схоже на речі, грудоподібні аналізатори (xerces, малиновий) разом з бібліотеками маніпуляції dom (dom4j, xom, jdom). також відповіді прагнуть до адвокації і не є настільки конструктивними.
Натан Х'юз

51
+220 і не конструктивна. Очевидно, що модератори та користувачі мають різні точки зору на те, що є конструктивним.
тброберг

5
Так, здається, модники короткозорі, коли мова йде про такі питання. Так, відповіді будуть сумнівними, але, безумовно, ґрунтуються на досвіді, і більшість випадків відповіді оцінюються кількісно. Модам потрібно створити ймовірно інший тег для переміщення цих питань, відкритих для обговорення, що призводить до конструктивної критики та результатів.
Ашраф Алі Вахаб

@dma_k ваше посилання не працює.
gaurav

Відповіді:


81

Якщо швидкість і пам'ять - це не проблема, dom4j - це дійсно хороший варіант. Якщо вам потрібна швидкість, правильний спосіб використовувати аналізатор StAX на зразок Woodstox , але вам потрібно написати більше коду, щоб зробити все, і вам доведеться звикати обробляти XML в потоках.


6
dom4j досить добре, але точно не без проблем. Для хороших альтернатив DOM4J см stackoverflow.com/questions/831865 / ...
Jonik

@zehrer - вони безпечні для потоків?
gaurav

257

Я думаю, вам не слід враховувати будь-яку конкретну реалізацію парсера. Java API для обробки XML дозволяє використовувати будь-яку реалізацію відповідного аналізатора стандартним способом. Код повинен бути набагато більш портативним, і коли ви зрозумієте, що певний аналізатор вже занадто старий, його можна замінити іншим, не змінюючи рядок коду (якщо ви це зробите правильно).

В основному є три способи поводження з XML стандартним способом:

  • SAX Це найпростіший API. Ви читаєте XML, визначаючи клас Handler, який отримує дані всередині елементів / атрибутів, коли XML обробляється послідовно. Це швидше і простіше, якщо ви плануєте лише прочитати деякі атрибути / елементи та / або записати деякі значення назад (ваш випадок).
  • DOM Цей метод створює дерево об'єктів, яке дозволяє змінювати / отримувати доступ до нього випадковим чином, так що це краще для складних XML-маніпуляцій та обробки.
  • StAX Це посеред шляху між SAX та DOM. Ви просто пишете код, щоб витягти дані з аналізатора, який вас цікавить, коли вони обробляються.

Забудьте про власні API, такі як JDOM або Apache (тобто Apache Xerces XMLSerializer ), тому що ви прив’яжете вас до конкретної реалізації, яка може розвиватися в часі або втратити зворотну сумісність, що змусить вас змінити код у майбутньому, коли ви хочете оновити до нову версію JDOM або будь-який аналізатор, який ви використовуєте. Якщо ви будете дотримуватися стандартного API Java (використовуючи фабрики та інтерфейси), ваш код буде набагато більш модульним та ремонтом.

Не потрібно говорити, що всі (я не перевірив усіх, але я майже впевнений) пропоновані парсери відповідають вимогам реалізації JAXP, так що технічно ви можете використовувати всіх, незалежно від того.


11
Власне, 3 способи: StAX (javax.xml.stream) є третім стандартним.
StaxMan

1
java-samples.com/showtutorial.php?tutorialid=152 (особисто люблю SAX)
kitokid

@kitokid Chrome повідомляє мені, що на цій сторінці є неприємні речі. Я використовував це замість цього: sce.uhcl.edu/yue/courses/xml/notes/xmlparser/IntroDOM.asp
Райан

Хороший огляд: лише одне, з чим я не погоджуюся - хоча для інкрементальної / потокової передачі SAX і Stax хороші, стандартний API достатній, для DOM це не так (IMO): є вагомі причини, що стосуються Java, як XOM, JDOM і DOM4J: мовно-агностичний DOM досить громіздкий у використанні.
StaxMan

130

Ось приємне порівняння DOM, SAX, StAX та TrAX (Джерело: http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/docs/1.6/tutorial/doc/SJSXP2.html )

Особливість StAX SAX DOM TrAX

Тип API                 Витягнути, потокове нажимання, потокове передавання В дереві пам'яті Правило XSLT

Простота використання           Високий середній Високий Середній

Можливість XPath    Ні Ні Так Так

Процесор і пам'ять     Хороший Хороший

Тільки вперед Вперед        Так Так Ні Ні

Прочитайте XML              Так Так Так

Написати XML              Так Ні Так Так

CRUD                      Ні Ні Так Ні


7
Ви можете писати XML за допомогою SAX. Раковина забезпечує реалізацію обробника, на яку користувач може викликати події SAX, щоб генерувати вихід XML. (Я бачу, що таблиця розміщена, а не оригінальний матеріал, хоча таблиця помилкова)
Dev


4

На додаток до SAX та DOM існує розбір STaX, доступний за допомогою XMLStreamReader, який є синтаксичним аналізатором xml.



2

Я б не рекомендував це: у вас є багато "думок" у вашій програмі, але використання XSLT може бути кращим (і потенційно швидшим за допомогою компіляції XSLT до байтового коду), ніж маніпулювання Java.


3
Краще, можливо: швидше, дуже малоймовірно.
StaxMan

Читання, маніпулювання та запис XML - саме те, що призначено для XSLT. Це приємна нестандартна відповідь.
james.garriss

1

Якщо ви менше піклуєтесь про продуктивність, я є великим шанувальником Apache Digester, оскільки він по суті дозволяє вам здійснювати картування безпосередньо з XML на Java Beans.

В іншому випадку вам потрібно спочатку розібратися, а потім сконструювати свої об’єкти.


Мені не потрібно робити Java Beans, просто трохи маніпулюйте сирими XML-елементами та переглядайте певні елементи, щоб отримати з них дані, тому аналізатор стилю DOM, мабуть, є ідеальним рішенням.
Еван

Так, dom4j, мабуть, буде кращим рішенням для цього ... Я звик користуватися нею, поки я не перейшов на один рівень до копальника
Урі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.