Trình phân tích cú pháp XML tốt nhất cho Java [đã đóng]


387

Tôi cần đọc các tệp XML nhỏ (ít nhất là MB, được mã hóa UTF-8), lục lọi xem xét các yếu tố và thuộc tính khác nhau, có thể sửa đổi một vài và viết lại XML ra đĩa (tốt nhất là với định dạng đẹp, thụt lề) .

Điều gì sẽ là trình phân tích cú pháp XML tốt nhất cho nhu cầu của tôi? Có rất nhiều để lựa chọn. Một số tôi biết là:

Và dĩ nhiên là cái trong JDK (Tôi đang sử dụng Java 6). Tôi quen thuộc với Xerces nhưng thấy nó thật rắc rối.

Khuyến nghị?


6
Tôi nghĩ rằng, bạn có thể tìm thấy nhiều người chơi hơn tại đây: xml.com/lpt/a/1703
dma_k

1
Tôi nghĩ rằng có những vấn đề thực sự với câu hỏi này. 1 là nó đang so sánh hoàn toàn không giống nhau, các trình phân tích cú pháp (xerces, đỏ thẫm) cùng với các thư viện thao tác dom (dom4j, xom, jdom). cũng là câu trả lời có xu hướng vận động và không mang tính xây dựng.
Nathan Hughes

51
+ 220 và không mang tính xây dựng. Người điều hành rõ ràng và người dùng có quan điểm khác nhau về những gì mang tính xây dựng.
tbroberg

5
Vâng, có vẻ như các mod rất thiển cận khi nói đến những câu hỏi như thế này. Có, các câu trả lời sẽ được đưa ra ý kiến ​​nhưng chắc chắn dựa trên kinh nghiệm và hầu hết các lần các câu trả lời được định lượng. Các mod cần tạo một thẻ có thể khác để di chuyển các câu hỏi này được mở để thảo luận dẫn đến sự chỉ trích và đầu ra mang tính xây dựng.
Ashraff Ali Wahab

@dma_k liên kết của bạn không hoạt động.
gaurav

Câu trả lời:


81

Nếu tốc độ và bộ nhớ không có vấn đề gì, dom4j là một lựa chọn thực sự tốt. Nếu bạn cần tốc độ, sử dụng trình phân tích cú pháp StAX như Woodstox là cách đúng đắn, nhưng bạn phải viết thêm mã để hoàn thành công việc và bạn phải làm quen với việc xử lý XML theo luồng.


6
dom4j là khá tốt, nhưng chắc chắn không phải không có vấn đề. Để biết các lựa chọn thay thế tốt cho dom4j, hãy xem stackoverflow.com/questions/831865/
Kẻ

@zehrer họ có an toàn không?
gaurav

257

Tôi nghĩ bạn không nên xem xét bất kỳ triển khai trình phân tích cú pháp cụ thể nào. API Java để xử lý XML cho phép bạn sử dụng bất kỳ triển khai trình phân tích cú pháp tuân thủ nào theo cách tiêu chuẩn. Mã phải dễ mang theo hơn nhiều và khi bạn nhận ra rằng một trình phân tích cú pháp cụ thể đã quá cũ, bạn có thể thay thế nó bằng một mã khác mà không thay đổi một dòng mã của bạn (nếu bạn làm đúng).

Về cơ bản, có ba cách xử lý XML theo cách tiêu chuẩn:

  • SAX Đây là API đơn giản nhất. Bạn đọc XML bằng cách định nghĩa một lớp Handler nhận dữ liệu bên trong các phần tử / thuộc tính khi XML được xử lý theo cách nối tiếp. Sẽ nhanh hơn và đơn giản hơn nếu bạn chỉ có kế hoạch đọc một số thuộc tính / yếu tố và / hoặc viết lại một số giá trị (trường hợp của bạn).
  • DOM Phương thức này tạo một cây đối tượng cho phép bạn sửa đổi / truy cập nó một cách ngẫu nhiên để tốt hơn cho việc xử lý và xử lý XML phức tạp.
  • StAX Đây là ở giữa con đường giữa SAX và DOM. Bạn chỉ cần viết mã để lấy dữ liệu từ trình phân tích cú pháp mà bạn quan tâm khi nó được xử lý.

Hãy quên các API độc quyền như JDOM hoặc Apache (tức là Apache Xerces XMLSerializer ) vì sẽ ràng buộc bạn với một triển khai cụ thể có thể phát triển kịp thời hoặc mất khả năng tương thích ngược, điều này sẽ khiến bạn thay đổi mã trong tương lai khi bạn muốn nâng cấp lên trong tương lai một phiên bản mới của JDOM hoặc bất kỳ trình phân tích cú pháp nào bạn sử dụng. Nếu bạn tuân thủ API tiêu chuẩn Java (sử dụng các nhà máy và giao diện), mã của bạn sẽ có tính mô đun và duy trì hơn nhiều.

Không cần phải nói rằng tất cả (tôi chưa kiểm tra tất cả, nhưng tôi gần như chắc chắn) các trình phân tích cú pháp được đề xuất tuân thủ triển khai JAXP để về mặt kỹ thuật bạn có thể sử dụng tất cả, bất kể đó là gì.


11
Trên thực tế, 3 cách: StAX (javax.xml.stream) là tiêu chuẩn thứ ba.
StaxMan


@kitokid Chrome nói với tôi rằng trang đó có những thứ khó chịu trên đó. Tôi đã sử dụng cái này thay thế: sce.uhcl.edu/yue/cifts/xml/notes/xmlparser/IntroDOM.asp
Ryan Shillington

Tổng quan tốt: chỉ có một điều tôi không đồng ý - trong khi đối với tăng / phát trực tuyến, SAX và Stax là tốt, API tiêu chuẩn đủ, đối với DOM thì đây không phải là trường hợp (IMO): có những lý do hợp lệ cho việc cụ thể của Java XOM, JDOM và DOM4J: ngôn ngữ bất khả tri DOM khá cồng kềnh khi sử dụng.
StaxMan

130

Đây là một so sánh tuyệt vời về DOM, SAX, StAX & TrAX (Nguồn: http://doad.oracle.com/docs/cd/E17802_01/webservice/webservice/docs/1.6/tutorial/doc/SJSXP2.html )

Tính năng THUẾ SAX DOM

Loại API                 Kéo, phát trực tuyến Đẩy, phát trực tuyến Trong quy tắc XSLT của cây bộ nhớ

Dễ sử dụng           Cao Trung bình Cao Trung bình

Khả năng XPath    Không Không Có Có Có

CPU & Bộ nhớ     Tốt Khác nhau Khác nhau

Chỉ chuyển tiếp        Có Có Không Không Không

Đọc XML              Có Có Có Có Có

Viết XML              Có Không Có Có Có

CRUD                      Không Không Có Không Không


7
Bạn có thể viết XML bằng SAX. Phần chìm cung cấp một triển khai xử lý mà người dùng có thể gọi các sự kiện SAX trên để tạo đầu ra XML. (Tôi thấy rằng bảng có nguồn gốc và không phải là tài liệu gốc, mặc dù bảng đã sai)
Dev


4

Ngoài SAX và DOM còn có phân tích STaX có sẵn bằng XMLStreamReader, là trình phân tích cú pháp kéo xml.


3

Tôi đã tìm thấy dom4j là công cụ để làm việc với XML. Đặc biệt so với Xerces.


2

Tôi không khuyến nghị rằng bạn có nhiều "suy nghĩ" trong ứng dụng của mình, nhưng sử dụng XSLT có thể tốt hơn (và có khả năng nhanh hơn với trình biên dịch XSLT-by-byte) so với thao tác Java.


3
Tốt hơn, có thể: nhanh hơn, rất khó xảy ra.
StaxMan

Đọc, thao tác và viết XML chính xác là những gì XSLT được thiết kế để làm. Đây là một câu trả lời tuyệt vời.
james.garriss

1

Nếu bạn quan tâm ít hơn về hiệu năng, tôi là một fan hâm mộ lớn của Apache Digester, vì về cơ bản, nó cho phép bạn ánh xạ trực tiếp từ XML sang Đậu Java.

Mặt khác, trước tiên bạn phải phân tích cú pháp, và sau đó xây dựng các đối tượng của bạn.


Tôi không cần tạo Đậu Java, chỉ cần thao tác các phần tử XML thô một chút và xem xét các phần tử nhất định để lấy dữ liệu từ chúng, vì vậy trình phân tích cú pháp kiểu DOM có lẽ là giải pháp lý tưởng của tôi.
Evan

Phải, dom4j có lẽ sẽ là một giải pháp tốt hơn ở đó ... Tôi đã từng sử dụng nó rất nhiều, cho đến khi tôi lên một cấp để tiêu hóa
Uri
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.