Cách kiểm tra và chuẩn hóa Unicode
- Dán văn bản cần kiểm tra, ví dụ một từ không tìm thấy bằng Ctrl+F hoặc dữ liệu so sánh bị lệch.
- Xem độ dài theo code unit UTF-16, code point, grapheme và byte UTF-8, văn bản đã ở dạng chuẩn nào, cùng bảng code point chi tiết.
- Chọn dạng chuẩn (thường là NFC), rồi sao chép hoặc tải văn bản đã chuẩn hóa về máy.
Ví dụ chuẩn hóa
Trước
Việt
Sau
Việt
Trước
Tiếng Việt
Sau
Tiếng Việt
Trước
file x² ＡＢＣ ①
Sau
file x2 ABC 1
Khi nào cần kiểm tra Unicode
- Sửa lỗi tìm kiếm: từ có trong văn bản nhưng Ctrl+F, ô tìm kiếm website hoặc truy vấn cơ sở dữ liệu không tìm thấy.
- Chuẩn hóa dữ liệu, tên tệp lấy từ macOS hoặc ứng dụng khác về NFC trước khi lưu trữ.
- Giải thích vì sao độ dài chuỗi trong JavaScript, giới hạn byte của cơ sở dữ liệu và số ký tự người dùng thấy lại khác nhau.
- Phát hiện ký tự ẩn như khoảng trắng không ngắt, zero-width space hoặc ký tự điều khiển trong dữ liệu.
- Gỡ lỗi chuỗi có emoji, chữ toàn khổ hoặc nhiều hệ chữ khác nhau khi lập trình.
Dựng sẵn, tổ hợp và bốn dạng chuẩn Unicode
Chữ tiếng Việt có dấu có thể được lưu theo hai cách. Dạng dựng sẵn dùng một code point cho mỗi chữ; dạng tổ hợp dùng chữ gốc kèm các dấu đi sau. “Việt” ở dạng NFC có 4 code point, còn ở dạng NFD có 6: V, i, e, U+0323 (dấu nặng), U+0302 (dấu mũ), t. Hai dạng hiển thị giống hệt nhau. Bộ gõ như Unikey gọi hai cách này là “Unicode dựng sẵn” và “Unicode tổ hợp”; dạng tổ hợp của bộ gõ gần với NFD nhưng không hoàn toàn trùng khớp. Chuẩn hóa NFC đưa cả hai về dạng dựng sẵn.
Lỗi hay gặp: văn bản sao chép từ macOS (đặc biệt là tên tệp) hoặc một số ứng dụng ở dạng NFD, trong khi phần còn lại của hệ thống dùng NFC. Kết quả là tìm kiếm không ra, so sánh chuỗi báo khác nhau, sắp xếp và lọc trùng sai, đôi khi dấu còn hiển thị lệch vị trí. Cách khắc phục an toàn là chuẩn hóa về NFC, dạng được khuyến nghị cho nội dung web và lưu trữ.
NFKC và NFKD là dạng tương thích, có thể thay đổi ý nghĩa hoặc hình thức của văn bản: “fi” thành “fi”, “²” thành “2”, chữ toàn khổ “Ａ” thành “A”, “①” thành “1”. Hai dạng này hữu ích khi tạo chỉ mục tìm kiếm hoặc so sánh lỏng, nhưng không nên dùng để ghi đè lên văn bản gốc.
Công cụ hiển thị bốn cách đo độ dài cho cả văn bản gốc và kết quả: code unit UTF-16 (thuộc tính length trong JavaScript), code point, cụm grapheme (ký tự người đọc thấy) và số byte UTF-8. Ví dụ 👍🏽 có 4 code unit, 2 code point, 1 grapheme và 8 byte. Bảng chi tiết liệt kê tối đa 500 code point đầu tiên của văn bản nhập, kèm ký tự, mã U+XXXX, các byte UTF-8 ở dạng hex và loại ký tự (chữ cái, dấu kết hợp, số, dấu câu, ký hiệu, khoảng trắng, ký tự điều khiển/định dạng).
Câu hỏi thường gặp
Nên chọn NFC hay NFD?
Trong đa số trường hợp, hãy dùng NFC: đây là dạng phổ biến trên web, trong cơ sở dữ liệu và trên Windows. Chỉ chọn NFD khi một hệ thống cụ thể yêu cầu, hoặc khi bạn cần xử lý riêng từng dấu.
Sau khi chuẩn hóa, văn bản trông y hệt. Có gì thay đổi không?
Chuẩn hóa NFC và NFD chỉ thay đổi cách lưu code point, không thay đổi hình thức. Hãy so sánh số code point và byte UTF-8 trước và sau, hoặc xem phần cho biết văn bản đã ở dạng chuẩn nào, để thấy sự khác biệt.
Công cụ có sửa được lỗi font TCVN3 hay VNI không?
Không. TCVN3 (ABC) và VNI là các bảng mã cũ không phải Unicode; văn bản dùng chúng thường hiện thành chữ lạ như “ViÖt Nam”. Công cụ này chỉ làm việc với văn bản Unicode, nên cần một bộ chuyển mã chuyên dụng cho trường hợp đó.
NFKC có an toàn để dùng cho mọi văn bản không?
Không nên. NFKC có thể biến “x²” thành “x2” hay “①” thành “1”, làm mất thông tin trong công thức, tài liệu kỹ thuật hoặc nội dung có định dạng đặc biệt. Hãy giữ bản gốc và chỉ dùng NFKC cho mục đích tìm kiếm, so khớp.
Bảng code point hiển thị tối đa bao nhiêu ký tự?
Bảng liệt kê tối đa 500 code point đầu tiên của văn bản nhập để trang luôn mượt. Văn bản dài hơn vẫn được chuẩn hóa và đo độ dài đầy đủ.