trích JSON-LD Product bằng Python có nguồn đường dẫn
trích JSON-LD Product bằng Python cần đọc đủ các script, node và Offer thay vì lấy giá đầu tiên tìm thấy. Markup công bố không đồng nghĩa giá thanh toán đang áp dụng. Bài này dùng sản phẩm mẫu có hai đồng tiền, giữ đường dẫn nguồn và phân biệt dữ liệu thiếu với lỗi cú pháp. ProxyVN hướng dẫn cách kiểm trên dữ liệu mẫu.
trích JSON-LD Product bằng Python từ HTML đã tải
JSON-LD thường nằm trong thẻ script của tài liệu HTML. Nó là một nguồn dữ liệu có cấu trúc được trang công bố, nhưng không phải lúc nào cũng đầy đủ hoặc cập nhật cùng giao diện. Parser cần giữ nguồn để người dùng đối chiếu khi thông tin khác nhau.
Tầng HTTP tải HTML theo quyền truy cập, còn parser đọc byte hoặc chuỗi đã được giải mã đúng. Không truyền proxy vào json.loads hoặc xem thay IP là cách sửa một script JSON thiếu dấu ngoặc. Giữ hai bước riêng giúp biết lỗi thuộc tải, giải mã hay cấu trúc dữ liệu.
Trong lab, một Product tên Lab cup có hai Offer tự tạo bằng USD và EUR. Không có giao dịch hoặc giá thị trường nào được suy ra từ các con số. Bộ mẫu chỉ kiểm việc parser giữ đủ hai offer và không trộn currency.
Product là node dữ liệu theo ngữ cảnh
Schema.org Product mô tả một kiểu thực thể cùng các thuộc tính liên quan. Trang có thể công bố nhiều node trong một script hoặc nhiều script khác nhau. Lấy script đầu tiên rồi mặc định nó là sản phẩm sẽ bỏ sót hoặc nhận nhầm dữ liệu tổ chức, breadcrumb và bài viết.
Kiểu có thể được biểu diễn theo dạng mà parser hỗ trợ, chẳng hạn chuỗi hoặc danh sách. Ví dụ dạy cơ chế nên nêu rõ phạm vi nhận dạng. Một phép so đúng với chuỗi Product không phải bộ xử lý mọi ngữ cảnh JSON-LD và mọi dạng URI mở rộng.
Nếu cần ngữ nghĩa JSON-LD đầy đủ, dùng thư viện xử lý phù hợp và kiểm context, expansion cùng cơ chế nạp tài nguyên. Bài này tập trung vào cấu trúc phổ biến trong fixture. Không gọi một vòng đệ quy dict là bộ xử lý chuẩn JSON-LD tổng quát.
trích JSON-LD Product bằng Python qua nhiều script và graph
Một trang có thể đặt Product dưới @graph, dùng mảng ở cấp cao hoặc tách node sang script khác. Parser nên có chiến lược duyệt rõ ràng và ghi vị trí node. Đường dẫn này giúp biết giá được lấy từ đâu khi có nhiều sản phẩm hoặc markup lặp.

Nhiều script và node trong graph
Đọc từng script và giữ lỗi cục bộ
Thử parse từng script riêng bằng thư viện JSON. Nếu một script hỏng, ghi chỉ số script và lỗi thay vì làm mất dấu các script còn lại. Chính sách dừng cả trang hay giữ phần hợp lệ cần theo tác vụ, không được âm thầm bỏ qua mà báo đầy đủ.
Không dùng biểu thức chính quy để sửa mọi dấu nháy hoặc dấu phẩy trước json.loads. Chuỗi mô tả có thể chứa ký tự giống cú pháp. Nếu phải hỗ trợ dữ liệu lỗi của một nguồn cụ thể, tạo adapter có version và fixture, giữ bản script gốc để kiểm.
Khi HTML được render bằng JavaScript, script có thể chưa xuất hiện trong bản tải ban đầu. Trạng thái không tìm thấy ở HTML tĩnh không chứng minh trang không công bố dữ liệu sau render. Ghi loại snapshot đã thu và chỉ thêm trình duyệt khi phạm vi dự án thực sự yêu cầu.
Duyệt cấu trúc mà không mất đường dẫn
Đoạn dưới minh họa một cây JSON đã parse. Nó trả node Product cùng đường dẫn trong cấu trúc, không nạp context ngoài và không giải mọi tham chiếu @id. Dùng giới hạn này để người đọc biết output được tạo từ dữ liệu có sẵn.
def products(value, path='$'):
if isinstance(value, dict):
kind = value.get('@type', [])
kinds = [kind] if isinstance(kind, str) else kind
if isinstance(kinds, list) and 'Product' in kinds:
yield path, value
for key, child in value.items():
yield from products(child, path + '.' + key)
elif isinstance(value, list):
for index, child in enumerate(value):
yield from products(child, f'{path}[{index}]')
sample = {'@graph': [{'@type': 'Product', 'name': 'Lab cup'}]}
assert next(products(sample))[0] == '$.@graph[0]'
Trong output thực, thêm script_index bên cạnh node_path. Hai script khác nhau đều có đường dẫn bắt đầu từ $ nên không thể phân biệt chỉ bằng path trong cây. URL nguồn và hash HTML nối vị trí này với snapshot đúng.
Duyệt mọi dict có thể tìm node lồng sâu ngoài @graph. Tuy nhiên một trường không đúng schema vẫn có thể chứa chuỗi @type Product. Bước chuẩn hóa và kiểm hợp đồng cần theo sau, không lấy phát hiện node làm chứng nhận dữ liệu đã hợp lệ.
trích JSON-LD Product bằng Python và quan hệ Offer
Product có thể công bố một Offer, danh sách Offer hoặc cấu trúc tổng hợp theo nguồn. Không ép mọi trường hợp về một giá duy nhất trước khi biết mục tiêu dữ liệu. Nhiều biến thể và điều kiện có thể cần nhiều record con.
Giữ offer cùng sản phẩm cha
Mỗi record offer nên có product_id nội bộ, vị trí offer và nguồn node cha. Nếu cùng trang có hai Product, không lấy mọi giá tìm thấy rồi ghép với tên đầu tiên. Quan hệ cha con là phần dữ liệu cần giữ, không phải chi tiết trình bày có thể bỏ.
Một offer thiếu giá nhưng có URL không giống một offer có giá bằng không. Giữ null hoặc trạng thái thiếu theo schema, không tự điền 0. Số không là một giá trị có ý nghĩa khác dữ liệu chưa được công bố hoặc parser chưa hiểu.
Tài liệu Offer và AggregateOffer giúp phân biệt các thuộc tính. Nếu nguồn đưa khoảng giá thấp và cao, không đổi lowPrice thành price mà không ghi mất ngữ nghĩa. Giữ kiểu node và trường gốc để người dùng hiểu output.
Biến thể không chỉ là nhiều giá
Hai offer có thể khác đồng tiền, người bán, tình trạng hoặc URL. Một Product cũng có thể đại diện một nhóm biến thể theo cách trang thiết kế. Không chọn offer rẻ nhất rồi gọi đó là giá sản phẩm nếu nhiệm vụ yêu cầu dữ liệu đầy đủ theo biến thể.
Nếu nguồn công bố định danh biến thể, lưu nó theo cấu trúc có kiểm. Nếu không có, tạo khóa nội bộ dựa trên snapshot và vị trí nhưng đừng nhận đó là mã sản phẩm chính thức. Khóa kỹ thuật phục vụ truy vết không thay thế ID do nguồn cấp.
Với giá theo khu vực hoặc người dùng, markup tải được có thể chỉ là một biểu diễn công khai. Không suy nó là giá checkout của mọi tài khoản. Tác vụ so sánh cần ghi vùng, phiên và điều kiện nguồn nếu đã được cấp quyền thu các biểu diễn đó.
trích JSON-LD Product bằng Python với giá và currency
Giá nên được giữ cả dạng gốc và dạng chuẩn hóa có kiểm. Chuyển thẳng sang float có thể tạo sai số biểu diễn không cần thiết cho dữ liệu thập phân. Dùng Decimal hoặc kiểu số phù hợp với hợp đồng lưu của dự án.

Offer riêng theo đồng tiền
Dữ liệu mẫu |
Cách giữ |
Lý do |
|---|---|---|
price 120.50, USD |
Chuỗi gốc và Decimal |
Giữ số thập phân rõ ràng |
price 99.00, EUR |
Offer riêng với currency |
Không trộn đồng tiền |
lowPrice và highPrice |
Hai trường khoảng giá |
Không giả làm một giá |
price thiếu |
Null và lý do |
Không biến thành giá bằng không |
Không đoán dấu phân cách theo cảm giác
Chuỗi có dấu phẩy có thể dùng phân cách hàng nghìn hoặc phần thập phân tùy nguồn. Nếu schema đầu vào chưa rõ, từ chối chuẩn hóa hoặc dùng adapter theo nguồn có fixture. Không xóa mọi dấu phẩy vì một ví dụ giá kiểu Mỹ đã chạy được.
Giữ raw_price để người biên tập kiểm khi chuẩn hóa thất bại. Thêm lỗi theo trường và đường dẫn offer thay vì làm cả trang biến mất. Một record quarantine có nguồn rõ thường hữu ích hơn giá số không được điền tự động.
Currency cần được giữ theo offer. Một chuỗi ba chữ in hoa có thể qua kiểm hình dạng nhưng chưa chứng minh nó là mã hợp lệ theo danh mục được dự án chấp nhận. Nếu cần kiểm danh mục, khóa nguồn và version thay vì gán mọi giá thiếu currency thành VND.
Đừng chuyển đổi tiền tệ ngoài phạm vi
Bộ parser của bài không đổi USD sang EUR hoặc VND. Tỷ giá là dữ liệu riêng có thời điểm và nguồn, không phải một phép làm sạch JSON. Nếu dự án cần quy đổi, giữ giá gốc và tạo trường suy ra với nguồn tỷ giá theo quy trình khác.
Hai offer khác đồng tiền không được so trực tiếp bằng số price để chọn rẻ nhất. Một số nhỏ hơn không có cùng đơn vị. Việc giữ đủ currency ngay từ bước trích giúp downstream tránh lỗi so sánh này.
Các giá trong lab là dữ liệu tự tạo, không phải khuyến nghị mua hàng hoặc số liệu tài chính. Mục tiêu là phát hiện parser bỏ mất một offer hoặc gán sai đơn vị. Kết quả hai offer còn nguyên là bằng chứng về cấu trúc fixture, chưa chứng nhận giá nguồn luôn chính xác.
trích JSON-LD Product bằng Python với tham chiếu và ngữ cảnh
Một node có thể dùng @id để tham chiếu thông tin được khai báo nơi khác. Vòng duyệt đơn tìm Product không tự nối mọi tham chiếu đó. Cần quyết định hỗ trợ tham chiếu cục bộ đến đâu và khi nào chuyển sang bộ xử lý JSON-LD đầy đủ.
Lập chỉ mục node trong phạm vi snapshot
Nếu adapter hỗ trợ @id cục bộ, lập bảng ID đến node trên các script đã parse. Phát hiện ID trùng với nội dung mâu thuẫn thay vì lấy node cuối âm thầm. Bảng chỉ mục cần giữ script và path để giải thích nguồn của mỗi phép nối.
Một tham chiếu không tìm thấy phải được đánh dấu unresolved. Không tự tải mọi URL trong @id vì chúng có thể là định danh, không phải endpoint cần truy xuất. Nạp tài nguyên ngoài còn tạo một phạm vi mạng mới cần chính sách và giới hạn riêng.
Các context từ xa thuộc xử lý ngữ nghĩa JSON-LD và có cơ chế riêng. Ví dụ trong bài không fetch context. Nếu thư viện dự án có làm việc đó, kiểm cache, nguồn tin cậy và khả năng tái lập theo tài liệu thư viện, không để dữ liệu một trang điều khiển truy cập mạng không giới hạn.
Nhận dạng kiểu theo phạm vi đã hỗ trợ
Fixture dùng chuỗi Product và trường offers trực tiếp. Một tài liệu dùng URI đầy đủ hoặc alias qua context có thể cần expansion trước khi nhận dạng. Ghi đây là giới hạn của adapter, không kết luận tài liệu đó không có Product chỉ vì phép so chuỗi đơn không thấy.
Khi thêm hỗ trợ dạng mới, tạo fixture giữ cả input và expected output. Không đổi một điều kiện contains để nhận mọi chuỗi có chữ Product vì có thể nhận nhầm kiểu khác. Kiểm tính chính xác của nhánh nhận dạng quan trọng như kiểm số node trả về.
Một node có nhiều kiểu cần được giữ danh sách gốc. Nếu chỉ chọn kiểu đầu, Product nằm sau có thể bị bỏ sót. Ngược lại, phát hiện Product trong danh sách vẫn cần kiểm các trường mà tác vụ sử dụng, không coi mọi thuộc tính còn lại đã hợp lệ.
trích JSON-LD Product bằng Python và provenance đầu ra
Một record chuẩn hóa cần truy lại được script và node đã tạo ra nó. URL nguồn, hash snapshot, script_index, node_path và thời điểm thu là các trường hữu ích. Không lấy ngày chạy parser làm ngày giá có hiệu lực nếu nguồn không công bố điều đó.

Provenance theo script và đường dẫn
Tách thời gian thu với thời gian công bố
Thời điểm crawler nhận HTML cho biết lúc quan sát. Thuộc tính ngày trong markup, nếu có, mang ý nghĩa theo schema của trường đó. Hai mốc có thể khác và đều cần tên rõ, không gộp thành một cột date chung.
Hash HTML giúp biết parser đọc cùng snapshot khi chạy lại. Hash record chuẩn hóa giúp theo dõi output nhưng không thay thế hash nguồn. Một thay đổi parser có thể tạo output khác từ cùng HTML mà không phải website đổi giá.
Nếu lưu script riêng, giữ mối liên hệ với snapshot thay vì chỉ tên tệp product.json. Nhiều trang hoặc nhiều lần thu có thể dùng cùng tên. Khóa kỹ thuật nên tránh ghi đè ngoài ý muốn và không chứa token của URL ký.
Lỗi theo trường giúp sửa có mục tiêu
Phân loại không có script, JSON sai cú pháp, không có node hỗ trợ, offer thiếu giá và currency không đạt. Những trạng thái này dẫn đến cách xử lý khác nhau. Một cột products=[] cho mọi ca sẽ khiến người dùng không biết nguồn thật sự không có sản phẩm hay parser đã bỏ qua lỗi.
Nếu giữ phần hợp lệ của trang, ghi partial cùng số node lỗi. Không trả danh sách một offer rồi báo đã lấy đủ khi offer thứ hai bị loại. Số lượng input, output và quarantine nên đối soát được trong báo cáo.
Khi mua proxy cho tầng tải, kiểm tuyến bằng response đã được phép thu và giữ snapshot. Parser JSON-LD chạy trên snapshot đó có thể kiểm độc lập với mạng. Bộ lab không xác nhận khả năng tương thích của một gateway thương mại cụ thể.
trích JSON-LD Product bằng Python với bộ ca kiểm
Bộ ca nên bắt lỗi nhận nhầm quan hệ và mất dữ liệu, không chỉ kiểm một sản phẩm đơn. Fixture tự tạo cho phép biết số node và giá trị đúng trước khi chạy. Khi thêm nguồn thật, vẫn cần nhãn theo phạm vi quyền sử dụng của dự án.

Ma trận dữ liệu thiếu và sai
Ca cấu trúc và quan hệ
Ca một Product với hai Offer phải giữ cả USD và EUR trong hai record con. Ca nhiều script cần giữ script_index đúng cho từng node. Ca @graph kiểm vòng duyệt không chỉ đọc object cấp cao nhất. Đây là các nhánh cấu trúc có kỳ vọng rõ.
Ca có Organization và BreadcrumbList trước Product giúp phát hiện cách lấy script đầu tiên sai. Ca hai Product giúp kiểm giá không bị ghép sang tên khác. Ca @type là danh sách giúp kiểm nhận dạng kiểu không chỉ dựa vào một chuỗi đơn.
Ca tham chiếu cục bộ chỉ được cho pass nếu adapter đã hỗ trợ và có expected output. Nếu chưa, trạng thái unresolved cần được giữ để người nhận biết. Không thay một record trống thành một offer đầy đủ bằng suy đoán.
Ca dữ liệu thiếu và sai
Ca price thiếu phải giữ null hoặc quarantine theo hợp đồng, khác price bằng không. Ca currency thiếu không được tự điền theo ngôn ngữ giao diện. Ca price có dấu phân cách chưa được hỗ trợ phải báo lý do thay vì đổi số tùy ý.
Ca script JSON hỏng cần giữ lỗi cùng vị trí, đồng thời kiểm chính sách xử lý các script tốt còn lại. Ca HTML không có JSON-LD cần trả trạng thái không tìm thấy, không phải lỗi proxy. Ca payload không phải HTML cần bị nhận diện trước parser script nếu nhiệm vụ yêu cầu HTML.
Ca markup khác giao diện không có một nhãn đúng chung nếu chưa biết hợp đồng nguồn. Giữ cả nguồn quan sát và không gọi giá markup là giá checkout. Nếu nghiệp vụ cần giá thanh toán, đó là tác vụ có quyền truy cập và bộ kiểm riêng.
Tái lập và giới hạn
Đợt soạn kiểm fixture @graph có một Product và hai Offer bằng hai đồng tiền. Kết quả xác nhận số lượng và currency được giữ theo cây mẫu. Nó chưa kiểm expansion đầy đủ, giá động sau render, referenced Offer từ xa hoặc đối chiếu checkout.
Tài liệu JSON-LD 1.1 cung cấp chuẩn ngữ nghĩa rộng hơn parser cây đơn giản. Chọn mức hỗ trợ theo nhu cầu thực rồi ghi rõ. Một adapter nhỏ có giới hạn minh bạch vẫn hữu ích nếu đầu vào và điều kiện từ chối được kiểm.
Khi nâng parser, chạy lại cả ca tốt và ca bị từ chối trước đó. So số Product, số Offer, đường dẫn nguồn và trạng thái lỗi. Không chỉ so một giá đầu tiên vì chính việc chọn giá đầu là rủi ro mà bộ bài đang cần tránh.
trích JSON-LD Product bằng Python khi markup bị lặp
Một trang có thể công bố cùng sản phẩm ở nhiều script do các thành phần giao diện tạo ra. Parser cây sẽ tìm thấy nhiều node là kết quả phù hợp với input. Việc gộp node cần một chính sách riêng, không tự xem mọi bản lặp là dữ liệu có thể bỏ.
Phân biệt node trùng với offer khác điều kiện
Nếu hai node có cùng @id nhưng một node thiếu trường còn node kia có thêm dữ liệu, dự án cần quy tắc hợp nhất có kiểm. Nếu chúng mâu thuẫn về giá hoặc đồng tiền, giữ xung đột để xem xét. Lấy node cuối cùng tùy thứ tự HTML sẽ tạo kết quả khó tái lập khi template đổi.
Nếu không có ID ổn định, có thể giữ khóa theo script và path để bảo toàn quan sát. Đừng dùng tên sản phẩm đơn làm khóa toàn cục vì nhiều biến thể hoặc người bán có thể cùng tên. Một khóa kỹ thuật tạm thời nên được gọi đúng vai trò, không nhận là mã định danh nguồn.
Hai Offer cùng giá và currency vẫn có thể khác tình trạng hoặc URL. Trước khi chống trùng, xác định những trường nào tạo ra một offer theo hợp đồng dữ liệu. Nếu nhiệm vụ chỉ cần một tập giá, đó là phép tổng hợp riêng và phải giữ cách truy lại các offer gốc.
Không để thứ tự duyệt quyết định dữ liệu kinh doanh
Danh sách node có thể thay thứ tự giữa các lần website render. Chọn “node đầu” làm sản phẩm chính cần một lý do được nguồn hoặc tác vụ hỗ trợ. Nếu không có, trả danh sách và trạng thái thay vì tự đoán theo vị trí.
Khi so snapshot theo ngày, khóa theo path có thể thay dù sản phẩm không đổi. Nếu có ID nguồn hợp lệ, dùng nó cùng phạm vi nguồn để nối lịch sử. Path vẫn hữu ích cho provenance của lần quan sát, nhưng không nhất thiết là khóa lịch sử ổn định.
Đầu ra nên phân biệt số node phát hiện, số thực thể sau hợp nhất và số offer được xuất. Ba số này không bắt buộc bằng nhau. Báo rõ quy tắc chuyển đổi giúp người dùng hiểu vì sao parser thấy ba node nhưng bảng cuối chỉ có hai sản phẩm.
Kiểm schema sau chuẩn hóa
Sau khi trích, kiểm kiểu các trường mà downstream sử dụng. Product name có thể là chuỗi theo fixture nhưng một nguồn lỗi có thể đưa object hoặc null. Nếu chuyển mọi giá trị sang str, lỗi cấu trúc sẽ bị che thành một chuỗi không có ý nghĩa.
Với trường URL, phân biệt URL nguồn của trang với URL được công bố trong node. Chúng có thể khác vì canonical, biến thể hoặc lỗi markup. Giữ cả hai theo tên rõ ràng và chỉ resolve URL tương đối theo chính sách đã kiểm.
Một field availability có thể là URI theo schema, không chỉ một chữ “còn hàng”. Nếu chuẩn hóa thành enum nội bộ, ghi mapping và giữ raw value. Giá trị chưa biết cần một trạng thái riêng, không tự gán thành hết hàng hoặc còn hàng.
Tạo báo cáo đối soát theo sản phẩm
Với fixture Lab cup, báo cáo nên cho biết một Product và hai Offer, mỗi Offer có currency riêng. Nếu output cuối chỉ có một đồng tiền, kiểm bước flatten hoặc chống trùng trước. Đây là lỗi dữ liệu có thể xảy ra dù JSON đã parse thành công.
Thêm vào báo cáo đường dẫn của hai giá và kết quả chuẩn hóa theo trường. Người nhận có thể mở script gốc để kiểm mà không tìm trong toàn HTML. Nếu một bước thay giá, giữ lý do và phép biến đổi thay vì chỉ lưu số cuối.
Một bản xuất không cần lặp toàn bộ HTML trong mỗi dòng. Tham chiếu hash snapshot và đường dẫn nguồn giúp giảm dung lượng mà vẫn truy vết được. Bản snapshot cần được lưu theo chính sách quyền và thời hạn của dự án, không mặc định giữ vô hạn.
Khi nào cần chuyển công cụ thay vì mở rộng adapter
Nếu đầu vào dùng nhiều alias, context hoặc tham chiếu phức tạp, việc thêm điều kiện thủ công có thể khó bảo trì. Đánh giá một thư viện JSON-LD có mức hỗ trợ phù hợp và bộ test của dự án. Không dùng sự phức tạp của chuẩn làm lý do gán mọi input ngoài fixture thành không có dữ liệu.
Trước khi thay công cụ, chạy cả hai trên tập mẫu đã gán nhãn. So không chỉ số node mà cả quan hệ, currency và provenance. Một công cụ trả nhiều dữ liệu hơn chưa chắc đúng hơn nếu nó ghép sai hai sản phẩm hoặc làm mất trạng thái xung đột.
Kiểm chuỗi thập phân sau khi xuất
Nếu dùng Decimal trong bộ nhớ, chọn cách serialize phù hợp cho JSONL của dự án. Chuyển sang chuỗi giữ được biểu diễn thập phân đã chọn; chuyển sang số cần một hợp đồng tương ứng. Không để serializer tự biến Decimal thành lỗi rồi bắt exception bằng cách bỏ cả offer.
Đọc lại tệp và kiểm giá cùng currency vẫn nằm trong cùng record. Một bước flatten bảng có thể làm currency bị điền theo hàng trước hoặc tên cột bị đổi. Bộ kiểm cuối cần nhìn object đã xuất, không chỉ object trước khi ghi.
Các quy tắc chuẩn hóa phải được khóa cùng version parser. Khi thay cách diễn giải dấu phân cách, tính lại trên snapshot có nhãn và báo những record đổi giá trị. Đây là thay đổi dữ liệu cần xem xét, không chỉ một sửa định dạng tệp.
Giữ quan hệ Product với từng Offer và currency trước khi chuẩn hóa giá; markup là một quan sát có nguồn, không phải cam kết checkout.
Anh em hãy lưu dữ liệu mẫu cùng cấu hình và kết quả đối chiếu để lần cập nhật sau có cơ sở kiểm lại. Tham khảo thêm tại Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam. Bắt đầu từ phạm vi nhỏ và tiêu chí rõ ràng khi triển khai trích JSON-LD Product bằng Python.