Unicode "Đấm" Nhau: Khi Chữ 's' Lại Biến Thành 'f' Và Bài Học Xương Máu Cho Anh Em Dev

Cứ ngỡ Unicode là cái chuẩn "vàng vẩu" mà anh em mình cứ thế dùng là xong, nhưng đời không như là mơ. Hóa ra bên trong cái bảng mã to đùng ấy, các ông nội xây dựng tiêu chuẩn cũng đang "đấm nhau" chan chát trên ít nhất 31 ký tự. Một bên bảo là số, một bên bảo là chữ; một bên bảo là 's', một bên khăng khăng là 'f'. Nghe thì có vẻ lý thuyết suông, nhưng tin tôi đi, không cẩn thận là hệ thống của các ông "toang" như chơi.

Tóm tắt nhanh vụ "huynh đệ tương tàn" giữa NFKC và Confusables

Câu chuyện bắt đầu khi một bác dev phát hiện ra sự mâu thuẫn cực kỳ "ảo ma" giữa hai thành phần của Unicode: NFKC (một kiểu chuẩn hóa dữ liệu giúp gom các ký tự biến thể về một mối) và confusables.txt (danh sách các ký tự trông giống hệt nhau nhưng mã code khác nhau).

Dưới đây là những điểm mấu chốt khiến dân tình nhức não:

Xung đột trực diện: Có 31 ký tự mà NFKC và danh sách Confusables không nhìn chung một hướng. Ví dụ, ký tự ſ (một kiểu chữ s cổ), NFKC bảo nó là s, nhưng Confusables lại liệt nó vào dạng dễ nhầm với chữ f.
Con số hay chữ cái?: Vui hơn nữa là ký tự 𝟎 (số 0 toán học). NFKC chuẩn hóa nó về số 0 (digit), nhưng danh sách Confusables lại bảo nó giống chữ o (letter).
Logic ngược đời: Nếu các ông áp dụng Confusables trước rồi mới đến NFKC, kết quả sẽ ra một nẻo. Ngược lại, nếu chạy NFKC trước (đúng quy trình), thì 31 mục trong danh sách Confusables trở thành... code rác (dead code) vì ký tự đã bị biến đổi mất rồi.
Lỗ hổng bảo mật tiềm tàng: Đây không chỉ là chuyện đúng sai, mà là chuyện "mất nick". Nếu hệ thống xử lý username không nhất quán, hacker có thể tạo tài khoản có tên trông y hệt admin để đi lừa đảo.

Giang hồ mạng dậy sóng: Chuyện bé xé ra to hay là "bom hẹn giờ"?

Ngay khi bài viết lên sóng trên Reddit, các cao thủ võ lâm đã nhảy vào combat nhiệt tình với đủ loại sắc thái:

Phe "Spotify là bài học": Nickname Ark_Tane nhắc lại vụ hack Spotify kinh điển năm 2013. Hồi đó, hacker chỉ cần dùng ký tự đặc biệt (small caps) để đăng ký trùng tên với user xịn, khiến hệ thống "ngáo ngơ" và chiếm quyền điều khiển. Vụ Unicode lần này chính là phiên bản nâng cấp của quả lỗi đó.
Phe thực dụng (Pragmatic): Có ông lại bảo: "31 ký tự thì bõ bèn gì? Thời đại này RAM rẻ như cho, thừa vài dòng code trong map cũng chẳng làm server sập được". Ý kiến này bị phản pháo ngay vì vấn đề không phải là tốn tài nguyên, mà là tính đúng đắn. Sai một li là đi một dặm, nhất là khi làm slug cho URL hay xác thực user.
Phe "Đừng có lười": Một số dev cứng nhắc thì khẳng định: Đừng bao giờ tự động chuyển đổi ký tự dựa trên danh sách Confusables. Chỉ nên dùng nó để cảnh báo (ví dụ: "Ê, tên này giống tên ông kia đấy nhé") chứ đừng tự ý "quay xe" thay đổi dữ liệu của người dùng. Tự động mapping là một sai lầm về tư duy hệ thống.

Góc nhìn thực tế từ WorkCloud: Đừng để mấy con "giun dế" làm sập tiệm

Thú thật với anh em, là một dev từng trải qua thời kỳ lương ba cọc ba đồng, tôi hiểu cảm giác chỉ muốn code cho xong rồi đi nhậu. Nhưng làm doanh nghiệp (đặc biệt là SME) mà để dính mấy quả bug Unicode này thì đúng là "cười ra nước mắt".

Thử tưởng tượng các ông vận hành một nền tảng quản lý nhân sự hay bán hàng, khách hàng đặt tên sản phẩm là Teſt (dùng chữ s cổ), hệ thống của các ông tự ý đổi thành Teft (chữ f) thay vì Test (chữ s). Khách tìm không ra hàng, shipper gọi nhầm tên, thế là mất đơn, mất khách.

Bài học rút ra cho anh em:

Chuẩn hóa là bắt buộc: Luôn chạy NFKC trước khi lưu trữ hay so sánh dữ liệu. Đây là bước cơ bản để chống lại đống ký tự "ma trận" ngoài kia.
Cảnh giác với Validation: Nếu các ông đang làm các tính năng nhạy cảm như login, đổi mật khẩu hay đặt slug cho website, đừng bao giờ tin hoàn toàn vào input của người dùng. Hãy filter thật kỹ.
Tối ưu chi phí bằng công nghệ chuẩn: Các doanh nghiệp SME thường không có đội ngũ Senior đủ trình để ngồi soi từng ký tự Unicode thế này. Đó là lý do tại sao WorkCloud luôn tối ưu sẵn các lớp xử lý dữ liệu chuẩn chỉ từ lõi. Thay vì bỏ cả mớ tiền thuê chuyên gia bảo mật về fix mấy lỗi "trên trời rơi xuống", dùng một hệ thống Work OS ổn định, tiết kiệm là cách tiếp cận thực dụng nhất.

Chốt lại: Unicode vẫn rất tuyệt, nhưng hãy là một dev tỉnh táo. Đừng để 31 ký tự lẻ loi làm bay màu cả một cái database mà anh em đã đổ mồ hôi sôi nước mắt mới dựng lên được.

Nguồn tham khảo: