XPath cho web scraping với class text và sibling

XPath cho web scraping giúp anh em chọn đúng phần tử, đọc thuộc tính và giữ quan hệ giữa các trường trong HTML. Giá trị của biểu thức nằm ở kết quả được kiểm tra, không chỉ ở cú pháp chạy được. ProxyVN hướng dẫn dùng một fixture có class dễ nhầm, chữ lồng và nhãn giá, kèm hai mươi phép thử cục bộ để đối chiếu.

XPath cho web scraping và cách đặt mục tiêu truy vấn

Một biểu thức cần bắt đầu từ điều anh em muốn thu thập: card sản phẩm, liên kết, nội dung hay giá trị kiểm tra. Nếu chưa rõ đầu ra, rất dễ tạo một truy vấn dài nhưng chọn nhầm phạm vi. Trong bài này, mục tiêu là lấy hai sản phẩm chính mà không kéo theo quảng cáo hoặc phần gợi ý bên cạnh.

Phạm vi của hướng dẫn

Bài dùng Python và lxml để chạy truy vấn trên HTML đã có. Không có yêu cầu tải website thật hay endpoint proxy thương mại trong bộ thử. Nhờ vậy, kết quả có thể được tái hiện bằng cùng một tệp, đồng thời giúp anh em tập trung sửa biểu thức thay vì bị nhiễu bởi tình trạng kết nối.

Ngôn ngữ được sử dụng là XPath 1.0 theo khả năng của lxml trong môi trường kiểm tra. Đặc tả XPath 1.0 của W3C là cơ sở đối chiếu các kiểu giá trị và đường dẫn. Những biểu thức chỉ có trong phiên bản XPath khác không được mặc định là chạy trong ví dụ này.

Đặt điều kiện chấp nhận đầu ra

Hai bản ghi cần giữ mã P01 và P02 theo thứ tự tài liệu. Mỗi card có một liên kết tiêu đề và cặp nhãn giá nằm trong danh sách mô tả. Card quảng cáo dùng class product-card được đặt cố ý để kiểm tra sự khác nhau giữa tìm chuỗi con và tìm một token class đúng nghĩa.

Bên ngoài catalog còn có một article mang class product. Nó là dữ liệu gợi ý, không thuộc phạm vi danh mục chính. Nếu biểu thức lấy đủ ba phần tử có token product trên toàn trang, cú pháp vẫn hợp lệ nhưng kết quả sai mục tiêu đã đặt. Vì vậy, kiểm tra phạm vi cần đi trước việc tối ưu biểu thức.

Một XPath ngắn có kết quả được xác nhận hữu ích hơn một đường dẫn dài chỉ trùng với cấu trúc tình cờ của một lần xem trang.

XPath cho web scraping với fixture có trường hợp đối chứng

Fixture không nên chỉ có dữ liệu làm biểu thức đúng. Những phần tử gần giống nhưng không thuộc kết quả giúp phát hiện truy vấn quá rộng. Bài này dùng HTML nhỏ để anh em nhìn thấy cả phần tử cần lấy lẫn phần tử phải loại, thay vì suy luận từ một trang dài khó kiểm tra.

Chuẩn bị thư viện và tệp mẫu

Bộ thử chạy trên Python 3.12.14, lxml 6.1.1 và libxml2 2.11.9. Đây là bản ghi môi trường đã thử, không phải khẳng định mọi phiên bản khác có cùng hành vi. Cài lxml trong môi trường riêng rồi lưu HTML dưới đây thành xpath-fixture.html với mã hóa UTF-8.

python -m pip install lxml==6.1.1

<!doctype html><html><head><meta charset="utf-8"></head><body>
<section id="catalog">
<article class="product featured" data-id="P01">
<h2><a href="/one">Bút <b>chì</b></a></h2>
<dl><dt>Mã</dt><dd>P01</dd><dt>Giá</dt><dd>12.50</dd></dl>
</article>
<article class="featured product" data-id="P02">
<h2><a href="/two">Sổ giấy</a></h2>
<dl><dt>Mã</dt><dd>P02</dd><dt>Giá</dt><dd>0</dd></dl>
</article>
<article class="product-card" data-id="AD01"><h2>Quảng cáo</h2></article>
</section>
<aside><article class="product" data-id="SIDE01"><h2>Gợi ý khác</h2></article></aside>
</body></html>

Đọc fixture bằng bytes để thông tin mã hóa trong tài liệu vẫn đi vào parser. Khi thay tệp, hãy giữ một bản cũ cho bộ kiểm tra hồi quy nếu ứng dụng vẫn phải xử lý cấu trúc ấy. Không sửa dữ liệu mẫu âm thầm để một biểu thức mới có vẻ đúng mà không giải thích thay đổi mục tiêu.

Tạo cây và nhìn kết quả đầu tiên

Lưu các đoạn Python tiếp theo trong cùng một tệp chạy ở thư mục fixture. Cây HTML được tạo một lần rồi dùng lại cho các truy vấn. Cách này tránh tải lại dữ liệu khi chỉ thay biểu thức và giúp phép thử có cùng đầu vào từ đầu đến cuối.

from pathlib import Path
from lxml import html
 
content = Path('xpath-fixture.html').read_bytes()
tree = html.fromstring(content)
print(tree.xpath('//section/@id'))

Kết quả đầu tiên phải là danh sách chứa catalog. Nếu không thấy, kiểm tra tệp đang đọc và cấu trúc cây trước khi chép thêm các biểu thức bên dưới. Một lỗi chọn nhầm tệp có thể khiến nhiều truy vấn cùng trả rỗng, dù cách viết của chúng không phải nguyên nhân.

Fixture có phần tử đối chứng

XPath cho web scraping và lựa chọn class đúng token

Thuộc tính class là một danh sách token trong HTML, nên phép so sánh toàn chuỗi hoặc tìm chuỗi con có thể không phản ánh mục tiêu. Fixture đặt hai card cùng có product nhưng khác thứ tự class. Nó còn có product-card để chứng minh chuỗi product xuất hiện chưa đủ xác nhận token cần tìm.

So ba cách chọn thường gặp

Điều kiện @class='product' chỉ chọn phần tử có giá trị class đúng như chuỗi đã viết. Trong fixture, phần tử gợi ý ở aside đáp ứng điều kiện, nhưng hai sản phẩm chính có thêm featured nên không được chọn. Đây là ví dụ một điều kiện tưởng chừng chặt chẽ lại bỏ sót chính dữ liệu cần lấy.

Điều kiện contains(@class,'product') lấy cả product-card vì nó tìm chuỗi con. Tài liệu contains của MDN giúp đối chiếu ý nghĩa hàm này. Khi dùng cho class, cần bổ sung ranh giới token nếu mục tiêu là một tên class riêng trong danh sách.

token = "contains(concat(' ', normalize-space(@class), ' '), ' product ')"
cards = tree.xpath("//section[@id='catalog']/article[" + token + "]")
assert [card.get('data-id') for card in cards] == ['P01', 'P02']

Khoảng trắng được thêm ở hai phía giúp phân biệt product với product-card trong fixture. Phần normalize-space làm điều kiện ít phụ thuộc vào khoảng trắng thường xuất hiện giữa các token. Trong môi trường HTML có những ký tự trắng đặc biệt, cần thêm mẫu thử tương ứng; đừng suy ra một biểu thức đã bao phủ mọi cách mã hóa đầu vào.

Kết hợp class với phạm vi có ý nghĩa

Biểu thức chọn section có id catalog trước rồi chỉ lấy các article con của section ấy. Điều kiện class đúng token nhưng thiếu phạm vi vẫn lấy thêm SIDE01. Vì thế, một ca thử hữu ích cần đồng thời kiểm tra mã bản ghi và số lượng, không chỉ kiểm tra rằng kết quả không rỗng.

Nếu nguồn thật không có id ổn định như fixture, hãy tìm một vùng có ý nghĩa trong cấu trúc nội dung. Tránh bám vào chuỗi lớp giao diện được sinh ngẫu nhiên nếu có dấu hiệu khác phù hợp hơn. Mỗi lựa chọn vẫn cần được thử trên các mẫu đại diện, vì không có thuộc tính nào tự mang lời hứa ổn định cho mọi website.

Đọc thuộc tính mà không làm mất quan hệ

Sau khi có cards, chạy truy vấn liên kết trong từng card thay vì lấy toàn bộ href trên trang rồi ghép theo vị trí. Mỗi bản ghi sẽ giữ được trường xuất phát từ cùng một vùng HTML. Nếu một card thiếu liên kết, chương trình có thể phát hiện tại chính card đó thay vì làm lệch cả danh sách phía sau.

Đừng dùng zip giữa hai danh sách toàn cục nếu chưa xác nhận tính tương ứng. Một card quảng cáo có tiêu đề nhưng không có liên kết có thể khiến độ dài hai danh sách khác nhau. Việc cắt tới danh sách ngắn hơn chỉ che lỗi ghép trường, không khôi phục được quan hệ dữ liệu ban đầu.

XPath cho web scraping và văn bản có thẻ lồng

Tiêu đề Bút chì trong fixture được chia giữa văn bản trực tiếp của a và thẻ b bên trong. Một biểu thức lấy text() trực tiếp không nhất thiết trả đủ chuỗi người đọc nhìn thấy. Hãy xác định cần lấy các nút văn bản hay cần giá trị chuỗi của phần tử trước khi dùng kết quả làm trường tiêu đề.

So text() với giá trị chuỗi

Truy vấn .//h2/a/text() trên card đầu trả phần Bút cùng khoảng trắng, không gộp nội dung của b theo cách tiêu đề mong muốn. Trong khi đó, normalize-space(.//h2/a) đọc giá trị chuỗi rồi chuẩn hóa khoảng trắng. Hai biểu thức đáp ứng hai nhiệm vụ khác nhau, không nên được thay thế cho nhau chỉ vì chúng đều có chữ text liên quan.

first = cards[0]
assert first.xpath('.//h2/a/text()') == ['Bút ']
assert first.xpath('normalize-space(.//h2/a)') == 'Bút chì'

Tham chiếu normalize-space của MDN giúp xác định ý nghĩa chuẩn hóa khoảng trắng của hàm. Với dữ liệu cần giữ xuống dòng hay bố cục nguyên bản, anh em nên lưu thêm trường thô. Không dùng một bước chuẩn hóa cho mọi loại văn bản nếu mục tiêu sử dụng khác nhau.

Tách chọn phần tử khỏi chuẩn hóa

Khi một biểu thức có thể chọn nhiều tiêu đề, đừng gọi string rồi xem một chuỗi nhận được là đã giải quyết mơ hồ. Trước tiên lấy danh sách phần tử, kiểm tra số lượng theo schema, rồi đọc nội dung của phần tử đã được chấp nhận. Cách này giúp lỗi có thêm giá hoặc tiêu đề không bị âm thầm thu về phần tử đầu.

Một thẻ được tìm thấy nhưng có nội dung rỗng cũng cần được phân biệt với không tìm thấy thẻ. Trong quy trình thu thập, hai tình huống có thể mang ý nghĩa khác nhau. Hãy quyết định có được chấp nhận rỗng hay phải cách ly bản ghi trước khi đưa chuỗi vào tệp xuất.

Văn bản lồng và phạm vi card

XPath cho web scraping với truy vấn tương đối và sibling

Phạm vi đánh giá là một phần của biểu thức. Khi đã có card, dấu chấm ở đầu truy vấn giúp giữ việc tìm dưới card đang xét. Nếu dùng đường dẫn bắt đầu từ gốc, vòng lặp có thể đọc lại cùng các phần tử trên toàn tài liệu dù biến Python hiện tại đang trỏ tới một card riêng.

Giữ truy vấn trong card

Hai assertion sau trả href khác nhau từ hai sản phẩm. Bộ thử còn xác nhận truy vấn //h2/a/@href chạy trên card đầu vẫn thấy các liên kết từ toàn cây. Đây là lỗi dễ bị bỏ sót khi fixture chỉ có một card, vì kết quả toàn cục khi ấy có thể trùng với kết quả cần lấy.

assert cards[0].xpath('.//h2/a/@href') == ['/one']
assert cards[1].xpath('.//h2/a/@href') == ['/two']
assert len(cards[0].xpath('//h2/a/@href')) == 2

Với nguồn có nhiều nhóm sản phẩm, hãy thử thêm nhóm không thuộc kết quả như aside trong fixture. Nếu số dòng tăng khi thêm khối gợi ý, biểu thức đang phụ thuộc phạm vi rộng hơn mục tiêu. Sửa phạm vi trước khi thêm các bước lọc bằng tên hoặc giá, vì lọc hậu kỳ không luôn khôi phục được quan hệ đã đọc nhầm.

Lấy giá theo nhãn cùng cấp

Khi nhãn Giá nằm trong dt và giá nằm ở dd kế tiếp, following-sibling giúp diễn đạt quan hệ này. Tài liệu trục XPath của MDN cung cấp ý nghĩa các hướng đi giữa các nút. Trong fixture, lựa chọn theo nhãn dễ hiểu hơn việc lấy dd thứ hai chỉ vì thứ tự hiện tại.

price = cards[0].xpath(
    ".//dt[normalize-space(.)='Giá']/following-sibling::dd[1]/text()"
)
assert price == ['12.50']

Biểu thức vẫn cần kiểm tra số lượng kết quả khi nguồn có thể lặp nhãn Giá trong cùng một card. Hai khối biến thể có cùng nhãn không nên được gộp ngẫu nhiên thành một giá. Khi schema chưa nói giá nào cần dùng, báo mơ hồ để người viết xác định quy tắc thay vì chọn đại kết quả đầu.

Hiểu vị trí trên trục ngược

preceding-sibling::dt[1] chọn dt gần nhất theo trục ngược khi đứng tại một nút dd phù hợp. Nếu bọc tập kết quả trong ngoặc rồi đặt [1], ý nghĩa vị trí có thể thay đổi theo thứ tự tài liệu. Fixture dùng hai nhãn Mã và Giá để anh em thấy sự khác nhau bằng kết quả cụ thể.

nearest = cards[0].xpath('.//dd[last()]/preceding-sibling::dt[1]/text()')
first_in_doc = cards[0].xpath('(.//dd[last()]/preceding-sibling::dt)[1]/text()')
assert nearest == ['Giá']
assert first_in_doc == ['Mã']

Không sao chép dấu ngoặc từ một biểu thức khác chỉ để cú pháp hết lỗi. Hãy viết lại mục tiêu bằng lời, chẳng hạn nhãn đứng gần nhất trước giá trị cuối, rồi kiểm tra biểu thức trên fixture có nhiều nút ứng viên. Kết quả đúng phải đến từ quan hệ được hiểu, không từ một cấu trúc chỉ tình cờ có một nút.

XPath cho web scraping và kiểu kết quả cần kiểm tra

Kết quả XPath không phải lúc nào cũng là danh sách phần tử. Một biểu thức có thể trả chuỗi, số hoặc giá trị boolean. Nếu mã gọi luôn lấy phần tử đầu mà không xét kiểu, chương trình có thể xử lý sai một kết quả hợp lệ hoặc báo lỗi khó hiểu khi đổi biểu thức.

Phân biệt tập nút với giá trị đơn

Trong fixture, count(.//dt) trả số 2.0, boolean(.//h2/a) trả True và string(.//missing) trả chuỗi rỗng. Truy vấn .//missing lại trả danh sách rỗng. Những khác biệt này cần được phản ánh trong assertion thay vì dùng cùng một điều kiện kiểm tra có dữ liệu cho mọi biểu thức.

assert cards[0].xpath('count(.//dt)') == 2.0
assert cards[0].xpath('boolean(.//h2/a)') is True
assert cards[0].xpath('string(.//missing)') == ''
assert cards[0].xpath('.//missing') == []

Với trường bắt buộc, string trả rỗng có thể che việc phần tử không tồn tại và việc phần tử tồn tại nhưng rỗng. Nếu cần phân biệt, hãy kiểm tra tập phần tử trước. Với trường tùy chọn, ghi rõ chính sách xuất null hoặc chuỗi rỗng để nơi nhận dữ liệu không phải đoán ý nghĩa của giá trị.

Truyền biến cho giá trị có dấu nháy

Một tên như D'Angelo có thể làm biểu thức nối chuỗi thủ công bị sai dấu nháy. Tài liệu XPath của lxml mô tả việc truyền biến khi đánh giá truy vấn. Ví dụ dưới giữ giá trị tìm kiếm ở tham số, không trộn nó vào phần cú pháp XPath.

sample = html.fromstring("<div><p>D'Angelo</p><p>Other</p></div>")
matched = sample.xpath('//p[normalize-space(.)=$needle]', needle="D'Angelo")
assert len(matched) == 1

Tham số biến dùng cho giá trị, không phải cơ chế cho phép người dùng tùy ý thay toàn bộ biểu thức. Nếu ứng dụng nhận lựa chọn trường từ bên ngoài, hãy ánh xạ lựa chọn vào một danh sách biểu thức do chương trình quản lý. Cách này giữ giao diện rõ ràng và giảm lỗi do ghép các mảnh truy vấn không được kiểm tra.

Phân biệt lỗi cú pháp và kết quả rỗng

Một biểu thức sai cú pháp cần được báo như lỗi cấu hình truy vấn, không phải một trang hợp lệ có không dữ liệu. Khi tổ chức nhiều nguồn, hãy kiểm tra các biểu thức lúc nạp cấu hình và gắn mã nguồn với thông báo lỗi. Không bắt mọi exception rồi trả danh sách rỗng, vì cách đó làm mất khác biệt giữa không tìm thấy phần tử và chưa thực hiện được truy vấn.

Nếu biểu thức hợp lệ nhưng kết quả rỗng, hãy kiểm tra từng đoạn từ vùng cha tới phần tử con trên fixture. Chẳng hạn xác nhận catalog tồn tại trước, sau đó xác nhận số article, cuối cùng mới áp điều kiện class. Việc chia bước giúp biết chính xác điều kiện nào loại toàn bộ ứng viên thay vì sửa ngẫu nhiên một truy vấn dài.

Trong nhật ký, ghi tên truy vấn và phiên bản cấu hình thay vì chép toàn bộ tài liệu nguồn. Người kiểm tra cần đủ thông tin tái hiện biểu thức nhưng không cần một bản sao dữ liệu nhạy cảm của trang. Nếu phải lưu mẫu, hãy giới hạn thời gian lưu và chỉ giữ cấu trúc cần thiết để tái hiện lỗi.

Không dùng vị trí để che điều kiện thiếu

Một hậu tố [1] có thể làm kết quả hết mơ hồ về mặt số lượng nhưng không chứng minh phần tử đầu là dữ liệu đúng. Trong ví dụ nhãn Giá, [1] diễn đạt phần tử cùng cấp gần nhất theo quan hệ đã hiểu. Ở một danh sách nhiều biến thể, lấy kết quả đầu chỉ vì thuận tiện có thể bỏ qua sản phẩm hoặc mức giá khác mà người dùng cần.

Hãy viết điều kiện chọn theo ý nghĩa trước khi dùng vị trí. Nếu nghiệp vụ thực sự cần sản phẩm đứng đầu danh mục, vị trí là một phần hợp đồng và nên được kiểm tra khi đảo thứ tự fixture. Nếu nghiệp vụ cần SKU cụ thể, hãy chọn theo SKU rồi xác nhận chỉ có một bản ghi đáp ứng thay vì dựa vào thứ tự hiển thị.

Những trường hợp này nên được ghi trong cấu hình nguồn để người sửa về sau không hiểu [1] như một mẹo làm sạch dữ liệu. Một bình luận ngắn giải thích quan hệ nhãn và giá hoặc lý do chọn bản ghi đầu sẽ giúp duy trì ý nghĩa truy vấn khi HTML được thay đổi. Giữ ý nghĩa rõ ràng quan trọng hơn rút ngắn vài ký tự.

Siblings theo quan hệ dữ liệu

XPath cho web scraping với namespace và biểu thức dùng lại

Một hướng dẫn HTML vẫn cần phân biệt trường hợp dữ liệu thực tế là XML. Thẻ trong tài liệu XML có namespace không được hiểu giống một thẻ HTML không namespace. Nếu biểu thức nhìn đúng tên nhưng trả rỗng, kiểm tra loại tài liệu và tên mở rộng của nút trước khi viết selector rộng hơn.

Khai báo namespace khi đọc XML

Ví dụ nhỏ sau cố ý đặt namespace mặc định urn:fixture. Truy vấn //item không tìm thấy nút vì nó không chỉ tới cùng tên mở rộng. Ánh xạ f trong lời gọi XPath là tiền tố do chương trình chọn để diễn đạt namespace, không cần trùng cách tài liệu ghi tiền tố.

from lxml import etree
xml = etree.fromstring(b'<root xmlns="urn:fixture"><item code="X"/></root>')
assert xml.xpath('//item') == []
assert xml.xpath('//f:item/@code', namespaces={'f': 'urn:fixture'}) == ['X']

Không dùng local-name cho mọi truy vấn chỉ để bỏ qua namespace. Hai nhóm dữ liệu có thể có cùng tên cục bộ nhưng ý nghĩa khác khi thuộc namespace khác. Nếu schema đã xác định namespace, hãy thể hiện nó trong truy vấn và thêm fixture chứng minh đang chọn đúng nhóm thông tin.

Dùng lại biểu thức có cùng hợp đồng

Với nhiều card dùng cùng cách lấy href, có thể tạo etree.XPath một lần rồi gọi trên từng card. Bộ thử xác nhận biểu thức dùng lại trả /one và /two theo đúng thứ tự. Bài không đưa ra benchmark tốc độ; lợi ích được minh họa ở đây là giữ một định nghĩa truy vấn nhất quán trong mã.

Nếu cần đo hiệu năng, hãy dùng tài liệu và quy mô đại diện cho công việc thực tế. Đừng lấy thời gian chạy trên fixture vài dòng để cam kết mức cải thiện cho hệ thống lớn. Kích thước cây, số biểu thức và các bước tải hay ghi dữ liệu đều có thể ảnh hưởng thời gian toàn tác vụ.

XPath cho web scraping và bộ kiểm thử hai mươi điều kiện

Bộ thử đi kèm đã chạy trên fixture HTML cùng một tài liệu XML nhỏ. Nó kiểm tra cả biểu thức đúng lẫn những cách viết dễ tạo kết quả sai nhưng vẫn hợp lệ cú pháp. Điều quan trọng là nhìn thấy khác biệt bằng mã bản ghi, chuỗi tiêu đề và giá trị cụ thể thay vì chỉ báo truy vấn có chạy.

Những nhóm đã được xác nhận

Hai mươi điều kiện bao gồm class token, class chứa chuỗi con, so class bằng toàn chuỗi, chữ lồng, text trực tiếp, hai href tương đối và truy vấn thoát phạm vi card. Những ca này được thiết kế quanh cấu trúc fixture của bài, nên người đọc có thể thay một phần tử rồi quan sát assertion nào không còn đạt.

Các điều kiện còn lại kiểm tra nhãn sibling, trục ngược có và không có ngoặc, kiểu count, boolean, chuỗi rỗng và tập nút rỗng. Bộ thử còn có giá trị chứa dấu nháy, biểu thức biên dịch dùng lại, XML có namespace, XML thiếu ánh xạ và vị trí của cả tập chọn. Không có kết nối website hoặc browser trong các phép thử này.

Thêm ca thử khi sửa selector

Khi một nguồn đổi HTML, hãy lưu mẫu mới được phép sử dụng rồi bổ sung assertion gắn với lỗi vừa gặp. Giữ các trường hợp đối chứng như quảng cáo và phần gợi ý để biểu thức không mở rộng quá mức. Một lần sửa chỉ đạt khi vừa lấy được dữ liệu mới vừa không kéo thêm phần tử ngoài mục tiêu.

Không thay assertion thành chấp nhận bất kỳ kết quả nào để làm báo cáo thử xanh. Nếu số bản ghi được phép thay đổi, hãy xác định điều kiện thay thế có ý nghĩa, chẳng hạn mỗi dòng phải có mã duy nhất và liên kết thuộc đúng card. Bộ thử cần ghi lại hợp đồng mới, không chỉ bỏ điều kiện cũ.

XPath cho web scraping khi kết nối vào pipeline thu thập

XPath hoạt động trên tài liệu đã nhận, nên chất lượng tuyến tải và chất lượng truy vấn là hai phần cần quan sát riêng. Nếu nguồn chỉ gửi khung JavaScript, không có biểu thức nào tạo ra dữ liệu chưa nằm trong cây đang đọc. Hãy kiểm tra HTML nguồn hoặc DOM được phép thu thập trước khi thay hàng loạt XPath.

Tách chẩn đoán mạng và nội dung

Anh em có thể đọc thêm về cơ chế web scraping proxy khi tổ chức tầng tải. Trong công việc thực tế, ghi status, loại nội dung và phiên bản parser cùng kết quả dữ liệu. Một lỗi xác thực proxy khác với một card thiếu nhãn Giá, nên không nên cùng bị gộp thành không lấy được dữ liệu.

Trước khi mua proxy, anh em hãy xác định HTTP client hoặc browser nào sẽ tải tài liệu và cách kiểm tra tuyến của nó. Endpoint phù hợp không sửa được truy vấn đang chọn toàn trang thay vì card. Hãy nghiệm thu mạng bằng mục tiêu được phép và nghiệm thu XPath bằng fixture để mỗi kết luận có bằng chứng riêng.

Chuẩn bị bàn giao dễ tái hiện

Gói bàn giao cần có fixture, các biểu thức, schema đầu ra, phụ thuộc và báo cáo hai mươi kiểm tra đã chạy. Nếu có mẫu nguồn thật, phải lưu theo quyền dữ liệu và loại thông tin không cần thiết. Không đưa mật khẩu hay cookie vào tệp thử chỉ vì chúng từng xuất hiện trong một lần chẩn đoán.

Người nhận cần biết giới hạn của ví dụ: chưa thử browser, website thật hay endpoint thương mại. Khi tích hợp, họ phải kiểm tra dữ liệu đại diện và điều kiện công bố lô trước khi chạy định kỳ. Những bước này giúp lỗi truy vấn được phát hiện ở thời điểm sửa, thay vì xuất hiện trong báo cáo sử dụng dữ liệu.

Hai mươi điều kiện kiểm tra

XPath cho web scraping hiệu quả khi biểu thức bám đúng phạm vi và có kiểm thử theo từng trường. Anh em hãy bắt đầu từ fixture, xác nhận class, văn bản cùng quan hệ sibling rồi mới tích hợp vào pipeline. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để trao đổi cách triển khai XPath cho web scraping.