Cảnh Báo 12 Nghìn Tỷ Yên Của Nhật Bản Không Phải Câu Chuyện Về Thiếu Kỹ Sư COBOL. Đó Là Câu Chuyện Về Bảng Mã Ký Tự.

“Vách Đá” Mà Ai Cũng Nhắc Đến Thực Ra Là Một Dòng Ngân Sách

“Vách đá số 2025” (2025年の崖) của Nhật Bản đã là điểm mốc tham chiếu cho rủi ro hệ thống legacy tại nước này kể từ khi Báo cáo DX của METI lần đầu dùng cụm từ này vào năm 2018: nếu các doanh nghiệp không hiện đại hóa hệ thống lõi đã lão hóa, bộ này ước tính thiệt hại kinh tế có thể lên tới 12 nghìn tỷ yên mỗi năm trong giai đoạn 2025-2030 (ict-miraiz; c3index). Bảy năm sau, cảnh báo này vẫn chưa lỗi thời — một khảo sát tiếp nối năm 2025 cho thấy chỉ 7% doanh nghiệp cho biết đã hoàn toàn vượt qua “vách đá”, trong khi khoảng 40% vẫn báo cáo những thách thức nghiêm trọng chưa được giải quyết (ict-miraiz).

Phần lớn các bình luận xoay quanh con số đó tập trung vào những điều dễ đoán: kỹ sư COBOL nghỉ hưu, chi phí bảo trì phình to trên những hệ thống chẳng ai tài liệu hóa đầy đủ, và rủi ro vận hành của một lần chuyển đổi kiểu “thay thế toàn bộ”. Điều nhận được ít sự chú ý hơn nhiều là một dạng lỗi không đợi đến đêm chuyển đổi mới xuất hiện — nó đã nằm sẵn trong dữ liệu ngay từ thời điểm hai hệ thống mã hóa ký tự khác nhau buộc phải thống nhất với nhau về ý nghĩa của một byte.

Cái Bẫy Không Ai Lập Ngân Sách Cho Nó

Chính tài liệu hướng dẫn hiện đại hóa của IBM gọi tên vấn đề này một cách rõ ràng, xem nó là một trong mười khuôn mẫu thất bại đã được ghi nhận trong các dự án chuyển đổi hệ thống legacy: xử lý bảng mã và thuộc tính ký tự (“文字コード・属性の罠”) có hẳn một mục riêng trong “10 cái bẫy” hiện đại hóa của IBM (IBM) — không phải vì nó hiếm gặp, mà vì đây là dạng vấn đề trông như đã được giải quyết nhưng thực ra thì chưa.

Cơ chế của nó như sau. Các hệ thống mainframe được xây dựng từ thời IBM System/360 năm 1964 chủ yếu dùng EBCDIC, và EBCDIC không hề thống nhất về thứ tự sắp xếp cơ bản với các bảng mã mà một hệ thống hiện đại thực sự đang chạy — Shift-JIS, Unicode. Khi sắp xếp tăng dần, EBCDIC đặt chữ cái trước chữ số; còn Shift-JIS và Unicode đặt chữ số trước chữ cái (Hitachi ITPF). Một bước sắp xếp COBOL hay một mệnh đề ORDER BY vốn đã “chạy đúng” suốt ba mươi năm có thể âm thầm đảo lộn thứ tự bản ghi ngay khi cùng logic đó chạy trên dữ liệu đã được mã hóa lại — không hề báo lỗi, không hề ghi log ngoại lệ, chỉ đơn giản là kết quả sai theo cách mà bộ kiểm thử hồi quy hiện có chưa bao giờ được viết ra để bắt được.

Ký tự tự định nghĩa (外字/gaiji) khiến vấn đề càng phức tạp hơn. Di trú từ một môi trường sử dụng các ký tự đăng ký tùy chỉnh nghĩa là những ký tự đó phải được tạo lại ở môi trường đích, và số lượng ký tự có thể đăng ký được lại phụ thuộc vào bảng mã ký tự nào được chọn (Hitachi ITPF) — bao gồm cả các ký tự mã số linh kiện đặc thù của từng doanh nghiệp lẫn ký tự gaiji đặc thù trong ngành ngân hàng. Đây là một vấn đề tương thích phổ biến đến mức Oracle cung cấp hẳn một tính năng giả lập thứ tự nhị phân EBCDIC riêng, chỉ để các ứng dụng sau di trú không phải viết lại để thích ứng với sự khác biệt này (tài liệu Oracle) — một dấu hiệu cho thấy các nhà cung cấp lớn xem đây là một vấn đề tương thích tồn tại lâu dài, chứ không phải thứ mà một lần chuyển đổi tệp là có thể âm thầm giải quyết xong.

Vấn Đề Của Tầng Phân Tích Cú Pháp, Không Phải Của Script Di Trú

Cách xử lý phổ biến là gắn thêm một bước chuyển đổi bảng mã ngay trước bất cứ thứ gì đọc dữ liệu — đưa dữ liệu xuất ra qua một bộ chuyển đổi mã, rồi hy vọng logic ở tầng dưới (so sánh khi sắp xếp, ranh giới trường có độ dài cố định, việc nhận diện byte đầu/byte sau trong DBCS) vẫn hoạt động giống hệt như trên dữ liệu gốc. Khi giả định về bảng mã ở phía lưu và phía đọc không khớp nhau, kết quả là hiện tượng ký tự lỗi (mojibake) — và tệ hơn, trong những trường hợp sự sai lệch không tạo ra văn bản lỗi rõ ràng mà chỉ âm thầm cho ra giá trị sai.

Legacy Dragon đọc trực tiếp Shift-JIS, EBCDIC và DBCS ở dạng gốc, song song với mười ngôn ngữ nguồn mà nó phân tích cú pháp — COBOL, JCL, PL/I, VB6, VB.NET, PowerBuilder, Assembly, SQL/DB2, CICS và REXX. Đây là một lựa chọn thiết kế có chủ đích: việc xử lý bảng mã nằm bên trong chính bộ phân tích cú pháp xây dựng nên đồ thị AST và đồ thị phụ thuộc, chứ không nằm trong một script tiền xử lý chạy trước khi Legacy Dragon kịp nhìn thấy tệp. Một đồ thị được xây dựng từ bản sao đã chuyển đổi trước sẽ thừa hưởng bất cứ sai sót nào mà bước chuyển đổi đó đã mắc phải. Còn một đồ thị được xây dựng bằng cách phân tích cú pháp trực tiếp trên bảng mã gốc thì không có chỗ để thừa hưởng loại lỗi đó — điều này quan trọng nhất chính ở nơi mà con số ước tính 12 nghìn tỷ yên giả định rủi ro đang nằm: trong những hệ thống mà lõi mainframe EBCDIC và các hệ thống ngoại vi thời Shift-JIS đã cùng tồn tại suốt nhiều thập kỷ, chứ không phải trong slide về nhân sự nghỉ hưu mà ai cũng đã thuộc lòng.

Điều này không có nghĩa là chỉ cần giải quyết tính trung thực của bảng mã là doanh nghiệp sẽ thoát khỏi “vách đá” của METI. Rủi ro về nhân sự nghỉ hưu và tuổi đời hệ thống là những vấn đề thực sự và tồn tại độc lập. Nhưng điều này thực sự có ý nghĩa là: giai đoạn đánh giá mà hầu hết các dự án hiện đại hóa thực hiện trước khi động đến bất kỳ dòng logic nào có thể bắt đầu bằng một câu hỏi nhỏ hơn và có thể kiểm chứng được — liệu đồ thị đang được xây dựng đã thực sự hiểu dữ liệu này được mã hóa như thế nào, hay chúng ta chỉ đang tin tưởng vào một bước chuyển đổi chưa từng được xác minh?

---

Muốn biết việc xử lý bảng mã ngay ở tầng phân tích cú pháp — thay vì đoán mò sau đó — trông như thế nào? Xem Legacy Dragon tại dragon.aitytech.com, đọc thêm về vì sao đồ thị AST được xây dựng trước hết như một công cụ phân tích tác động, hoặc liên hệ chúng tôi tại [email protected].