Lấy dữ liệu từ các trang web có JavaScript nặng mà không bị chặn
TL;DR
Một trang web nặng về JavaScript có thể trả về một shell HTML trước, sau đó tải dữ liệu thông qua một API đã được tài liệu hóa, trạng thái trang nhúng hoặc các yêu cầu từ trình duyệt. Kiểm tra nơi nội dung cần thiết thực sự xuất hiện.
Sử dụng API đã được phê duyệt của nguồn khi có sẵn; nếu không, hãy phân tích dữ liệu được máy chủ tạo ra hoặc nhúng cho phép trước khi phải trả tiền cho việc render đầy đủ trên trình duyệt.
Đối với nội dung chỉ trên trình duyệt, hãy chờ một phần tử có ý nghĩa và xác thực nó. load và networkidle không phải là tín hiệu hoàn thành phổ quát.
"Không bị chặn" phụ thuộc vào việc ủy quyền, tốc độ theo nguồn cụ thể, và các điều kiện dừng; việc render hoặc proxy không đảm bảo truy cập vào một trang web bị hạn chế.
Nstdata Crawl có thể render JavaScript, phát hiện các trang liên kết, và trả về Markdown sẵn sàng cho LLM cùng với các hiện vật khác với định tuyến proxy tích hợp.
Tại Sao Các Trang Web Nặng Về JavaScript Trả Về HTML Rỗng Cho Các Công Cụ Thu Thập Dữ Liệu?
Nhiều trang web hiện đại gửi một tài liệu nhỏ tải các script và lấy nội dung hữu ích sau khi điều hướng. Một client HTTP trực tiếp chỉ thấy phản hồi ban đầu và không thể thực thi ứng dụng trang. Các trang web khác nhúng một đối tượng trạng thái JSON trong HTML, render nội dung trên máy chủ, hoặc mở một API đã được tài liệu hóa. Phương pháp thu thập dữ liệu đúng phụ thuộc vào cơ chế nào mà nguồn được phê duyệt sử dụng.
Nstdata Crawl cung cấp dịch vụ render được quản lý cho các trang được phép khi nội dung thực sự yêu cầu trình duyệt.
Mở trang trong công cụ phát triển và so sánh Mạng → Tài liệu, Mạng → Fetch/XHR, và chế độ xem Phần tử đã được render. [Ảnh chụp màn hình: Phản hồi HTML ban đầu bên cạnh sản phẩm hoặc phần tử bài viết đã được render.] Hướng dẫn điều hướng Playwright lưu ý rằng các trang hiện đại có thể tiếp tục tải dữ liệu sau sự kiện . Một giấc ngủ cố định là một sự thay thế kém cho việc kiểm tra dấu hiệu nội dung thực tế.
Chuẩn bị một URL đã được phê duyệt, các trường dữ liệu dự định, một dấu hiệu trang mong đợi, một quy tắc xác định danh tính tài liệu, các điều khoản truy cập nguồn, và một ngân sách yêu cầu theo máy chủ. Quyết định tần suất mà bản ghi phải được làm mới. Giữ một trang tốt đã biết và một trường hợp thất bại để xác thực. Nếu sử dụng Playwright, hãy cài đặt thư viện và trình duyệt của nó. Nếu sử dụng Nstdata Crawl, nhận một khóa API từ Bảng điều khiển → Khu vui chơi Crawler. Không cần các trường Proxy Host, Port, Tên người dùng, Mật khẩu, hoặc Giao thức riêng biệt cho một công việc Crawler được quản lý tiêu chuẩn.
Sử dụng phân loại trang cụ thể cho nguồn. static_html, documented_api, embedded_state, browser_rendered, access_denied, và unknown hữu ích hơn một boolean gọi là scrape_success. Danh mục xác định cả con đường thu thập rẻ nhất và phương pháp xử lý thất bại.
Làm Thế Nào Để Bạn Chọn Phương Pháp Thu Thập Hợp Lý Nhất?
Phương Pháp 1: Sử Dụng API Nguồn Đã Được Tài Liệu
Bước 1. Kiểm tra tài liệu phát triển của trang web hoặc thỏa thuận đối tác cho các bản ghi cần thiết. Xác nhận rằng API và cách sử dụng dự định của bạn được phép.
Bước 2. Yêu cầu một bản ghi, xác thực ID và các trường của nó, và kiểm tra phân trang, hạn ngạch, và ngữ nghĩa cập nhật. Giữ thông tin đăng nhập API ở phía máy chủ.
Bước 3. Lưu ID nguồn, phiên bản API, thời gian quan sát, và một đường dẫn sửa chữa. Nếu API là chính xác cho dữ liệu cần thiết, việc thu thập trên trình duyệt có thể thêm chi phí mà không cải thiện độ chính xác.
Giới hạn: Một điểm cuối riêng tư được quan sát trong công cụ phát triển không tự động là một API công khai được hỗ trợ. Xem lại các điều khoản và truy cập trước khi sử dụng nó trực tiếp.
Phương Pháp 2: Phân Tích HTML Ban Đầu Hoặc Trạng Thái Nhúng
Bước 1. Lưu phản hồi tài liệu ban đầu và tìm kiếm các giá trị cần thiết hoặc một payload trạng thái nhúng được tài liệu hóa.
Bước 2. Phân tích trang với một trình phân tích phiên bản, chỉ định phạm vi các trường đến bài viết hoặc sản phẩm đúng, và xác nhận với trang nhìn thấy. Xử lý mã hóa, ngôn ngữ địa phương, và các biến thể thiếu.
Bước 3. Nếu dữ liệu thiếu hoặc lỗi thời, chuyển sang việc render thay vì thêm nhiều bộ chọn vào shell rỗng.
Giới hạn: Trạng thái nhúng có thể thay đổi hình dạng mà không thông báo. Giữ thử nghiệm fixture và từ chối các bản ghi không còn phù hợp với schema.
Phương Pháp 3: Render Với Playwright
Bước 1. Cài đặt Playwright và nhị phân trình duyệt của nó trong một môi trường ảo. Chọn một trang đã được phê duyệt và một dấu hiệu có ý nghĩa.
Bước 2. Điều hướng, chờ dấu hiệu, và chỉ lấy thông tin sau khi trang ở trạng thái mong đợi:
from playwright.sync_api import sync_playwright
with sync_playwright()as playwright:browser = playwright.chromium.launch(headless=True)try: page = browser.new_page() response = page.goto("https://example.com/", wait_until="domcontentloaded", timeout=30000)if response isNoneornot response.ok:raise RuntimeError("Chuyển hướng không thành công") heading = page.get_by_role("heading", level=1) heading.wait_for(state="visible", timeout=10000) text = heading.inner_text().strip()ifnot text:raise ValueError("Nội dung dự kiến bị thiếu")print({"url": page.url,"heading": text})finally: browser.close()
Bước 3. Thay thế dấu hiệu ví dụ bằng một dấu hiệu được quan sát trên trang động đã được phê duyệt. Xác thực thực thể và các trường, và lưu ảnh chụp màn hình của các lỗi nếu chính sách lưu giữ cho phép. Hướng dẫn hướng dẫn định vị Playwright giải thích các định vị vai trò và văn bản có thể tồn tại lâu hơn tên lớp được tạo.
Giới hạn: Thực thi trình duyệt sử dụng nhiều bộ nhớ và xử lý hơn HTTP thông thường, và nó không cho phép truy cập vào nội dung bị thách thức hoặc riêng tư.
Làm Thế Nào Để Ngăn Chặn Các Trình Cạo Trang Động Gặp Lỗi Im Lặng?
Tách biệt sự thành công của điều hướng và sự thành công của bản ghi. Kiểm tra trạng thái phản hồi, URL cuối cùng, loại trang dự kiến, văn bản hoặc trường yêu cầu, ngôn ngữ địa phương, và trạng thái hiển thị. Một trang 200 có thể là một bức tường đồng ý hoặc thách thức. Một trang động có thể hiển thị một vòng quay tải mãi mãi. Đặt cho công việc một thời gian chờ hữu hạn và một lý do bị từ chối như empty_render, wrong_template, access_denied, hoặc missing_field.
Đối với các công việc nhiều trang, giữ một hàng đợi URL bền vững, tốc độ cụ thể của nguồn, và các ghi chép không thay đổi. Chỉ quay lại các trang mà mục tiêu độ tươi của nó yêu cầu. Vào 429, giảm tốc độ và tôn trọng hướng dẫn thử lại; vào 401 hoặc 403, ngừng lại để xem xét quyền truy cập. Hướng dẫn kết xuất JavaScript ở quy mô lớn đề cập đến việc cấp phép trình duyệt và sẵn sàng, trong khi hướng dẫn duyệt có trách nhiệm đề cập đến các điều kiện dừng có ý thức nguồn.
Nstdata Có Thể Giúp Chuyển Các Trang Động Thành Dữ Liệu Sẵn Sàng Cho LLM Như Thế Nào?
Nstdata Crawl là một tùy chọn thu thập và chuyển đổi được quản lý cho các trang động đã được phê duyệt. Nó hỗ trợ kết xuất JavaScript, phát hiện trang từ một URL hạt giống, cào đệ quy giới hạn, và đầu ra trang thông qua API Crawl. Điều này có thể giảm công việc của đội tàu trình duyệt và phối hợp proxy cho một đường ống dữ liệu AI. Nó không thay thế quyền truy cập nguồn, ánh xạ trường ứng dụng, hoặc xác thực ngữ nghĩa.
Đầu ra sẵn sàng cho LLM: Markdown cung cấp nội dung sạch hơn cho RAG và các đại lý; HTML và dữ liệu thô giữ cấu trúc cho các bộ phân tích và gỡ lỗi; liên kết hỗ trợ phát hiện; ảnh chụp màn hình và PDF giúp xác nhận trạng thái đã được kết xuất. Tài liệu Crawl liệt kê các loại đầu ra này và việc lấy mã tham chiếu.
Proxy tích hợp sẵn: Các yêu cầu Crawl tiêu chuẩn kế thừa định tuyến proxy của Nstdata mà không cần cấu hình Host, Port, Username, Password, hoặc Protocol trong khách hàng. Điều đó giảm công việc tích hợp, trong khi các quy tắc truy cập và tỷ lệ của nguồn vẫn áp dụng.
Điều khiển trang:maxDepth, maxPages, includeUrls, và excludeUrls xác định một công việc giới hạn. So sánh tập hợp trang kết quả với danh sách dự kiến; một công việc đơn lẻ không phải là bằng chứng rằng mọi trạng thái động đã được truy cập.
Làm Thế Nào Để Thêm Nstdata Crawl Vào Một Đường Ống Trang Động?
Bước 1. Kiểm tra một URL đã được phê duyệt đại diện trong Bảng điều khiển → Khu vui chơi Cào. So sánh HTML ban đầu, kết quả kết xuất, và dấu hiệu trang dự kiến. Đ obtain và lưu khóa API như NSTDATA_API_TOKEN.
Bước 2. Gửi một yêu cầu một trang cho văn bản và chứng cứ. Sử dụng các điều khiển kết xuất hiện tại của Khu vui chơi cho trang cụ thể; thân bài bắt đầu nhanh sau đây chỉ sử dụng các trường đã được xác nhận trong hướng dẫn API công khai:
curl--request POST 'https://api.nstdata.io/api/v1/crawl/scrape/submit-sync'\--header"x-api-key: ${NSTDATA_API_TOKEN}"\--header'Content-Type: application/json'\--data'{"url":"https://example.com/","formats":["markdown","html","screenshot"],"onlyMainContent":true,"timeout":60000}'
Bước 3. Kiểm tra thành công nhiệm vụ lồng ghép và trạng thái trang, sau đó so sánh Markdown hoặc HTML trả về với ký hiệu mong đợi. Lấy các giá trị lớn markdownRef, htmlRef, hoặc screenshotRef thông qua điểm cuối lưu trữ đã được tài liệu hóa. Từ chối một thách thức hoặc một bản render không hoàn chỉnh. Một yêu cầu trực tiếp cần một khóa tài khoản; mã là một ví dụ tích hợp đã được tài liệu hóa.
Sử dụng trình duyệt chỉ khi mẫu chứng minh rằng nó cần thiết, và giữ hợp đồng bản ghi đã chấp nhận giống hệt nhau trên các phương pháp. Hướng dẫn trang động Python cung cấp nhiều tùy chọn trình duyệt cục bộ hơn. Nstdata Cloud Browser là một giải pháp riêng biệt cho việc tiếp tục tương tác tùy chỉnh.
Bạn Xử Lý Hydration, Lazy Loading, và Service Workers Như Thế Nào?
Hydration có thể thay thế mã HTML render từ máy chủ sau khi điều hướng, vì vậy một bộ chọn mà tồn tại ngay lập tức có thể vẫn thay đổi giá trị của nó. Chờ đợi ký hiệu dữ liệu ổn định, sau đó so sánh giá trị của nó trong một khoảng thời gian quan sát ngắn hoặc phản hồi mạng liên quan khi ứng dụng tiết lộ một cái. Các danh sách được lazy-load yêu cầu một vòng lặp cuộn hoặc nhấp giới hạn với các điểm kiểm tra ID mục; việc đến đáy của DOM hiện tại không chứng minh rằng máy chủ không còn kết quả nào nữa.
Service workers và bộ nhớ cache của trình duyệt cũng có thể thay đổi những gì một bài kiểm tra thấy. Nếu một trang vừa được thay đổi có vẻ lỗi thời, hãy kiểm tra nguồn yêu cầu và tiêu đề phản hồi trong công cụ phát triển. So sánh ngữ cảnh trình duyệt sạch với ngữ cảnh đã được sử dụng lại. Đừng vô hiệu hóa các điều khiển bảo mật hoặc hành vi cache một cách mù quáng; quyết định xem sản phẩm có cần chế độ xem cache của người dùng hay một quan sát nguồn hiện tại, và ghi lại phương pháp đã sử dụng.
Đối với một pipeline lặp lại, thêm một fixture cho mỗi mẫu trang động. Kiểm tra ký hiệu mong đợi, danh tính mục, địa phương, và các trường sau khi lấy được. Bảo tồn một tác phẩm thô hoặc đã được render khi chính sách cho phép, để một nhà phát triển có thể phát lại việc trích xuất mà không cần yêu cầu trang lặp lại. Tách biệt các kết quả render_timeout, access_denied, và schema_mismatch. Chúng có chủ sở hữu và sửa chữa khác nhau, mặc dù cả ba có thể xuất hiện như một bản ghi đầu ra trống.
Kiểm tra lại các lựa chọn thu thập định kỳ. Một trang có thể thêm render từ máy chủ, công bố một API được hỗ trợ, hoặc di chuyển nội dung sau một chính sách truy cập mới. Ghi lại phương pháp nào hiện đang cung cấp mỗi nguồn, lý do nó được chọn, và tín hiệu nào kích hoạt xem xét. Điều này tránh việc mang một quy trình trình duyệt tốn kém tiếp tục chỉ vì nó là phương pháp đầu tiên hoạt động.
Tài liệu Tham chiếu Fetch API giải thích các yêu cầu trình duyệt mà bạn có thể quan sát trong bảng điều khiển mạng.
