CSV Best Practices for Developers — csv-x.com

Tôi vẫn nhớ ngày mà toàn bộ quy trình dữ liệu của chúng tôi bị sập vì ai đó đã mở một tệp CSV trong Excel, thực hiện một "sửa đổi nhanh" và lưu lại. Những gì lẽ ra chỉ là công việc năm phút lại biến thành một sự cố kéo dài sáu giờ, khiến công ty chúng tôi thiệt hại khoảng 47.000 đô la vì doanh thu và thời gian kỹ thuật bị mất. Đó là bảy năm trước, khi tôi còn là kỹ sư dữ liệu cấp thấp tại một công ty khởi nghiệp fintech. Hôm nay, với vai trò Kỹ sư Dữ liệu Chính tại một công ty Fortune 500, tôi đã chứng kiến cùng một kịch bản xảy ra hàng chục lần ở các tổ chức khác nhau, và tôi đã học được rằng tệp CSV vừa phổ biến vừa bị hiểu lầm nhiều nhất trong phát triển phần mềm.

Sự mỉa mai là các tệp CSV (Giá Trị Phân Cách Bằng Dấu Phẩy) được cho là đơn giản. Chúng có thể đọc được bởi con người, được hỗ trợ toàn cầu và đã xuất hiện từ những năm 1970. Tuy nhiên, trong 12 năm làm việc với các hệ thống dữ liệu—từ việc xây dựng các quy trình ETL xử lý hàng tỷ bản ghi mỗi ngày cho đến kiến trúc các hồ dữ liệu cho khách hàng doanh nghiệp—tôi đã chứng kiến nhiều sự cố sản xuất hơn do các vấn đề xử lý CSV hơn bất kỳ định dạng dữ liệu nào khác. Vấn đề không phải là CSV vốn đã xấu; mà là các lập trình viên thường xuyên đánh giá thấp độ phức tạp của chúng và đánh giá cao độ đơn giản của chúng.

Sự Phức Tạp Ẩn Giấu Đằng Sau Các Tệp Văn Bản "Đơn Giản"

Khi hầu hết các lập trình viên nghĩ về các tệp CSV, họ tưởng tượng một định dạng đơn giản: các giá trị được phân tách bằng dấu phẩy, một bản ghi mỗi dòng. Mô hình tư duy này rất không đầy đủ. Trên thực tế, tiêu chuẩn CSV giống như một tập hợp các quy ước được đồng thuận một cách lỏng lẻo với vô số trường hợp méo mó và biến thể thực hiện khác nhau.

Xem điều này: có ít nhất 15 cách khác nhau mà các bộ phân tích CSV xử lý các trường được đóng trong dấu ngoặc chứa các ký tự xuống dòng. Tôi đã cá nhân gỡ lỗi các vấn đề nơi dữ liệu xuất khẩu từ một hệ thống không thể được nhập vào một hệ thống khác do những khác biệt tinh tế trong cách mà họ xử lý các dấu ngoặc bị thoát trong các trường được đóng trong dấu ngoặc. Đặc tả RFC 4180, được công bố vào năm 2005, đã cố gắng chuẩn hóa định dạng CSV, nhưng nó được gán nhãn là "thông tin" thay vì một tiêu chuẩn thực sự, và nhiều công cụ đã có trước nó hoặc chỉ đơn giản là bỏ qua nó.

Trong một dự án đáng nhớ, chúng tôi đang xử lý dữ liệu phản hồi của khách hàng từ nhiều nguồn khác nhau. Xuất khẩu CSV của một nhà cung cấp sử dụng dấu phẩy làm ký tự phân cách, một cái khác sử dụng dấu chấm phẩy (thông dụng ở các khu vực châu Âu nơi dấu phẩy là ký tự phân cách thập phân), và một cái thứ ba sử dụng tab nhưng vẫn gọi chúng là "tệp CSV." Bộ phân tích ban đầu của chúng tôi đã thất bại với khoảng 23% tệp đến, gây ra một tồn đọng 180.000 bản ghi không được xử lý trước khi chúng tôi thực hiện phát hiện định dạng thích hợp.

Bài học ở đây rất căn bản: đừng bao giờ giả định rằng bạn biết tệp CSV chứa gì cho đến khi bạn thực sự kiểm tra nó. Tôi luôn bắt đầu bằng cách kiểm tra vài dòng đầu tiên một cách lập trình, kiểm tra các ký hiệu thứ tự byte (BOM), phát hiện ký tự phân cách thực tế được sử dụng và xác thực mã hóa. Cách tiếp cận phòng thủ này đã tiết kiệm cho tôi vô số giờ gỡ lỗi và ngăn chặn nhiều vấn đề trong sản xuất.

Mã Hóa Ký Tự: Kẻ Thù Dữ Liệu Im Lặng

Nếu tôi phải xác định nguồn gốc phổ biến nhất của các lỗi liên quan đến CSV trong các hệ thống sản xuất, đó sẽ là các vấn đề mã hóa ký tự. Trong kinh nghiệm của tôi, khoảng 40% tất cả các vấn đề xử lý CSV bắt nguồn từ sự không khớp mã hóa, nhưng hầu hết các lập trình viên chỉ xem xét khía cạnh này một cách tối thiểu.

Các tệp CSV giống như gián trong các định dạng dữ liệu—chúng sống sót với mọi thứ, hoạt động ở mọi nơi và gây ra vấn đề khi bạn ít mong đợi nhất. Sự đơn giản khiến chúng trở nên phổ biến chính là sự đơn giản làm cho chúng trở nên nguy hiểm trong các hệ thống sản xuất.

Dưới đây là một ví dụ thực tế từ công việc của tôi: chúng tôi đang xử lý dữ liệu danh mục sản phẩm từ các nhà cung cấp quốc tế. Các tệp CSV trông hoàn hảo khi mở trong Excel trên Windows, nhưng quy trình tiếp nhận dựa trên Python của chúng tôi đã làm hỏng tên sản phẩm, biến "Café" thành "Café" và "naïve" thành "naïve." Nguyên nhân gốc rễ? Các tệp được mã hóa bằng Windows-1252 (một mã hóa Windows cũ), nhưng quy trình của chúng tôi giả định rằng đó là UTF-8. Điều này ảnh hưởng đến khoảng 12.000 bản ghi sản phẩm trong 47 danh mục khác nhau trước khi chúng tôi phát hiện ra.

Cách khắc phục cần phải triển khai một chiến lược phát hiện mã hóa đa giai đoạn. Đầu tiên, chúng tôi kiểm tra xem có BOM UTF-8 (ký hiệu thứ tự byte: EF BB BF trong hệ thập lục phân) hay không. Nếu có, chúng tôi biết đó là UTF-8. Nếu không, chúng tôi sử dụng thư viện chardet để phát hiện mã hóa với độ tự tin hợp lý. Đối với dữ liệu quan trọng, chúng tôi cũng triển khai các quy tắc xác thực để đánh dấu các chuỗi ký tự khả nghi có thể chỉ ra các vấn đề mã hóa.

Tôi khuyên luôn chỉ định rõ ràng mã hóa khi đọc các tệp CSV. Trong Python, điều này có nghĩa là sử dụng encoding='utf-8' (hoặc bất kỳ mã hóa nào mà bạn đã phát hiện) thay vì dựa vào mặc định của hệ thống. Tôi đã thấy các hệ thống sản xuất hoạt động khác nhau khi được triển khai trên các máy chủ khác nhau chỉ vì mã hóa hệ thống mặc định khác nhau giữa môi trường phát triển và sản xuất.

Một thực hành quan trọng khác: khi viết các tệp CSV, luôn sử dụng UTF-8 với BOM nếu những người tiêu dùng của bạn có thể sử dụng Excel. Excel trên Windows sẽ không phát hiện đúng mã hóa UTF-8 nếu không có BOM, dẫn đến văn bản bị rối cho bất kỳ ký tự nào không phải ASCII. Chi tiết nhỏ này đã cứu tôi khỏi nhiều vé hỗ trợ từ người dùng doanh nghiệp những người không thể hiểu vì sao dữ liệu xuất khẩu của họ trông bị hỏng.

Phát Hiện và Xử Lý Ký Tự Phân Cách

"C" trong CSV đứng cho "dấu phẩy", nhưng trên thực tế, tôi đã gặp các tệp CSV sử dụng dấu phẩy, dấu chấm phẩy, ống, tab, thậm chí các ký tự phân cách kỳ lạ hơn như ký tự phân cách đơn vị ASCII (0x1F). Sự lựa chọn ký tự phân cách thường phụ thuộc vào địa phương, công cụ đã tạo ra tệp hoặc bản chất của dữ liệu tự nó.

Tại các quốc gia châu Âu, dấu chấm phẩy thường được sử dụng làm ký tự phân cách vì dấu phẩy là ký tự phân cách thập phân trong các số (ví dụ: "1.234,56" thay vì "1,234.56"). Tôi một lần làm việc trong một dự án tích hợp dữ liệu tài chính từ 23 ngân hàng khác nhau ở châu Âu, và chúng tôi đã gặp bảy quy ước ký tự phân cách khác nhau từ các nguồn đó. Việc xây dựng một hệ thống phát hiện ký tự phân cách mạnh mẽ trở nên thiết yếu.

Cách tiếp cận của tôi để phát hiện ký tự phân cách liên quan đến việc phân tích vài dòng đầu tiên của tệp (tôi thường sử dụng 10-20 dòng để có ý nghĩa thống kê) và đếm số lần xảy ra của các ký tự phân cách có thể. Ký tự phân cách mà xuất hiện cùng số lần trên mỗi dòng có khả năng là ký tự đúng. Tuy nhiên, quy tắc suy diễn này thất bại khi dữ liệu chứa ký tự phân cách trong các trường, đó là lý do mà việc đóng dấu đúng trở nên rất quan trọng.

Tôi đã phát triển một quy tắc đơn giản: nếu dữ liệu của bạn có thể chứa ký tự phân cách, bạn phải sử dụng các trường được đóng trong dấu ngoặc. Và nếu dữ liệu của bạn có thể chứa nhữn