TrungTamThongTin.comTrung Tâm Thông Tin
Dữ liệu mở

Định dạng dữ liệu CSV, JSON, XML, Excel và API: chọn đúng để khỏi mất dữ liệu

So sánh định dạng dữ liệu CSV, JSON, XML, Excel, Parquet và API: ưu nhược, lỗi hay gặp khi mở bằng bảng tính, cách đọc API có phân trang và giới hạn lượt gọi.

Low angle shot of server racks in a cool data center aisle with small green indicator lights, a technician seen from behind holding a tablet with a blank screen, blue palette

Với dữ liệu dạng bảng đơn giản, CSV là định dạng trao đổi phổ biến và bền nhất; với dữ liệu lồng nhiều tầng, JSON hợp hơn; XML còn mạnh ở các ngành có chuẩn trao đổi lâu đời; Excel tiện cho người đọc nhưng rủi ro cho phân tích; còn API là kênh truy cập, không phải định dạng, thường trả về JSON hoặc XML.

Chọn định dạng sai hiếm khi gây lỗi ngay, mà gây lỗi âm thầm: số 0 ở đầu mã bị mất, ngày bị đổi, chữ tiếng Việt bị vỡ, số thập phân bị nhân lên nghìn lần. Những lỗi này đi vào báo cáo mà không ai thấy. Hiểu đặc tính của từng định dạng giúp bạn biết lỗi nằm ở đâu để chặn từ đầu.

Bài này so sánh các định dạng thông dụng nhất với dữ liệu mở, đi sâu vào các bẫy khi mở CSV bằng bảng tính, giới thiệu định dạng cột cho dữ liệu lớn và định dạng không gian, và hướng dẫn cách làm việc với API dữ liệu ở mức người dùng.

So sánh nhanh các định dạng

Mỗi định dạng sinh ra để giải một bài toán khác nhau. Bảng dưới tóm tắt khi nào nên dùng cái nào:

Định dạngCấu trúcƯu điểmNhược điểmDùng khi
CSVBảng phẳng, mỗi dòng một bản ghiĐơn giản, mọi công cụ đọc được, bền theo thời gianKhông có kiểu dữ liệu, không lồng được, nhiều biến thểTrao đổi bảng, công bố dữ liệu mở
JSONĐối tượng lồng nhau, mảngBiểu diễn được cấu trúc phức tạp, chuẩn của webKhó mở bằng bảng tính, tệp lớn tốn bộ nhớAPI, dữ liệu có quan hệ cha con
XMLCây thẻ có lược đồKiểm định được bằng lược đồ, nhiều chuẩn ngànhDài dòng, xử lý phức tạp hơnVăn bản có cấu trúc, trao đổi giữa hệ thống cũ
ExcelNhiều trang tính, có định dạngNgười dùng quen, xem ngayTự đổi kiểu, giới hạn số dòng, thuộc một hãngTrình bày cho người đọc, không phải lưu trữ gốc
ParquetLưu theo cột, có nén và kiểuNhanh, nhỏ, giữ kiểu dữ liệuCần công cụ chuyên dụng để mởDữ liệu lớn, phân tích lặp lại
GeoJSONJSON cho đối tượng không gianDễ đọc, dùng tốt trên webTệp lớn khi ranh giới chi tiếtRanh giới hành chính, điểm, tuyến

Không có định dạng tốt nhất cho mọi việc. Thực hành tốt của nhiều cổng dữ liệu là công bố cùng một bộ dữ liệu ở hai ba định dạng: CSV cho đại đa số, JSON hoặc API cho lập trình viên, và một bản Excel có trình bày cho người chỉ muốn xem.

CSV: đơn giản đến mức có quá nhiều biến thể

CSV (giá trị phân tách bằng dấu phẩy) được dùng từ những năm đầu của máy tính cá nhân, nhưng mãi tới năm 2005 mới có văn bản mô tả RFC 4180, và đó cũng chỉ là mô tả thông lệ chứ không phải tiêu chuẩn bắt buộc. Hệ quả là "CSV" trên thực tế là một họ định dạng: có tệp dùng dấu phẩy, có tệp dùng chấm phẩy (phổ biến ở các nước dùng dấu phẩy làm dấu thập phân), có tệp dùng tab.

Bốn quy tắc giúp CSV chạy đúng ở mọi nơi: mã hoá UTF-8; dòng đầu là tên cột, ngắn, không dấu; bọc trong dấu ngoặc kép những giá trị chứa dấu phân tách, dấu ngoặc kép hay xuống dòng; dùng dấu chấm làm dấu thập phân và không dùng dấu phân cách hàng nghìn. Ngày tháng nên theo chuẩn ISO 8601 dạng năm-tháng-ngày, vì đó là cách duy nhất không bị hiểu nhầm giữa các vùng và sắp xếp theo chữ cũng đúng thứ tự thời gian.

Kèm theo mỗi tệp CSV nên có một tệp mô tả: tên cột, ý nghĩa, đơn vị, kiểu dữ liệu, cách ghi giá trị thiếu. W3C có khuyến nghị CSV on the Web (2015) cho phép viết mô tả này dưới dạng máy đọc được, nhưng ngay cả một tệp văn bản thường cũng tốt hơn nhiều so với không có gì.

Bẫy khi mở CSV bằng bảng tính

Tự đổi chuỗi thành ngày. Bảng tính tự đoán kiểu và đổi những chuỗi trông giống ngày. Ví dụ nổi tiếng trong sinh học: các tên gene như SEPT2 hay MARCH1 bị đổi thành ngày tháng. Nghiên cứu của Ziemann và cộng sự năm 2016 thấy khoảng một phần năm số bài báo có kèm danh sách gene dạng bảng tính bị lỗi này, và năm 2020 ủy ban đặt tên gene người đã đổi tên một số gene để tránh.

Mất số 0 ở đầu. Mã số thuế, mã đơn vị hành chính, số điện thoại bị đọc thành số và mất số 0. Một khi đã lưu lại, thông tin đó mất vĩnh viễn trong tệp mới.

Số dài bị làm tròn. Bảng tính lưu số với khoảng 15 chữ số có nghĩa; mã định danh dài hơn sẽ bị làm tròn hoặc hiện dạng luỹ thừa. Số căn cước, mã giao dịch phải được giữ dạng chuỗi.

Giới hạn số dòng. Một trang tính Excel chứa tối đa 1.048.576 dòng. Mở tệp lớn hơn, phần thừa bị cắt bỏ, và nếu không để ý cảnh báo, bạn phân tích một phần dữ liệu mà tưởng là trọn bộ.

Vỡ chữ tiếng Việt. Tệp UTF-8 không có dấu hiệu BOM thường bị một số phiên bản bảng tính đọc bằng mã cũ, làm vỡ dấu. Cách an toàn là dùng chức năng nhập dữ liệu và chọn rõ mã hoá, thay vì nhấp đúp mở tệp.

JSON, XML và khi nào cấu trúc lồng là cần thiết

Dữ liệu thực tế nhiều khi không phẳng. Một doanh nghiệp có nhiều ngành nghề, nhiều người đại diện, nhiều địa điểm kinh doanh; một gói thầu có nhiều lô, mỗi lô nhiều nhà thầu dự. Ép những dữ liệu này vào một bảng CSV buộc phải lặp thông tin hoặc tách thành nhiều bảng nối bằng khoá. JSON biểu diễn tự nhiên cấu trúc cha con đó bằng đối tượng và mảng lồng nhau, và trở thành định dạng mặc định của hầu hết API web hiện nay.

XML ra đời trước, năm 1998 thành khuyến nghị W3C, và vẫn đứng vững ở những nơi cần kiểm định chặt bằng lược đồ hoặc dữ liệu có tính văn bản: hồ sơ hải quan điện tử, hoá đơn điện tử, văn bản pháp quy có cấu trúc, siêu dữ liệu thư viện, nguồn cấp tin RSS. Ở Việt Nam, nhiều hệ thống hành chính điện tử trao đổi bằng XML.

Với người phân tích, việc chính là làm phẳng: chuyển JSON hay XML lồng nhau thành một hoặc vài bảng gọn gàng. Các thư viện phổ biến đều có hàm làm việc này; điều cần nghĩ là đơn vị quan sát của bảng đích là gì. Nếu phân tích theo doanh nghiệp, mỗi doanh nghiệp một dòng và gộp ngành nghề thành số đếm; nếu phân tích theo ngành, mỗi cặp doanh nghiệp ngành một dòng.

Làm việc với API dữ liệu: các bước cho người mới

API (giao diện lập trình ứng dụng) cho phép chương trình hỏi dữ liệu theo điều kiện và nhận về kết quả. Với dữ liệu mở, quy trình điển hình như sau:

  1. Đọc tài liệu API: địa chỉ gốc, các điểm truy cập, tham số lọc (quốc gia, năm, chỉ tiêu), định dạng trả về.
  2. Đăng ký khoá truy cập nếu được yêu cầu; giữ khoá ngoài mã nguồn công khai.
  3. Thử một yêu cầu nhỏ bằng trình duyệt hoặc công cụ dòng lệnh để xem cấu trúc kết quả.
  4. Xử lý phân trang: kết quả lớn được chia thành nhiều trang, cần lặp tới khi hết thay vì chỉ lấy trang đầu.
  5. Tôn trọng giới hạn lượt gọi: thêm thời gian chờ giữa các yêu cầu, xử lý mã lỗi quá tải bằng cách chờ rồi thử lại.
  6. Lưu kết quả thô vào tệp trước khi xử lý, để không phải gọi lại khi sửa mã phân tích.
  7. Ghi lại phiên bản API và ngày gọi; API có thể đổi cấu trúc hoặc ngừng phiên bản cũ.

Lỗi phổ biến nhất của người mới là chỉ lấy trang đầu tiên của kết quả rồi tưởng đó là toàn bộ. Luôn so số bản ghi nhận được với tổng số mà API báo trong phần thông tin đi kèm.

Định dạng cho dữ liệu lớn và dữ liệu không gian

Khi dữ liệu vượt vài triệu dòng hoặc có yếu tố bản đồ, CSV và bảng tính bắt đầu bất tiện. Một số định dạng chuyên dụng đáng biết:

  • Parquet: định dạng lưu theo cột, mã nguồn mở, nén tốt và giữ kiểu dữ liệu. Truy vấn chỉ đọc những cột cần, nên nhanh hơn CSV nhiều lần với bảng rộng. Ngày càng nhiều cổng dữ liệu cung cấp bản Parquet bên cạnh CSV.
  • SQLite: cả một cơ sở dữ liệu quan hệ trong một tệp duy nhất, được Thư viện Quốc hội Mỹ liệt kê trong các định dạng khuyến nghị để lưu trữ dữ liệu. Phù hợp khi muốn chia sẻ nhiều bảng có quan hệ.
  • GeoJSON: chuẩn mở dựa trên JSON cho điểm, đường, vùng; dùng nhiều trên web.
  • Shapefile: định dạng không gian cũ nhưng còn rất phổ biến, thực chất gồm nhiều tệp đi kèm nhau; thiếu một tệp là không đọc được, và tên trường bị giới hạn độ dài.
  • GeoPackage: chuẩn mở của OGC dựa trên SQLite, được xem là thay thế hiện đại cho shapefile.

Với dữ liệu không gian, ngoài định dạng còn phải chú ý hệ quy chiếu toạ độ: Việt Nam có hệ VN-2000 bên cạnh hệ WGS84 dùng toàn cầu. Hai lớp bản đồ khác hệ quy chiếu đặt chồng lên nhau sẽ lệch, có khi vài trăm mét.

Chọn định dạng khi chính bạn là người công bố

Ai sẽ dùng dữ liệu? Nếu đa số là nhà phân tích dùng bảng tính, CSV kèm từ điển dữ liệu là đủ. Nếu có lập trình viên xây ứng dụng cập nhật liên tục, cần thêm API. Nếu là nhà nghiên cứu xử lý hàng chục triệu dòng, một bản Parquet giúp họ tiết kiệm nhiều giờ.

Dữ liệu thay đổi nhanh đến đâu? Dữ liệu năm một lần thì tệp tĩnh có phiên bản là hợp lý. Dữ liệu thay đổi theo ngày, như giá, lịch chạy xe, chất lượng không khí, thì API hoặc nguồn cấp cập nhật giúp người dùng không phải tải lại toàn bộ.

Có cấu trúc lồng không? Một bảng phẳng thì đừng ép sang JSON chỉ vì nghe hiện đại. Ngược lại, dữ liệu lồng nhiều tầng thì công bố nhiều bảng CSV có khoá nối, kèm sơ đồ quan hệ, hoặc dùng JSON, thay vì một bảng khổng lồ lặp thông tin.

Năng lực duy trì của bạn ra sao? Một API cần vận hành, giám sát, bảo mật và hỗ trợ người dùng; nếu không có người phụ trách, nó sẽ chết sau vài tháng và làm gãy mọi ứng dụng phụ thuộc. Tệp tĩnh đặt đúng chỗ, đặt tên có phiên bản, thường bền hơn một API bị bỏ rơi.

Câu hỏi thường gặp

Khi công bố dữ liệu, nên chọn CSV hay Excel?

Nên có CSV làm bản chuẩn vì bền, mở và đọc được bằng mọi công cụ. Nếu người dùng chủ yếu là người đọc không chuyên, có thể kèm bản Excel có trình bày, nhưng bản Excel không nên chứa thông tin mà CSV không có.

Vì sao mở CSV bằng Excel chữ tiếng Việt bị lỗi mà mở bằng trình soạn thảo thì không?

Vì khi nhấp đúp, một số phiên bản bảng tính đoán mã hoá theo thiết lập vùng của máy chứ không đọc là UTF-8. Dùng chức năng nhập dữ liệu và chọn UTF-8, hoặc lưu tệp kèm ký hiệu BOM, sẽ tránh được lỗi.

API và tải tệp trọn bộ, cái nào tốt hơn?

Tuỳ nhu cầu. Cần vài chỉ tiêu cập nhật thường xuyên thì API tiện. Cần phân tích toàn bộ, chạy lại nhiều lần thì tải trọn bộ một lần rồi làm việc cục bộ nhanh và ít phụ thuộc hơn. Nhiều dự án kết hợp: tải trọn bộ lần đầu, dùng API cập nhật phần mới.

Định dạng nào bền nhất để lưu trữ dài hạn?

Các định dạng văn bản mở, có mô tả công khai, như CSV UTF-8, JSON, XML, được xem là bền nhất vì đọc được ngay cả khi phần mềm hiện nay không còn. Định dạng nhị phân độc quyền có rủi ro không mở được sau vài chục năm.

JSON có thay thế được CSV không?

Về khả năng biểu diễn thì JSON bao quát được mọi thứ CSV làm, nhưng với bảng phẳng thì JSON dài hơn nhiều vì lặp tên trường ở mỗi bản ghi, và khó mở với người không lập trình. Hai định dạng bổ sung cho nhau hơn là thay thế.

Có cách nào kiểm tra tệp CSV có hợp lệ không?

Có các công cụ kiểm tra cấu trúc như đếm số cột mỗi dòng, phát hiện dấu ngoặc kép không đóng, kiểm mã hoá, và kiểm theo lược đồ nếu có tệp mô tả. Cách nhanh nhất là đọc bằng một thư viện phân tích và xem số dòng, số cột có khớp kỳ vọng không.

Cần tư vấn cụ thể cho trường hợp của bạn?

Chúng tôi sẽ liên hệ trong vòng 24 giờ.

Đăng ký tư vấn ngay

Bài viết liên quan

Bạn cần hỗ trợ thêm?

Để lại thông tin, chúng tôi sẽ liên hệ trong 24 giờ.