lxml là gì?
Trình duyệt thu thập không cần lỗi cung cấp thực thi trình duyệt đám mây cho các trang động mà HTML đã được kết xuất của chúng có thể trở thành đầu vào cho các trình phân tích Python như lxml.
lxml là một thư viện Python để xử lý XML và HTML. Nó cung cấp khả năng phân tích dựa trên cây, duyệt tài liệu, truy vấn XPath và khả năng biến đổi XML thông qua một giao diện được xây dựng xung quanh mô hình ElementTree. Trong thu thập dữ liệu web, lxml thường chuyển đổi một tài liệu đã thu được thành các trường thay vì điều khiển toàn bộ quá trình thu thập.
Thư viện này đặc biệt hữu ích khi cấu trúc quan trọng như văn bản nhìn thấy. Một feed XML có thể phân biệt các phần tử thông qua không gian tên. Một mô tả HTML có thể phân chia một câu qua nhiều thẻ lồng nhau. Việc trích xuất chính xác phụ thuộc vào việc hiểu cấu trúc đó trước khi làm phẳng nó thành một bảng tính hoặc hàng cơ sở dữ liệu.
lxml có gì bên trong?
lxml cung cấp giao diện Python cho việc xử lý XML và HTML được hỗ trợ bởi libxml2 và libxslt. Giao diện etree xử lý các cây phần tử và các thao tác liên quan đến XML, trong khi lxml.html thêm các tiện ích cho tài liệu HTML. Những bề mặt này chồng chéo lên nhau, nhưng giả định phân tích của chúng và các phương thức cụ thể cho tài liệu là điều đáng phân biệt.
Cái mô hình cây phần tử lxml đại diện cho các phần tử với thuộc tính, trẻ em, và các thuộc tính liên quan đến văn bản. Bạn có thể điều hướng cây đó trực tiếp hoặc đánh giá một truy vấn trên nó. Đối với một quy trình trích xuất, sự lựa chọn phụ thuộc vào biểu thức nào làm cho mối quan hệ giữa các nút nguồn và các trường đầu ra dễ dàng duy trì hơn.
lxml cũng hỗ trợ tuần tự hóa tài liệu và các biến đổi. Những khả năng đó làm cho nó hữu ích cho việc chuyển đổi feed và xử lý đánh dấu có kiểm soát, ngoài việc thu thập. Một dự án không nhất thiết phải sử dụng mọi bề mặt: một bộ thu thập HTML có thể dựa vào một tập hợp nhỏ các thao tác phân tích và lựa chọn trong khi để các tính năng biến đổi không được sử dụng.
Phân tích HTML và phân tích XML có các hợp đồng khác nhau
Phân tích HTML được thiết kế để chứa đựng HTML không hoàn hảo, trong khi phân tích XML thường mong đợi một tài liệu có cấu trúc tốt. Sự lựa chọn trình phân tích thay đổi cây mà ứng dụng nhận được và các lỗi mà nó nên mong đợi. Chỉ có phần mở rộng tập tin thôi là không đủ để thiết lập chế độ chính xác.
Cái cấu hình trình phân tích lxml miêu tả hành vi phục hồi, tùy chọn mã hóa, và các điều khiển cụ thể cho XML. Khôi phục HTML có thể xây dựng một cây khả dụng từ đầu vào bị hỏng, nhưng không thể đảm bảo rằng mọi mối quan hệ dự kiến vẫn tồn tại. Một trình phân tích XML có thể từ chối các lỗi cấu trúc mà một trình phân tích HTML sẽ chấp nhận.
Đối với một feed XML, giữ thông tin không gian tên và tên phần tử không thay đổi. Gửi XML qua một con đường thiên về HTML có thể làm cho một tài liệu bị hỏng trông khả dụng trong khi thay đổi cách mà nó được diễn giải. Đối với một trang HTML, đối xử với đánh dấu web thông thường như XML nghiêm ngặt có thể từ chối các tài liệu mà một trình duyệt hiển thị thường xuyên.
Xác nhận ở cấp độ ứng dụng sau khi phân tích. Một cây tồn tại không phải là bằng chứng rằng một feed chứa các phần tử mục đích đã mong đợi hoặc rằng một danh sách có tiêu đề hợp lệ. Ghi lại chế độ trình phân tích đã chọn với các ví dụ trích xuất để các thay đổi trong tương lai không âm thầm thay đổi hợp đồng tài liệu.
XPath mô tả mối quan hệ trong cây
XPath chọn các nút và tính toán giá trị bằng cách sử dụng đường dẫn, các điều kiện, và các mối quan hệ tài liệu. Nó hữu ích khi một trường liên kết với một nhãn láng giềng hoặc một tổ tiên cụ thể thay vì một tên lớp thuận tiện. lxml hỗ trợ các biểu thức XPath thông qua các giao diện cây và phần tử của nó.
Cái mô hình biểu thức XPath phân biệt bối cảnh của một truy vấn từ tài liệu lớn hơn. Trong một vòng lặp mục, một truy vấn tương đối có thể vẫn nằm trong mục hiện tại, trong khi một truy vấn tuyệt đối hoặc phạm vi tài liệu có thể chọn giá trị ở nơi khác. Một truy vấn trả về văn bản vẫn có thể liên kết văn bản sai với bản ghi hiện tại.
Đối với một danh mục phụ tùng minh họa, xác định phần tử đại diện cho một phần trước khi trích xuất tên và các giá trị thông số của nó. Nếu một thông số bị thiếu, truy vấn nên tạo ra một trường vắng cho phần đó. Chọn mỗi thông số trong tài liệu và ghép nối các kết quả theo vị trí có thể chuyển giá trị vào các hàng sai.
Sử dụng các biểu thức mà rõ ràng phơi bày mối quan hệ. Một truy vấn ngắn hơn không tự động là một truy vấn tốt hơn, và một con đường vị trí dài hơn có thể bị ràng buộc quá chặt với một bố cục. Giữ truy vấn và một mảnh nguồn đại diện cùng nhau trong quy trình bảo trì của bạn để người xem có thể thấy lý do tại sao mối quan hệ đó là hợp lệ.
Không gian tên giải thích nhiều kết quả XML trống
Không gian tên XML phân biệt tên phần tử bằng URI không gian tên, vì vậy một nhãn thẻ hiển thị một mình có thể không xác định phần tử mà bạn muốn. Một tài liệu có thể đặt các phần tử của nó trong một không gian tên mặc định mà không hiển thị tiền tố trên mỗi thẻ. Các truy vấn vẫn cần phải tính đến không gian tên đó.
Cái mapping không gian tên XPath lxml cho phép một ứng dụng ánh xạ một tiền tố truy vấn tới URI liên quan. Tiền tố được sử dụng trong truy vấn không nhất thiết phải khớp với tiền tố mà tài liệu nguồn đã chọn; URI không gian tên cung cấp bản sắc. Điều này ngăn các lựa chọn định dạng nguồn trở thành những phụ thuộc ngẫu nhiên.
Nếu một truy vấn XML đột ngột trả về không có gì, hãy kiểm tra tên phần tử đủ điều kiện và các khai báo không gian tên trước khi loại bỏ việc xử lý không gian tên. Một nhà xuất bản feed có thể đã thay đổi không gian tên hoặc giới thiệu một lớp bọc. Việc kết hợp mọi tên cục bộ có thể che giấu vấn đề và kết hợp các phần tử có cùng tên từ các từ vựng khác nhau.
Việc trích xuất văn bản cần nhiều hơn thuộc tính văn bản đầu tiên
Văn bản trong cây lxml có thể được phân phối qua một phần tử và các phần tử con của nó, bao gồm cả văn bản theo sau các phần tử con. Đọc chỉ thuộc tính văn bản đầu tiên có thể cắt bỏ một câu chứa từ nhấn mạnh hoặc một liên kết nội tuyến. Chọn một thao tác phù hợp với phạm vi văn bản hoàn chỉnh bạn cần.
Trong mô hình ElementTree, văn bản trước một phần tử con và văn bản sau phần tử đó được lưu trữ riêng biệt. Phần sau gọi là văn bản đuôi. Các phương pháp định hướng HTML có thể thu thập văn bản của các phần tử con mà không có chú thích, nhưng ứng dụng của bạn vẫn quyết định cách chuẩn hóa khoảng trắng và liệu các khối liền kề có cần bộ phân tách hay không.
Bảo tồn sự khác biệt giữa văn bản hiển thị và giá trị máy. Một trang sản phẩm có thể hiển thị một số tiền định dạng bên cạnh ký hiệu tiền tệ trong khi một thuộc tính giữ một định danh. Đừng chuyển đổi tất cả các chuỗi được trích xuất thông qua cùng một hàm làm sạch. Tiêu đề, định danh, mô tả phong phú và các trường số có các quy tắc chính xác khác nhau.
| Chi tiết Tài liệu | Sai lầm Thông thường | Kiểm tra Tốt hơn |
|---|---|---|
| Thẻ nội tuyến lồng nhau | Chỉ đọc giá trị văn bản đầu tiên của phần tử. | Kiểm tra toàn bộ văn bản của các phần tử con và khoảng cách. |
| Không gian tên XML mặc định | Truy vấn một tên không đủ điều kiện. | Ánh xạ URI không gian tên một cách rõ ràng. |
| Thông số tùy chọn | Ghép cặp danh sách kết quả toàn cầu theo vị trí. | Trích xuất trong mỗi bộ chứa mục. |
| HTML bị lỗi | Giả định khôi phục giữ nguyên ý định. | Xác thực cấu trúc bản ghi đã khôi phục. |
Tài liệu lớn yêu cầu một chiến lược bộ nhớ
Xử lý tài liệu lớn cần một lựa chọn có chủ đích giữa việc giữ lại toàn bộ cây và tiêu thụ các phần tử một cách dần dần. Một cây hoàn chỉnh rất tiện lợi cho việc điều hướng tùy ý. Phân tích dần dần hữu ích khi đầu vào bao gồm nhiều bản ghi độc lập có thể được xử lý và giải phóng theo thứ tự.
Giao diện iterparse của lxml cung cấp các sự kiện khi tài liệu được phân tích, nhưng đọc dần dần một mình không đảm bảo sử dụng bộ nhớ thấp. Ứng dụng vẫn có thể giữ lại các phần tử, đối tượng kết quả hoặc tham chiếu cha. Giải phóng dữ liệu đã xử lý chỉ sau khi các phần tử con yêu cầu đã được đọc và tránh giữ lại các tham chiếu không cần thiết đến cây gốc.
Đo lường toàn bộ đường đi. Một bộ phân tích có thể sử dụng bộ nhớ khiêm tốn trong khi danh sách đầu ra phát triển không giới hạn. Một giai đoạn lưu trữ ghi lại các bản ghi được chấp nhận một cách dần dần có thể quan trọng hơn một tối ưu hóa phân tích nhỏ. Theo dõi kích thước tài liệu, các bản ghi đã giữ, và bộ đệm đầu ra một cách độc lập khi chẩn đoán một lần nhập lớn.
Cài đặt bộ phân tích cho XML không đáng tin cậy cũng xứng đáng với một quyết định rõ ràng. Tải tài liệu bên ngoài và xử lý thực thể là tách biệt với việc chọn các trường bình thường. Sử dụng các điều khiển được tài liệu cho phiên bản bộ phân tích đã cài đặt và đầu vào bạn chấp nhận, thay vì nới lỏng các hạn chế chỉ để làm cho một tài liệu không được giải thích phân tích.
Cách lxml Hoạt động Với Beautiful Soup và Lấy Dữ liệu từ Trình duyệt
lxml có thể được sử dụng trực tiếp hoặc như một backend phân tích cho Beautiful Soup, trong khi việc lấy dữ liệu từ trình duyệt cung cấp các tài liệu cần thực thi trang. Sử dụng lxml trực tiếp cung cấp cho bạn cây gốc và bề mặt truy vấn của nó. Beautiful Soup bổ sung giao diện duyệt của riêng mình trên một bộ phân tích được chọn. Đây là các lớp tương thích chứ không phải các danh mục sản phẩm loại trừ lẫn nhau.
Đối với trang động, Scrapeless Scraping Browser cung cấp thực thi trình duyệt cần thiết trước khi trích xuất. Dịch vụ Tổng quan về Trình duyệt Scraping mô tả hoạt động của trình duyệt được quản lý. lxml sau đó làm việc trên chú thích đã thu được và không kế thừa một phiên trình duyệt sống từ chuỗi HTML.
Các phương pháp Trích xuất HTML liên quan giúp đặt việc phân tích trong một quy trình thu thập lớn hơn. Sử dụng Giá cả Scrapeless khi cần lấy dữ liệu từ trình duyệt, và giữ lại phân tích trực tiếp cho các tài liệu đã chứa thông tin cần thiết.
Kết luận
lxml là một lựa chọn tốt cho các quy trình làm việc Python cần xử lý cây HTML hoặc XML chính xác. Chọn chế độ phân tích đúng, tôn trọng không gian tên, và xác thực các mối quan hệ văn bản và trường trước khi tối ưu hóa thông lượng. Giá trị của nó đến từ việc làm cho cấu trúc tài liệu có thể sử dụng; việc lấy dữ liệu, phạm vi thu thập, và xác thực doanh nghiệp vẫn là những phần rõ ràng của ứng dụng.
Lấy HTML Động cho Bộ Phân Tích Python của Bạn
Sử dụng Scrapeless Scraping Browser khi tài liệu cần thực thi trình duyệt, sau đó áp dụng các quy tắc trích xuất và xác thực lxml của bạn.
Đăng ký ngay hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.
Khiếu nại tín dụng $5 của bạn →Câu hỏi thường gặp
Hỏi: lxml có thực thi JavaScript không?
lxml không thực thi các kịch bản trong một tài liệu HTML. Nó phân tích chú thích cung cấp cho nó. Nếu các phần tử cần thiết chỉ tồn tại sau khi trình duyệt kết xuất trang, hãy lấy trạng thái đã kết xuất đó trước khi áp dụng các truy vấn lxml.
Hỏi: Tại sao XPath lại bỏ lỡ các phần tử có thể nhìn thấy trong XML?
Một truy vấn XPath có thể bỏ lỡ các phần tử XML có thể nhìn thấy vì tên của chúng thuộc về một không gian tên mà truy vấn không đề cập. Kiểm tra URI không gian tên và ánh xạ nó trong truy vấn. Cũng xác nhận liệu biểu thức có tương đối với phần tử hiện tại hay bắt đầu từ gốc tài liệu.
Hỏi: lxml có phải là một sự thay thế cho Beautiful Soup không?
Bạn có thể sử dụng lxml trực tiếp như một giao diện phân tích, hoặc chọn nó làm backend cho Beautiful Soup. Việc sử dụng trực tiếp lxml làm lộ cây gốc và khả năng XPath của nó. Beautiful Soup cung cấp một giao diện điều hướng khác trong khi vẫn phụ thuộc vào bộ phân tích đã chọn để xây dựng cây.
Hỏi: Phân tích gia tăng có luôn giảm bộ nhớ không?
Phân tích gia tăng làm giảm nhu cầu đọc và giữ một tài liệu cùng một lúc chỉ khi ứng dụng cũng giải phóng các phần tử đã xử lý và giới hạn các bộ đệm đầu ra của nó. Giữ tham chiếu đến từng phần tử hoặc thu thập mọi kết quả vào một danh sách có thể bảo tồn nhiều chi phí bộ nhớ.