DOM là gì?

Scrapeless Agent Browser cung cấp một môi trường trình duyệt được quản lý để kiểm tra và tương tác với các trang web động.

DOM đại diện cho điều gì

DOM, hay Document Object Model, là một giao diện lập trình biểu diễn một tài liệu dưới dạng cây các đối tượng. Trình duyệt xây dựng cây đó từ HTML và cho phép script đọc hoặc thay đổi các node của nó. Tiêu chuẩn DOM định nghĩa mô hình dùng chung cho cây node và các sự kiện. JavaScript thường sử dụng mô hình này, nhưng JavaScript và DOM là hai thứ khác nhau: một là ngôn ngữ, và cái kia là giao diện tới một tài liệu.

Đối với công việc dữ liệu web, điểm khác biệt hữu ích là giữa HTML nhận được từ máy chủ và tài liệu tồn tại sau khi các script trên trang đã chạy. Một giá sản phẩm có thể không có trong phản hồi ban đầu và chỉ xuất hiện sau đó trong trình duyệt. Việc kiểm tra DOM có thể tiết lộ mức giá đó khi ứng dụng tạo ra nó. Chỉ đọc phản hồi ban đầu thì không thể phát hiện được một phần tử chưa được tạo.

Hãy hình dung một thẻ sản phẩm chứa tiêu đề, liên kết và giá. Phần tử thẻ là cha; các phần tử lồng bên trong là con. Hai thẻ trong cùng một danh sách là anh chị em. Các ký tự hiển thị bên trong tiêu đề nằm trong các node văn bản. Những mối quan hệ này cho phép bộ trích nhận diện đúng bản ghi trước khi đọc các trường của nó, thay vì thu thập mọi chuỗi trông giống giá trên trang.

Mã nguồn HTML, trạng thái DOM và điểm ảnh trên màn hình

Mã nguồn HTML, trạng thái DOM và màn hình đã render mô tả các giai đoạn khác nhau của một trang. Mã nguồn là văn bản đầu vào. DOM là cấu trúc tài liệu hiện tại. Màn hình đã render còn phụ thuộc vào kiểu dáng, bố cục, phông chữ, khung nhìn (viewport) và các hành vi render khác. Một node có thể tồn tại trong DOM nhưng vẫn bị ẩn khỏi người đang xem trang.

Đặc tả HTML parsing mô tả cách trình duyệt xây dựng tài liệu từ markup, bao gồm cách chúng xử lý đầu vào không hợp lệ. Điều đó quan trọng khi một tệp nguồn và bảng Elements của trình duyệt có vẻ không khớp nhau. Trình duyệt có thể đã sửa lại việc lồng nhau hoặc chèn thêm cấu trúc trong lúc phân tích cú pháp trước khi bất kỳ script ứng dụng nào thay đổi trang.

Một ảnh chụp màn hình trả lời câu hỏi cái gì đã được hiển thị trong một khung nhìn cụ thể. Một snapshot DOM trả lời những node và thuộc tính tài liệu nào có sẵn tại thời điểm chụp. Cả hai thứ này riêng lẻ đều không chứng minh rằng mọi sản phẩm trong một danh mục đã được tải. Ví dụ, một danh sách ảo hóa có thể chỉ giữ các mục đang cần trong tài liệu trong khi trình bày một tập hợp lớn hơn nhiều thông qua việc cuộn.

Vì vậy, một đặc tả trích xuất nên nêu rõ nguồn của nó: HTML gốc, DOM hiện tại, văn bản có thể truy cập, hoặc một nguồn dữ liệu có cấu trúc. Gọi tất cả những thứ này là “nội dung trang” sẽ che khuất những khác biệt sau đó trông giống như dữ liệu không nhất quán. Hãy lưu loại nguồn đã chọn cùng với bản ghi để người rà soát biết phương pháp thu thập thực sự có thể quan sát được gì.

Đọc phần tử mà không làm mất ranh giới bản ghi

Trích xuất DOM hoạt động tốt nhất khi việc chọn bắt đầu từ vùng chứa bản ghi. Xác định một thẻ sản phẩm, kết quả bài viết hoặc hàng trong bảng, rồi đọc các trường bên trong vùng chứa đó. Nếu tiêu đề và giá được chọn độc lập trên toàn bộ tài liệu, một thẻ quảng cáo hoặc giá bị thiếu có thể làm lệch danh sách và gán một mức giá cho sai sản phẩm.

Bộ chọn CSS mô tả các điều kiện để khớp phần tử. Đặc tả Selectors phân biệt các mối quan hệ cấu trúc như hậu duệ và con trực tiếp. Trong thực tế, “một liên kết nào đó bên trong thẻ này” và “một liên kết nằm trực tiếp dưới thẻ này” là những yêu cầu khác nhau. Hãy chọn mối quan hệ phản ánh cấu trúc của trang, rồi kiểm tra nó với các bản ghi tiêu biểu.

Văn bản của một phần tử và các thuộc tính của nó cũng có thể phục vụ những mục đích khác nhau. Văn bản hiển thị của một liên kết có thể là “Xem chi tiết”, trong khi đích đến của nó xác định sản phẩm. Nhãn giá có thể chứa ký hiệu tiền tệ và phần mô tả khuyến mại. Giữ nguyên văn bản thô cho đến khi các ý nghĩa đó đã được tách ra; loại bỏ ngay mọi ký tự không phải số có thể phá hủy thông tin về khoảng giá hoặc giá trả góp.

Ưu tiên một thuộc tính ổn định hoặc một mối quan hệ có ý nghĩa khi có thể. Tên class được sinh ra bởi quy trình build có thể thay đổi mà không có bất kỳ thay đổi nghiệp vụ nào trên trang. Tuy vậy, không có bộ chọn nào là đáng tin vĩnh viễn. Hãy lưu các ví dụ về bản ghi mong đợi và gắn cờ khi thiếu các trường nhận diện trước khi chấp nhận một lần trích xuất mới là hoàn tất.

Thời điểm làm thay đổi tài liệu bạn đọc

Một lượt đọc DOM quan sát một khoảnh khắc trong vòng đời ứng dụng. Tài liệu ban đầu có thể chứa các placeholder, trạng thái tiếp theo có thể hiển thị kết quả, và trạng thái muộn hơn có thể cập nhật tình trạng còn hàng sau khi chọn vị trí. Việc điều hướng thành công không chứng minh rằng trường mà quy trình của bạn cần đã sẵn sàng.

Hãy định nghĩa trạng thái sẵn sàng theo góc nhìn bản ghi. Một điều kiện hữu ích có thể yêu cầu mã định danh sản phẩm và biến thể đã chọn phải xuất hiện, với chỉ báo tải đã biến mất. Một điều kiện mạng ở cấp độ toàn trang có thể là lựa chọn tệ khi hệ thống phân tích hoặc quảng cáo vẫn tiếp tục gửi yêu cầu. Độ trễ cố định cũng chỉ là phỏng đoán trừ khi trạng thái dự định được kiểm tra lại sau đó.

Giả sử một trang giày ban đầu hiển thị mức giá thấp nhất trong tất cả các size. Sau khi chọn size, giá thay đổi. Ghi lại giá trị đầu tiên và gán nhãn đó là giá của size đã chọn tạo ra lỗi ngữ nghĩa ngay cả khi bộ chọn trả về văn bản hợp lệ. Hãy ghi nhận trạng thái tương tác, rồi đọc giá trị thuộc về trạng thái đó.

Để các lần chạy có thể lặp lại, hãy ghi lại URL bắt đầu, mọi lựa chọn bắt buộc, quy tắc sẵn sàng và các trường xác nhận đúng bản ghi. Những bước này là một phần của hợp đồng trích xuất. Chúng cần được giữ rõ ràng ngay cả khi điều hướng trình duyệt được quản lý bởi một dịch vụ.

Khung, Cây bóng (Shadow Trees) và Nội dung bị thiếu

Không phải mọi phần nội dung đều thuộc về cây tài liệu cấp cao nhất. Một iframe có tài liệu riêng của nó. Một web component có thể đặt phần tử trong một cây bóng. Nội dung được vẽ trên canvas có thể không có các nút văn bản thông thường tương ứng với những từ mà người dùng nhìn thấy. Những khác biệt này giải thích tại sao một giá trị hiển nhiên về mặt trực quan có thể vắng mặt khỏi một bộ chọn đơn giản trên toàn tài liệu.

Khi một bộ chọn không trả về gì, trước hết hãy kiểm tra ngữ cảnh tài liệu. Giá trị đó có nằm trong một frame không? Component có để lộ shadow root có thể truy cập không? Ứng dụng đã thực sự tải phần liên quan chưa? Đừng kết luận rằng nguồn không có dữ liệu cho đến khi phương pháp quan sát đã được kiểm tra.

Các ranh giới truy cập vẫn được áp dụng. Một công cụ tự động hóa trình duyệt không cấp quyền đọc thông tin riêng tư hoặc gỡ bỏ các hạn chế trên một tài liệu. Hãy giữ quy trình làm việc trong phạm vi các trang và tương tác mà bạn được phép sử dụng. Nếu giao diện hiện có không cung cấp thông tin cần thiết, hãy ghi nhận giới hạn đó thay vì bịa ra một giá trị.

Thường hữu ích khi phân loại các trường thiếu là tùy chọn, chưa được tải, nằm ngoài ngữ cảnh tài liệu hiện tại, hoặc lỗi trích xuất. Các nhãn này cho người dùng ở bước sau biết nên chấp nhận một bản ghi không đầy đủ hay điều tra quy trình thu thập. Một chuỗi rỗng duy nhất không thể truyền đạt tất cả những ý nghĩa đó.

Hướng dẫn thực tế về việc kiểm tra DOM

Một lần kiểm tra DOM hữu ích bắt đầu với một trang đã biết và một bản ghi đã biết. Mở trang, xác định bản ghi hiển thị và kiểm tra vùng chứa của nó. So sánh văn bản bạn nhìn thấy với các nút và thuộc tính thực tế. Xác nhận rằng cùng một lựa chọn xác định đúng thẻ (card) mong muốn khi một thẻ bên cạnh có bố cục khác.

Tiếp theo, kiểm tra phản hồi ban đầu của trang. Nếu bản ghi đã có sẵn ở đó, trình duyệt có thể không cần thiết cho lần trích xuất cụ thể đó. Nếu nội dung chỉ xuất hiện sau khi script chạy hoặc sau một tương tác được cho phép, thì một trình duyệt được điều khiển là lớp phù hợp. Quyết định phụ thuộc vào hành vi của trang chứ không phải độ phức tạp của công cụ.

Với một danh mục giả định, hãy kiểm tra một sản phẩm bình thường, một sản phẩm đang giảm giá và một sản phẩm không còn bán. Kiểm tra xem giá bị thiếu có tạo ra trạng thái “không khả dụng” rõ ràng không. Xác minh rằng huy hiệu giảm giá không bị nhầm với giá bán thực tế và một băng chuyền gợi ý không bị gộp vào danh sách sản phẩm chính.

Cuối cùng, giữ một mẫu đánh giá nhỏ chứa URL nguồn, thời điểm thu thập, định danh bản ghi, biến thể đã chọn, văn bản trường thô và giá trị đã chuẩn hóa. Mẫu này giúp việc xem xét thay đổi bộ chọn về sau trở nên có thể kiểm chứng. Ai đó phải có thể giải thích vì sao mỗi giá trị được trích xuất thuộc về bản ghi của nó mà không cần dựng lại toàn bộ phiên duyệt web.

Agent Browser nằm ở đâu

Scrapeless Agent Browser cung cấp một môi trường trình duyệt được quản lý để tương tác với các trang động. Khả năng của Agent Browser bao phủ việc vận hành trình duyệt; ứng dụng của bạn vẫn là bên quyết định trạng thái tài liệu nào cần kiểm tra và các trường được trích xuất có ý nghĩa gì.

Một trình duyệt được quản lý có thể loại bỏ nhu cầu tự vận hành các máy chủ trình duyệt. Nó không tự động chọn đúng sản phẩm tương ứng, phân biệt trả góp với tổng giá, hay xác lập rằng một bản ghi đã đầy đủ. Hãy giữ những kiểm tra đó trong các giai đoạn trích xuất và kiểm định, nơi các quy tắc nghiệp vụ hiển thị rõ ràng.

Sự tách biệt tương tự xuất hiện trong một price-drop monitoring workflow: việc render cung cấp khả năng truy cập tài liệu đang thay đổi, trong khi việc so sánh phụ thuộc vào định danh sản phẩm nhất quán và cách diễn giải giá. Xem lại Scrapeless pricing khi ước tính việc sử dụng trình duyệt, và đánh giá lượng dữ liệu hợp lệ được thu thập thay vì chỉ dựa vào việc điều hướng thành công.

Kết luận

Hiểu DOM giúp việc chẩn đoán trích xuất bằng trình duyệt dễ dàng hơn. Hãy chọn đúng ngữ cảnh tài liệu, chờ trạng thái liên quan, và đọc từng trường trong phạm vi bản ghi của nó. Bước hữu ích tiếp theo là kiểm tra một trang đại diện và ghi chép chính xác những gì phải đúng trước khi dữ liệu của trang đó có thể được chấp nhận.