Mở đầu

Tôi làm công cụ này vì một lý do rất đơn giản. Làm thủ công mỗi lần quá mệt.

CSV từ hệ thống nội bộ, CSV chuyển từ Excel, và tệp cấu hình xuất từ Linux, Windows hoặc CSDL. Mỗi khi nguồn khác nhau, encoding, xuống dòng và BOM cũng khác.

  • Tưởng là UTF-8 nhưng lại là Shift_JIS
  • Tưởng là LF nhưng lại là CRLF
  • Có hệ thống cần BOM, có hệ thống hỏng khi có BOM

Việc kiểm tra/chuyển đổi bằng mắt và kinh nghiệm không thể mở rộng. Vì vậy tôi làm công cụ nhận mọi nguồn và chuẩn hóa đầu ra theo yêu cầu import.

Vấn đề thực tế không phải một file lỗi

Nếu chỉ hỏng một file thì còn xử lý được. Khó nhất là 10 hay 100 file đến cùng lúc, nguồn thì lẫn lộn.

Rắc rối hơn nữa là mỗi hệ thống đích có một “chuẩn đúng” khác nhau.

  • Hệ thống A chỉ nhận UTF-8 không BOM
  • Hệ thống B ổn định hơn với UTF-8 có BOM
  • Hệ thống C giả định Shift_JIS; UTF-8 nhìn được nhưng import vẫn fail

Trong tình huống này, lời khuyên “cứ thống nhất UTF-8” là vô dụng. Cần một quy trình an toàn, lặp lại được theo đúng đích sử dụng.

Mục tiêu của công cụ này

Chỉ có ba nguyên tắc:

  1. Nhận file từ mọi nguồn
  2. Chuyển đổi theo yêu cầu của hệ thống đích
  3. Xử lý hàng loạt nhưng không làm tăng sự cố

Đây không phải để khoe kỹ thuật chuyển đổi. Đây là công cụ giảm ma sát vận hành.

Quy trình tôi đang dùng thực tế

1. Chốt đặc tả đầu ra trước

Đừng bắt đầu từ đầu vào; hãy chốt đầu ra trước. Cố định ba mục:

  • Encoding (UTF-8 / Shift_JIS, …)
  • Xuống dòng (LF / CRLF)
  • BOM (có / không)

Nếu chỗ này mơ hồ, đổi người vận hành là đổi kết quả.

2. Chia nhỏ phạm vi chuyển đổi

Không chạy toàn bộ ngay. Chia theo hệ thống, thời gian, loại file, và chạy batch nhỏ trước.

Lý do: khi lỗi còn rollback được. Chạy one-shot toàn bộ chỉ nhanh khi thành công.

3. Khóa điều kiện rồi chuyển đổi hàng loạt

Trong công cụ chuyển mã, cố định điều kiện theo từng đích. Không đổi setting giữa chừng. Điều quan trọng là có thể chạy lại cùng điều kiện.

4. Đừng đánh giá thành công bằng “mở được file”

“Mở được là ổn” chính là cửa vào sự cố. Ít nhất phải kiểm tra:

  • Số dòng trước/sau có khớp không
  • Số cột CSV/TSV có bị lệch không
  • � (ký tự thay thế) có tăng không
  • Cột khóa (ID/mã) có giữ nguyên độ dài và loại ký tự không

Nếu không đạt, không được import.

BOM không phải niềm tin, mà là yêu cầu phía đối tác

Tranh luận có/không BOM trong vận hành thường không có nhiều ý nghĩa. Chỉ cần nhìn hệ thống bên nhận xử lý thế nào.

  • Bên nhận ổn với BOM thì xuất có BOM
  • Bên nhận lỗi vì BOM thì xuất không BOM

Ưu tiên “định dạng không làm bên kia hỏng” hơn “định dạng đúng theo lý thuyết”. Vận hành thực tế là như vậy.

Giá trị của công cụ không nằm ở việc chuyển đổi

Giá trị thật ở hai điểm:

  • Quyết định không còn phụ thuộc từng người
  • Chi phí kiểm tra lặp lại giảm xuống

Không thể đưa sự cố encoding về 0 tuyệt đối. Nhưng có thể ngăn việc lặp lại cùng một dạng sự cố. Vì vậy tôi chuẩn bị công cụ nhận mọi thứ và trả về đúng theo mục tiêu sử dụng.

Kết luận

Công cụ này không sinh ra từ lý tưởng. Nó sinh ra để triệt tiêu công việc chỉnh encoding lặp đi lặp lại ngoài hiện trường.

Nhận file khác nguồn, căn encoding/xuống dòng/BOM theo yêu cầu import, rồi trả về đầu ra thống nhất. Chỉ cần tự động hóa luồng này, vận hành đã nhẹ đi rất nhiều.

Xử lý lỗi font không phải việc gồng ý chí. Nó phải được đưa thành quy trình tái lập, để ai làm cũng ra cùng kết quả. Khi đó mới có thể gọi là cứu hàng loạt một cách an toàn.