JSON và CSV khi crawl dữ liệu: chọn và xuất đúng định dạng

JSON và CSV khi crawl dữ liệu quyết định cách anh em giữ cấu trúc, trao đổi kết quả và phát hiện lỗi sau thu thập. Cùng ProxyVN, hãy bắt đầu từ người nhận dữ liệu thay vì chọn phần mở rộng theo thói quen. Bài viết dùng một tập sản phẩm nhỏ để so sánh hai định dạng, xuất bằng Python và kiểm tra việc đọc lại từng trường quan trọng.

JSON và CSV khi crawl dữ liệu theo mục đích sử dụng

Hãy xác định người nhận và cách dùng dữ liệu để chọn cấu trúc bàn giao có thể kiểm tra được.

Tệp hợp lệ chỉ là điều kiện đầu tiên; dữ liệu bàn giao còn phải giữ đúng định danh, trạng thái thiếu và quan hệ giữa các trường.

Chọn đầu ra từ câu hỏi cần trả lời

Một nhóm phân tích cần lọc tên và giá trong bảng tính sẽ có nhu cầu khác nhóm xây API cho dữ liệu sản phẩm có nhiều biến thể. Trường hợp đầu thường phù hợp với bảng hàng cột ổn định; trường hợp sau cần giữ quan hệ giữa sản phẩm, biến thể và thuộc tính. Nếu chọn đầu ra trước khi xác định người sử dụng, anh em có thể tạo được tệp hợp lệ nhưng khiến người nhận phải tự đoán cách khôi phục các thông tin đã bị gộp.

Định dạng cũng cần được quyết định theo giai đoạn xử lý. Bản dữ liệu gần với nguồn nên giữ đủ thông tin để kiểm tra và tái xử lý. Bản bàn giao cho báo cáo có thể được chuẩn hóa, đổi tên trường và làm phẳng theo nhu cầu. Hai bản này không nhất thiết dùng cùng một định dạng. Điều quan trọng là có quan hệ truy ngược giữa chúng, để khi một ô bị sai, nhóm biết nó đến từ bản ghi nguồn nào và qua bước biến đổi nào.

Ví dụ trong bài sử dụng hai sản phẩm do người viết tạo cục bộ, không lấy từ một website thương mại. Một sản phẩm có dấu phẩy, dấu ngoặc kép và xuống dòng trong tên; sản phẩm còn lại thiếu giá. Cả hai có mã dạng chuỗi và danh sách nhãn. Tập mẫu nhỏ này không đại diện cho hiệu năng sản xuất, nhưng đủ làm lộ các lỗi phổ biến như mất số 0 đầu, tách sai cột hoặc biến giá chưa biết thành số không.

Phạm vi khác với bước thu thập trang

Chọn bộ phân tích HTML, gọi API hoặc cấu hình proxy là các công việc phía trước bước xuất file. Nếu crawler lấy nhầm trang thông báo lỗi, chuyển kết quả sang JSON không làm nó trở thành dữ liệu sản phẩm đúng. Hãy kiểm tra nội dung và trạng thái thu thập trước khi đưa vào mô hình dữ liệu. Tệp đầu ra cần phản ánh những gì đã được xác minh, không nên âm thầm gán giá trị mặc định để che những trường chưa lấy được.

Anh em có thể đọc thêm cơ chế web scraping proxy để hiểu lớp kết nối trong pipeline. Bài này tập trung vào bước biểu diễn và bàn giao dữ liệu sau khi đã trích xuất. Việc tách phạm vi giúp người vận hành chọn đúng nơi sửa: lỗi đường truyền cần xem yêu cầu mạng, lỗi trường dữ liệu cần xem trích xuất, còn lỗi mất cấu trúc hoặc sai cột cần xem bước chuyển đổi và trình đọc file.

Cấu trúc JSON và CSV khi crawl dữ liệu

Hai định dạng biểu diễn quan hệ khác nhau, nên cần giữ rõ ý nghĩa bản ghi trước khi chọn cách xuất.

JSON giữ quan hệ lồng nhau

RFC 8259 mô tả JSON với các kiểu như object, array, chuỗi, số, boolean và null. Trong một bản ghi sản phẩm, anh em có thể để danh sách nhãn bên trong sản phẩm thay vì phải tạo thêm nhiều cột cố định. Tuy nhiên, khả năng biểu diễn không tự tạo ra quy ước dữ liệu; nhóm vẫn phải thống nhất trường nào bắt buộc, giá trị nào được phép và một danh sách rỗng có ý nghĩa gì.

Ví dụ một sản phẩm có nhiều mức giá theo kích thước. Nếu giữ chúng thành một danh sách các đối tượng con, mỗi mức giá vẫn gắn với kích thước tương ứng. Nếu chỉ tách thành hai danh sách kích thước và giá song song, anh em phải duy trì quan hệ theo vị trí và có thể gây nhầm khi một phần tử bị thiếu. Thiết kế cấu trúc nên làm cho quan hệ quan trọng được biểu diễn trực tiếp, thay vì dựa vào một thỏa thuận ngầm khó kiểm tra.

Trong JSON, trường không xuất hiện và trường có giá trị null có thể được nhóm gán hai ý nghĩa khác nhau. Chẳng hạn, không xuất hiện nghĩa là nguồn chưa cung cấp thuộc tính, còn null nghĩa là thuộc tính đã được kiểm tra nhưng chưa có giá trị. Đó là quy ước nghiệp vụ cần ghi trong tài liệu dữ liệu, không phải ý nghĩa được định dạng áp đặt sẵn. Nếu nguồn và công cụ không phân biệt được, không nên tự tạo ra độ chính xác mà dữ liệu đầu vào không có.

CSV phù hợp bảng có lược đồ rõ

RFC 4180 ghi nhận cách biểu diễn các trường chứa dấu phẩy, dấu ngoặc kép và xuống dòng trong CSV. Vì các trường này có thể chứa chính ký tự phân cách, việc tự nối chuỗi bằng dấu phẩy không đủ để tạo tệp đúng. Hãy dùng thư viện ghi CSV để xử lý dấu bao trường. Đồng thời ghi rõ bảng có dòng tên cột hay không, dùng dấu phân cách nào và thứ tự cột được người nhận kỳ vọng.

Một cột CSV không mang đầy đủ kiểu dữ liệu giống một trường trong mô hình ứng dụng. Khi đọc, chuỗi 0012 có thể bị phần mềm bảng tính hiểu thành số, còn một chuỗi giống ngày có thể bị diễn giải theo cài đặt vùng. Do đó, hợp đồng bàn giao phải nêu kiểu mong muốn cho mã hàng, số điện thoại, thời gian và số tiền. Tệp được mở thành công chỉ chứng minh trình đọc nhận được văn bản, chưa chứng minh các giá trị vẫn giữ đúng ý nghĩa.

Nếu mỗi sản phẩm có nhiều nhãn, cần chọn cách biểu diễn có chủ ý. Có thể tạo bảng nhãn riêng liên kết bằng mã sản phẩm, hoặc lưu một chuỗi JSON trong cột được đặt tên rõ như tags_json. Cách thứ hai tiện cho tập trao đổi nhỏ nhưng người nhận cần biết phải giải mã cột đó. Không nên ghép nhãn bằng dấu phẩy rồi hy vọng không có nhãn nào chứa dấu phẩy, vì khi dữ liệu phát triển quy tắc này rất dễ trở nên mơ hồ.

Cấu trúc trước, định dạng sau

Chuẩn hóa JSON và CSV khi crawl dữ liệu tiếng Việt

Tiếng Việt, mã định danh và giá trị thiếu cần có quy tắc riêng để dữ liệu vẫn giữ đúng nghĩa khi đọc lại.

Mã hóa và nội dung là hai lớp cần kiểm tra

Chọn UTF-8 cho tệp văn bản giúp trao đổi tiếng Việt nhất quán hơn giữa các công cụ. Tuy nhiên, ghi đúng mã hóa không sửa được một chuỗi đã bị giải mã sai ở bước đọc phản hồi. Hãy đối chiếu tên sản phẩm trước khi xuất và sau khi đọc lại. Nếu bản ghi trong bộ nhớ đã hiển thị sai dấu, cần quay về bước tiếp nhận dữ liệu thay vì chỉ đổi encoding khi ghi file. Nếu trong bộ nhớ đúng nhưng tệp đọc lại sai, mới tập trung vào cặp mã hóa và trình đọc.

Với JSON, tùy chọn hiển thị ký tự Unicode trực tiếp và cách ghi byte ra đĩa là hai việc riêng. Một tệp chứa chuỗi escape Unicode vẫn có thể biểu diễn đúng tiếng Việt; điều quan trọng là parser khôi phục đúng giá trị. Trong ví dụ Python, lựa chọn giữ ký tự trực tiếp làm tệp dễ xem bằng trình soạn thảo. Khi nghiệm thu, so giá trị sau giải mã chứ không đòi mọi tệp phải có cùng cách trình bày khoảng trắng hoặc cùng hình thức escape.

Với CSV để bàn giao cho người dùng bảng tính trên Windows, có thể chuẩn bị một biến thể UTF-8 có dấu nhận diện ở đầu file. Ví dụ sử dụng encoding utf-8-sig cho bản CSV và đọc lại bằng cùng encoding. Đây là lựa chọn của bộ mẫu, không phải lời hứa mọi trình đọc sẽ tự nhận đúng. Nếu hệ thống nhận yêu cầu UTF-8 không có dấu nhận diện, hãy xuất đúng hợp đồng đó và kiểm tra bằng chính công cụ nhập của bên nhận.

Giá, đơn vị và mã định danh

Giá nên đi cùng quy ước đơn vị tiền và cách biểu diễn phần lẻ. Trong mẫu, giá là số nguyên theo đơn vị đồng đã thống nhất. Đối với dữ liệu nhiều tiền tệ hoặc cần độ chính xác thập phân, phải thiết kế riêng cách lưu số và quy tắc làm tròn. Không lấy chuỗi có dấu chấm phân cách hàng nghìn rồi chuyển thẳng sang số thực theo cài đặt của máy. Giữ bản hiển thị gốc bên cạnh giá chuẩn hóa thường hữu ích khi cần đối chiếu lỗi.

Mã sản phẩm cần được giữ dạng chuỗi khi số 0 đầu là một phần của định danh. Trường này không được dùng cho phép cộng nên việc trông giống số không phải lý do để ép kiểu. Một lỗi thường gặp là xuất CSV đúng nhưng mở bằng cách nhấp đúp, sau đó lưu lại và làm mất số 0 đầu do trình bảng tính đã suy kiểu. Tập nghiệm thu phải bao gồm cả bước nhập mà người nhận thực sự dùng, không dừng ở việc kiểm tra byte của tệp ban đầu.

Giá thiếu cần có trạng thái giải thích. Trong bộ mẫu, giá null ở JSON được chuyển thành ô trống trong CSV và một cột price_state ghi missing. Nhờ vậy, người đọc không nhầm với giá bằng không. Với dự án thật, có thể cần phân biệt chưa công bố, hết hàng, không được phép xem hoặc lỗi trích xuất. Chỉ thêm những trạng thái có thể xác định từ dữ liệu và quy trình; nếu chưa biết nguyên nhân, ghi trạng thái chưa xác định thay vì đoán.

Ví dụ Python xuất JSON và CSV khi crawl dữ liệu

Ví dụ sau dùng dữ liệu giả lập để kiểm tra cách ghi và đọc lại các trường dễ bị thay đổi.

Tạo bộ mẫu có các trường dễ gây lỗi

Mã dưới đây dùng thư viện chuẩn và được chạy cục bộ bằng Python 3.12.14. Nó không gửi yêu cầu mạng, không cần endpoint proxy và không trích xuất HTML. Anh em có thể lưu ba khối mã theo thứ tự trong cùng file demo_export.py rồi chạy bằng Python. Thư mục demo_output được tạo dưới thư mục làm việc; để tránh ghi đè dữ liệu thật, hãy chạy ví dụ trong một thư mục thử riêng và giữ nguyên tên tệp minh họa cho lần đối chiếu đầu tiên.

Tài liệu json của Python mô tả việc chuyển đổi cấu trúc Python sang JSON và tùy chọn ensure_ascii. Ví dụ cũng dùng allow_nan=False để không xuất các giá trị số đặc biệt ngoài tập số JSON dự kiến. Đây là một hàng rào ở bước ghi, chưa phải toàn bộ bộ kiểm tra lược đồ. Cấu trúc đầu vào vẫn phải được kiểm tra riêng nếu dữ liệu đến từ nhiều nguồn hoặc được người dùng cung cấp.

import csv
import json
from pathlib import Path
 
out = Path('demo_output')
out.mkdir(exist_ok=True)
items = [
    {'id': '0012', 'name': 'Áo, màu "xanh"\nCỡ M',
     'price': 125000, 'tags': ['áo', 'mới'],
     'source_url': 'https://example.com/p/0012'},
    {'id': '0013', 'name': 'Túi vải', 'price': None,
     'tags': [], 'source_url': 'https://example.com/p/0013'}
]
json_path = out / 'products.json'
json_path.write_text(json.dumps(items, ensure_ascii=False,
                               allow_nan=False, indent=2),
                     encoding='utf-8')

Tên sản phẩm đầu tiên cố ý chứa nhiều ký tự cần xử lý, còn mã hàng là chuỗi thay vì số. Danh sách nhãn có cả trường hợp có dữ liệu và rỗng. Thiết kế bộ mẫu theo các ranh giới như vậy hữu ích hơn việc dùng hai dòng chỉ chứa chữ không dấu và số đơn giản. Nếu thử nghiệm quá thuận lợi, một cách xuất sai bằng nối chuỗi thủ công cũng có thể trông như đang hoạt động cho đến khi dữ liệu thật xuất hiện ký tự đặc biệt.

Xuất bảng với trạng thái giá và danh sách nhãn

Tài liệu csv của Python hướng dẫn mở tệp với newline rỗng và cung cấp DictWriter để ghi theo tên trường. Ví dụ dưới đây quy định thứ tự cột, tự chuyển danh sách nhãn thành JSON và tách trạng thái giá khỏi giá trị. Lựa chọn này giữ bảng gọn để xem, đồng thời vẫn có cách giải mã nhãn mà không phải đoán ký tự phân cách bên trong ô. Đây là một mô hình bàn giao cụ thể, có thể thay bằng bảng con khi nhu cầu khác đi.

fields = ['id', 'name', 'price', 'price_state',
          'tags_json', 'source_url']
with (out / 'products.csv').open('w', encoding='utf-8-sig',
                                newline='') as f:
    writer = csv.DictWriter(f, fieldnames=fields)
    writer.writeheader()
    for item in items:
        writer.writerow({
            'id': item['id'], 'name': item['name'],
            'price': '' if item['price'] is None else item['price'],
            'price_state': 'missing' if item['price'] is None else 'known',
            'tags_json': json.dumps(item['tags'], ensure_ascii=False),
            'source_url': item['source_url']
        })

Khi mở CSV trong trình soạn thảo văn bản, bản ghi đầu có thể chiếm nhiều dòng vật lý do tên chứa xuống dòng. Điều đó không đồng nghĩa có thêm một sản phẩm. Số bản ghi phải được đếm qua parser CSV hiểu dấu bao trường, không phải bằng cách đếm ký tự xuống dòng. Nếu hệ thống nhập không chấp nhận trường nhiều dòng, cần thống nhất bước biến đổi hoặc chọn định dạng khác, đồng thời giữ bản gốc để biết nội dung nào đã bị thay đổi.

Ghi rồi đọc lại dữ liệu mẫu

Kiểm thử JSON và CSV khi crawl dữ liệu

Kiểm thử cần đối chiếu giá trị đã đọc lại với dữ liệu gốc, thay vì chỉ xác nhận tệp mở được.

Đọc lại để kiểm tra ý nghĩa từng trường

Phép thử hữu ích nhất ở quy mô nhỏ là ghi rồi đọc lại, sau đó đối chiếu các giá trị có nguy cơ biến đổi. Đọc JSON thành công chưa đủ vì vẫn có thể thiếu một bản ghi hoặc sai kiểu. Đọc CSV thành công cũng chưa đủ vì cột mã có thể bị thay đổi ở một bước trước đó. Khối kiểm tra dưới đây xác nhận hai bản ghi, mã có số 0 đầu, chuỗi chứa ký tự đặc biệt, giá thiếu và hai trường hợp danh sách nhãn.

assert json.loads(json_path.read_text(encoding='utf-8')) == items
with (out / 'products.csv').open(encoding='utf-8-sig', newline='') as f:
    rows = list(csv.DictReader(f))
assert len(rows) == len(items) == 2
assert rows[0]['id'] == '0012'
assert rows[0]['name'] == items[0]['name']
assert rows[0]['price'] == '125000'
assert rows[1]['price'] == '' and rows[1]['price_state'] == 'missing'
assert json.loads(rows[0]['tags_json']) == items[0]['tags']
assert json.loads(rows[1]['tags_json']) == []
for name in ['products.json', 'products.csv']:
    print(name, (out / name).stat().st_size, 'bytes')
print('PASS: 2 records; Unicode, quoting, newline, ID, null, tags')

Lần chạy cục bộ của bộ mẫu tạo products.json dung lượng 340 byte và products.csv dung lượng 204 byte; các kiểm tra trong mã đều vượt qua. Hai dung lượng chỉ mô tả đúng tập mẫu, encoding và cách trình bày đang dùng, không chứng minh CSV luôn nhỏ hơn JSON. Việc thêm thụt lề, lặp tên khóa hoặc chọn cách làm phẳng khác đều có thể thay đổi tỷ lệ. Chưa có kiểm thử nhập Excel hoặc kiểm thử crawler mạng trong kết quả này.

Phân biệt kiểm tra parser và kiểm tra nghiệp vụ

Phép so bằng giữa dữ liệu JSON đọc lại và danh sách gốc kiểm tra được cấu trúc của bộ mẫu. Với dữ liệu thật, vẫn cần các ràng buộc nghiệp vụ như mã không trống, URL nguồn thuộc phạm vi cho phép và giá nằm trong kiểu đã thống nhất. Một tệp có thể hợp lệ về cú pháp nhưng chứa toàn trang lỗi hoặc những trường bị tráo. Vì vậy, thiết kế quy trình nên có bước xác thực trước xuất và bước kiểm tra đọc lại sau xuất, thay vì gom mọi vấn đề vào một lần mở file.

Nên thêm ca thử khi nguồn xuất hiện trường mới, khi một danh sách có nhiều phần tử hoặc khi một bản ghi thiếu thuộc tính bắt buộc. Xác định trước cách hệ thống phản ứng: từ chối lô, đưa bản ghi vào vùng cách ly hay chấp nhận với cảnh báo có thể theo dõi. Không để một trường mới âm thầm biến mất chỉ vì nó chưa có tên trong danh sách cột. Ngược lại, cũng không tự thêm hàng trăm cột vào tệp bàn giao mà không thông báo thay đổi lược đồ cho bên nhận.

Nhập Excel từ JSON và CSV khi crawl dữ liệu

Bước nhập cần được kiểm tra trên công cụ người nhận dùng, đặc biệt với mã có số không ở đầu.

Xem trước dấu phân cách và kiểu cột

Hướng dẫn nhập tệp văn bản của Microsoft mô tả đường dẫn Data, From Text/CSV và bước xem trước hoặc Transform Data. Khi nhập bản CSV, hãy kiểm tra dấu phân cách và mã hóa trong phần xem trước, rồi đặt cột mã định danh theo kiểu văn bản trước khi tải. Tên menu thực tế còn phụ thuộc ngôn ngữ và phiên bản Excel; thao tác cần được nghiệm thu trên môi trường của người nhận.

• 1. Từ workbook dùng để kiểm tra, vào Data và chọn From Text/CSV, sau đó chọn tệp products.csv. Xem tên cột và số cột trước khi tải. Nếu cả hàng dồn vào một cột, kiểm tra dấu phân cách thay vì chỉnh sửa nội dung bằng cách tìm và thay mọi dấu phẩy.
• 2. Chọn Transform Data nếu cần kiểm soát kiểu cột. Đặt mã hàng là văn bản và xem lại bước tự nhận diện kiểu nếu có. Đối chiếu giá trị 0012 trong phần xem trước; mục tiêu là giữ định danh gốc, không chỉ làm nó hiển thị đủ số ký tự bằng định dạng ô sau khi đã mất dữ liệu.
• 3. Kiểm tra tiếng Việt, nội dung có ngoặc kép và tên nhiều dòng, rồi tải vào vị trí phù hợp. Lưu workbook kiểm tra thành một tệp riêng nếu cần giữ các thiết lập bảng tính. Đừng ghi đè bản CSV gốc trong lúc chỉnh sửa trình bày, vì bản gốc là căn cứ để so sánh khi việc nhập làm thay đổi giá trị.

Nhóm bàn giao nên cung cấp một tệp mẫu cùng hướng dẫn kiểu cột, thay vì yêu cầu mọi người tự thay cài đặt vùng của máy. Dấu phẩy có thể xuất hiện trong dữ liệu và trong cách hiển thị số, nhưng parser cần một quy tắc thống nhất để phân biệt chúng. Nếu bên nhận yêu cầu dấu chấm phẩy, tạo đúng biến thể được thống nhất và ghi nó vào tài liệu. Không thay dấu phân cách bằng một thao tác thay thế văn bản thiếu hiểu biết về dấu bao trường.

Chọn cấu trúc cho dữ liệu nhiều bảng

Một sản phẩm có nhiều biến thể thường nên được biểu diễn thành bảng sản phẩm và bảng biến thể, liên kết bằng mã ổn định. Cách này giúp người phân tích tổng hợp theo từng biến thể mà không phải giải mã một ô chứa danh sách. Tuy nhiên, nếu đầu ra chỉ cần lưu trữ gần nguồn hoặc chuyển sang API, giữ cấu trúc lồng trong JSON có thể ít biến đổi hơn. Chọn một hình thức theo tác vụ tiêu thụ thay vì bắt cả hệ thống dùng duy nhất một mô hình.

Khi tách bảng, kiểm tra quan hệ giữa số hàng và số thực thể. Một sản phẩm có ba biến thể sẽ tạo nhiều dòng ở bảng con; đó không phải ba sản phẩm khác nhau. Nếu ghép bảng rồi cộng giá sản phẩm, phép tính có thể bị nhân lên theo số biến thể. Tài liệu dữ liệu cần ghi khóa của từng bảng và mức độ chi tiết của mỗi hàng. Đây là thông tin nghiệp vụ quan trọng hơn việc chỉ mô tả tệp có đuôi CSV hay JSON.

Nhập bảng với kiểu cột rõ

Vận hành JSON và CSV khi crawl dữ liệu theo lô

Khi xử lý nhiều lô, phiên bản lược đồ và dấu hiệu hoàn tất giúp người nhận truy lại nguồn dữ liệu.

Lược đồ, phiên bản và truy ngược nguồn

Mỗi lần xuất nên ghi nhận phiên bản lược đồ cùng mã lần chạy ở hồ sơ đi kèm. Nếu tên trường đổi từ price sang price_vnd, người nhận phải biết thời điểm áp dụng và cách chuyển đổi. Một bản dữ liệu không có phiên bản rất khó so sánh khi crawler cập nhật quy tắc trích xuất. Có thể giữ một từ điển trường ngắn mô tả kiểu, ý nghĩa, quy tắc thiếu và ví dụ cho những trường có khả năng bị hiểu nhầm.

URL nguồn và thời điểm lấy dữ liệu giúp giải thích biến động giá hoặc nội dung. Cùng một mã sản phẩm có thể thay đổi qua các lần chạy, nên khóa dùng để so sánh lịch sử có thể cần thêm thời điểm hoặc mã lô. Không chỉ giữ bản mới nhất nếu mục tiêu là theo dõi thay đổi. Ngược lại, nếu bên nhận chỉ cần một ảnh chụp hiện trạng, đừng trộn dữ liệu của nhiều thời điểm vào cùng tệp mà thiếu thông tin phân biệt.

Nếu cần mua proxy tốc độ cao cho bước thu thập trước khi xuất file, hãy kiểm tra giao thức, xác thực và nhịp truy cập của nguồn dữ liệu trước. Chất lượng đầu ra vẫn cần được nghiệm thu riêng bằng nội dung bản ghi và phép đọc lại; một kết nối nhanh không sửa được lỗi chuyển kiểu, mất Unicode hoặc làm phẳng sai quan hệ giữa các trường.

Dung lượng và khả năng chạy lại

Với lô lớn, đo dung lượng trên một tập đại diện và ghi rõ cách xuất có thụt lề hay nén không. So sánh cần cùng trường dữ liệu và cùng số bản ghi; bỏ danh sách con khỏi CSV rồi kết luận CSV tiết kiệm hơn là so hai sản phẩm thông tin khác nhau. Cũng cần đo bộ nhớ và thời gian theo cách chương trình đọc, vì tải toàn bộ một mảng vào bộ nhớ khác với xử lý từng lô. Tệp nhỏ hơn chưa tự làm cho quy trình dễ phục hồi hơn.

Ghi tệp theo từng lô có ranh giới rõ giúp chạy lại phần thất bại mà không tải lại toàn bộ nguồn. Hồ sơ lô nên có số bản ghi kỳ vọng, số bản ghi thực tế và dấu hiệu hoàn tất. Nếu chương trình bị ngắt khi đang ghi một mảng JSON, tệp có thể chưa đóng cấu trúc; nếu ngắt khi ghi CSV, dòng cuối có thể chưa đầy đủ. Chỉ công bố lô sau khi kiểm tra đọc lại và hoàn tất việc ghi, thay vì để người nhận dùng ngay tệp đang còn thay đổi.

Lưu một tập mẫu kiểm tra hồi quy cùng mã chuyển đổi để dùng khi nguồn đổi giao diện hoặc người nhận đổi công cụ nhập. Tập mẫu nên giữ các ký tự khó, giá trị thiếu và dữ liệu lồng đã có trong ví dụ, rồi bổ sung trường hợp phát sinh thật. Khi có lỗi, sửa quy tắc và chạy lại mẫu trước khi xuất toàn bộ lô. Cách làm này tập trung vào các ranh giới dữ liệu có thể kiểm chứng, giúp giảm việc sửa thủ công sau bàn giao.

Bàn giao lô có thể kiểm tra

Kết luận về JSON và CSV khi crawl dữ liệu

JSON và CSV khi crawl dữ liệu nên được chọn theo cấu trúc và công cụ nhận, rồi kiểm tra bằng phép đọc lại. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để cập nhật hướng dẫn, và giữ bộ mẫu Unicode, giá thiếu, mã định danh khi nghiệm thu JSON và CSV khi crawl dữ liệu.