DOM là gì? Hướng dẫn thực hành cho công việc dữ liệu web

Trình duyệt thu thập dữ liệu không có scrapeless chạy trang trong một trình duyệt đám mây để các quy trình dữ liệu có thể kiểm tra DOM sau khi trang đã được tải và thay đổi.

DOM là gì?

Mô hình Đối tượng Tài liệu, thường được viết tắt là DOM, là đại diện trong bộ nhớ của trình duyệt về một tài liệu dưới dạng cây các đối tượng. HTML cung cấp mã nguồn, trong khi trình duyệt phân tích mã đó và tạo ra các nút cho tài liệu, các phần tử, văn bản, bình luận và các phần khác của tài liệu. Các chương trình sau đó có thể đọc hoặc thay đổi các nút đó thông qua các API trình duyệt tiêu chuẩn.

DOM không giống với tệp HTML được trả về bởi máy chủ. Nội dung phản hồi là đầu vào. DOM là kết quả được phân tích và sống bên trong một ngữ cảnh duyệt web. Một trình duyệt có thể sửa chữa việc lồng ghép bị lỗi, thêm các phần tử ngụ ý, mở rộng các mẫu, gắn các cây bóng, hoặc cho phép JavaScript tạo ra và loại bỏ các nút sau khi phản hồi ban đầu đến. Đó là lý do tại sao Xem Nguồn và bảng Các phần tử có thể hiển thị các cấu trúc khác nhau.

Cây DOM ghi lại các mối quan hệ. Tài liệu chứa một phần tử HTML; phần tử đó chứa các nhánh đầu và thân; các nhánh đó chứa các hậu duệ như tiêu đề, liên kết, mẫu, bảng và nút văn bản. Mối quan hệ giữa cha, con, anh chị em và hậu duệ cung cấp cho các bộ chọn CSS, biểu thức XPath, công cụ truy cập, bài kiểm tra và mã thu thập dữ liệu một cách chia sẻ để định vị nội dung.

Sự khác biệt chính là thực tiễn: một quy trình làm việc dữ liệu nên xác định lớp sở hữu giá trị mục tiêu. Lớp đó có thể là phản hồi tài liệu, bộ nhớ trình duyệt, một nút đã được kết xuất, một phản hồi nền, hoặc một chính sách phía máy chủ. Khi lớp được biết đến, quy trình làm việc có thể thu thập giá trị với ít giả định hơn và xác thực nó dựa trên hành vi trang mà người dùng thực sự nhận được.

Cách hoạt động của Dom

DOM trở nên dễ dàng hơn để lý luận khi quá trình được chia thành các giai đoạn có thể quan sát. Mỗi giai đoạn tạo ra bằng chứng có thể được kiểm tra trong phản hồi, trình duyệt, nhật ký mạng, hoặc tập hợp hồ sơ được trích xuất.

Những giai đoạn này có thể chồng chéo, lặp lại, hoặc được xử lý bởi các hệ thống khác nhau. Kế hoạch trích xuất do đó nên theo dõi yêu cầu và chuỗi trạng thái thực tế thay vì giả định rằng một sự kiện tải trang đại diện cho toàn bộ vòng đời. Các công cụ phát triển trình duyệt rất hữu ích vì chúng đặt tài liệu, mạng, lưu trữ, và cái nhìn thời gian chạy bên cạnh nhau.

Các mẫu chính và các khái niệm liên quan

Các sự phân biệt sau đây ngăn chặn các lỗi loại thể thông thường. Chúng cũng giúp các nhóm chọn một bộ phân tích, khách hàng HTTP, trình duyệt, lập lịch, hoặc chính sách thu thập dữ liệu cho công việc.

Một nhãn chỉ hữu ích khi nó dự đoán hành vi. Nếu hai lộ trình trên cùng một trang web trả dữ liệu qua các lớp khác nhau, hãy coi chúng là các bề mặt trích xuất khác nhau ngay cả khi nhóm sản phẩm mô tả chúng bằng một thuật ngữ kiến trúc duy nhất. Quan sát cấp lộ trình vượt qua giả định cấp miền.

Tại sao điều này quan trọng đối với Web Scraping và Thu thập Dữ liệu

Việc thu thập trên web thường thất bại âm thầm khi nó đọc lớp sai. Một bộ phân tích cú pháp có thể trả về HTML hợp lệ mà thiếu các bản ghi mục tiêu. Một trình duyệt có thể tạo ra một lớp vỏ thuyết phục trong khi một yêu cầu cần thiết bị từ chối. Một chuỗi có thể trả về các lô đầy đủ trong khi lặp lại các bản ghi giống nhau. Các kiểm tra bên dưới kết nối DOM với chất lượng dữ liệu thay vì với sở thích công cụ.

Một trình duyệt là một lựa chọn bên trong cây quyết định đó. Trang sản phẩm Scrapeless Scraping Browser mô tả bề mặt trình duyệt quản lý, trong khi tài liệu bắt đầu Scraping Browser getting-started bao gồm các tham số kết nối và phiên. Sử dụng việc kết xuất trình duyệt chỉ cho các trạng thái cần thực hiện trên trình duyệt và giữ các lối đi lấy và phân tích đơn giản hơn cho nội dung đã có sẵn trong các phản hồi.

Một Quy trình Chẩn đoán Thực tế

Một chẩn đoán đáng tin cậy bắt đầu bằng cách so sánh, không phải mã tự động hóa. Bảo lưu phản hồi đầu tiên, quan sát giao diện trực tiếp và kết nối từng trường mục tiêu với sự kiện hoặc tài nguyên tạo ra nó.

1. So sánh nội dung phản hồi mạng với bảng Tham Elements. Nếu văn bản mục tiêu xuất hiện trong cả hai, một bộ phân tích cú pháp HTML nhẹ có thể là đủ; nếu nó chỉ xuất hiện trong Elements, việc kết xuất hoặc truy cập API trực tiếp là cần thiết.
2. Xác định bộ chứa ổn định nhỏ nhất sở hữu các bản ghi mục tiêu. Bắt đầu với các phần tử ngữ nghĩa, tên có thể truy cập, thuộc tính ổn định hoặc mẫu liên kết trước khi dựa vào các lớp định dạng.
3. Theo dõi bảng mạng trong khi nội dung xuất hiện. Một phản hồi JSON có cấu trúc đôi khi có thể cung cấp một nguồn sạch hơn so với việc duyệt hàng trăm nút trình bày.
4. Định nghĩa một điều kiện sẵn sàng rõ ràng, chẳng hạn như sự hiện diện của một thẻ kết quả và sự biến mất của một chỉ báo tải. Một sự kiện tải trang chung có thể xảy ra trước khi dữ liệu ứng dụng đến cây.
5. Kiểm tra các trạng thái rỗng, một phần và thay thế. Một bộ chọn chỉ có hiệu lực khi mọi trường đều có mặt sẽ tạo ra các khoảng trống im lặng khi các giá cả, huy hiệu hoặc mô tả tùy chọn bị bỏ qua.

Tài liệu kết quả dưới dạng một hợp đồng trích xuất nhỏ: mẫu URL mục tiêu, ngữ cảnh công cộng, lớp nguồn, điều kiện sẵn sàng, bộ chọn hoặc trường phản hồi, khóa duy nhất, quy tắc tiếp tục, quy tắc kết thúc và kiểm tra xác thực. Hợp đồng này bền hơn một kịch bản chứa cùng các giả định mà không đặt tên cho chúng.

Sử dụng chứng cứ từ tài liệu kỹ thuật chính khi định nghĩa hợp đồng. Các nền tảng phù hợp cho chủ đề này bao gồm MDN DOM scripting introduction WHATWG DOM Standard. Những nguồn đó mô tả hành vi nền tảng và giao thức; hành vi trực tiếp của trang mục tiêu vẫn cần được quan sát riêng.

Các Sai Lầm Thông Thường

Hầu hết các thất bại quanh DOM đến từ việc thay thế một tín hiệu tiện lợi cho trạng thái thực tế mà quy trình làm việc cần. Các sai lầm sau có thể trả về đầu ra hợp lý, điều này khiến chúng nguy hiểm hơn một lỗi rõ ràng.

• Coi nguồn trang là DOM cuối cùng sẽ bỏ lỡ các nút do client tạo ra và có thể đọc sai đánh dấu được trình duyệt sửa.
• Trích xuất mỗi nút văn bản thường bắt được việc điều hướng, nhãn ẩn, thông báo cookie, và các biến thể di động hoặc máy tính để bàn trùng lặp.
• Dựa vào bộ chọn theo vị trí sâu làm cho quy trình làm việc nhạy cảm với các bộ bọc vô hại và thay đổi bố cục.
• Đọc quá sớm tạo ra một bức tranh hợp lệ về cấu trúc nhưng không đầy đủ, đặc biệt khi các mục danh sách đến theo lô.
• Giả định rằng DOM chứa dữ liệu chuẩn có thể sai khi các giá trị được định dạng, bị cúp, ảo hóa, hoặc chỉ được giữ trong trạng thái ứng dụng.

Bảo vệ chống lại những thất bại này bằng cách đưa ra khẳng định ở cấp nội dung. Yêu cầu một bộ chứa đã biết, ít nhất một khóa ổn định khi kết quả được mong đợi, không có khóa trùng lặp trong một lô, thứ tự nhất quán khi thứ tự có ý nghĩa, và một trạng thái rỗng hoặc trạng thái kết thúc đã được công nhận.

Các Thực Hành Tốt Nhất cho Một Quy Trình Làm Việc Duy Trì

Thích ý nghĩa ổn định hơn vị trí hình ảnh. Các bộ chọn và quy tắc nên mô tả vai trò của một giá trị, không phải vị trí tạm thời của nó trong một bố cục. Khi một phản hồi có cấu trúc là nguồn công khai chính thống được sử dụng bởi trang, hãy bảo tồn ánh xạ trường liên quan và xác thực nó với nhãn đã được kết xuất.

Làm cho trạng thái rõ ràng. Ghi lại địa phương, viewport, lộ trình, giả định phiên công cộng, bộ lọc, thứ tự sắp xếp và giá trị tiếp tục. Một giá trị thiếu trạng thái của nó có thể là không thể so sánh với một bản chụp sau đó.

Tách biệt việc phát hiện, lấy, kết xuất và trích xuất. Mỗi giai đoạn có chi phí và chế độ thất bại khác nhau. Sự tách biệt cho phép một công việc chỉ kết xuất những URL cần thiết, xử lý lại các phản hồi đã lưu mà không cần lưu lượng mới, và kiểm tra các bản ghi chưa hoàn thiện trước khi chúng vào các hệ thống hạ nguồn.

Sử dụng công việc có giới hạn. Định nghĩa số trang tối đa, hành động cuộn, yêu cầu hoạt động và hồ sơ cho mỗi lần chạy. Giới hạn bảo vệ cả dịch vụ mục tiêu và hệ thống thu thập khi một vòng điều khiển tiếp theo, một con trỏ lặp lại, hoặc một trang tạo ra không gian thu thập không mong muốn.

Tôn trọng nhà xuất bản và người dùng. Kiểm tra robots.txt nơi áp dụng, tuân thủ các điều khoản và luật, chỉ thu thập các trường công khai cần thiết cho một mục đích xác định, tránh các khu vực riêng tư hoặc bị hạn chế, và giữ khối lượng yêu cầu trong một giới hạn bảo thủ. Truy cập kỹ thuật không giống như quyền sử dụng cho mọi mục đích.

Kết luận

DOM là mô hình hoạt động hữu ích nhất: xác định nơi dữ liệu tồn tại, quan sát cách mà trạng thái đó được sản xuất, và chọn phương pháp thu thập nhỏ nhất có thể tái tạo nó. Quy trình làm việc mạnh nhất so sánh trạng thái nguồn và trạng thái đã render, theo các tín hiệu tiếp tục rõ ràng, và xác thực các bản ghi với các khóa bền.

Bắt đầu với một URL đại diện và viết hợp đồng trích xuất trước khi mở rộng. Bước nhỏ đó lộ diện những giả định về thời gian, định tuyến, phân trang, và chính sách trong khi chúng vẫn còn rẻ để sửa chữa. Mở rộng chỉ sau khi quy trình làm việc có thể giải thích lý do tại sao mỗi bản ghi là hoàn chỉnh và mỗi trường đến từ đâu.