"Bẫy" UTF-16 Trên Windows: Bài Học Xương Máu Từ Thực Chiến Sửa Bug Mã Hóa Unicode

Gần đây, tôi đã đóng góp sửa lỗi đồng thời cho hàng loạt dự án mã nguồn mở nổi tiếng - tất cả đều vướng phải cùng một vấn đề: Thiếu sót trong xử lý Unicode trên Windows. Câu chuyện bắt nguồn từ lịch sử hình thành của hệ điều hành này và sự khác biệt trong thiết kế API so với các nền tảng hiện đại.

Bối cảnh lịch sử và hệ quả công nghệ

Windows - với di sản phần mềm hàng thập kỷ - vẫn đang mang theo “túi bom” mang tên UTF-16. Trong khi thế giới đã thống nhất dùng UTF-8 làm chuẩn mã hóa Unicode, Microsoft lại chọn con đường riêng khi thiết kế các API hệ thống dựa trên UTF-16. Chưa hết, họ còn để lại đống hỗn độn với các API ANSI cũ nhằm đảm bảo tính tương thích ngược.

Điều đáng tiếc là nhiều dự án mã nguồn mở phương Tây, dù có lượng người dùng toàn cầu, lại thiếu hiểu biết sâu về UTF-16. Một phần vì Microsoft tự tạo ra sự nhầm lẫn khi đặt tên “MBCS” (Multi-Byte Character Set) đối lập với “WideChar” - khiến nhiều lập trình viên nghĩ sai về bản chất UTF-16.

Bản chất UTF-16 và “cạm bẫy” surrogate pair

Nhiều lập trình viên vẫn lầm tưởng mỗi ký tự Unicode là 2 byte trong UTF-16. Thực tế phức tạp hơn nhiều:

• Không gian Unicode có 17 planes (mỗi plane chứa 65,536 ký tự)
• BMP (Basic Multilingual Plane) chỉ chiếm 1 plane (U+0000 đến U+FFFF)
• Các ký tự ngoài BMP (như emoji, chữ Hán hiếm SIP) phải dùng surrogate pair - kết hợp 2 mã 16-bit (U+D800-U+DBFF và U+DC00-U+DFFF)

Khi xử lý emoji 🐲 (U+1F40C), bạn sẽ nhận được hai mã UTF-16 liên tiếp: D83D DC0C. Nếu không nhận diện surrogate pair đúng cách, ứng dụng sẽ hiển thị sai hoặc crash.

Bài học thực tiễn từ các dự án lớn

Trong quá trình đóng góp cho các dự án như imgui, lua iup và bgfx, tôi nhận thấy lỗi phổ biến nhất nằm ở xử lý tin nhắn WM_CHAR. Trên Windows:

1. Khi người dùng gõ ký tự ngoài BMP, hệ thống gửi 2 WM_CHAR liên tiếp
2. Phần lớn ứng dụng không nhận diện trường hợp này, dẫn đến mất dữ liệu

Câu chuyện với WM_UNICHAR còn bi hài hơn. Dù tên gọi gợi ý “Unicode 32-bit”, tin nhắn này:

• Không được IME gửi khi nhập liệu thực tế
• Chỉ dùng để chuyển ký tự từ cửa sổ ANSI sang Unicode
• Không giải quyết được surrogate pair

Giải pháp đúng đắn và “bài học máu”

Khi xử lý WM_CHAR, bạn cần:

1. Lưu giá trị surrogate đầu tiên (U+D800-U+DBFF) vào cấu trúc dữ liệu của cửa sổ
2. Khi nhận được surrogate thứ hai (U+DC00-U+DFFF), kết hợp hai giá trị để tính codepoint đúng
3. Chỉ sau đó mới xử lý ký tự hoàn chỉnh

Đừng bao giờ tự viết hàm chuyển đổi UTF-8 ↔ UTF-16. Nên dùng các hàm hệ thống như MultiByteToWideChar() và WideCharToMultiByte(). Thậm chí có nhóm phát triển còn đề xuất WTF-8 - một chuẩn mã hóa sửa lỗi UTF-16 bị xử lý sai!

Lưu ý khi tương tác với API Windows

Các API quản lý tin nhắn như PeekMessage(), DispatchMessage() đều có phiên bản ANSI (A) và Unicode (W). Nếu trộn lẫn:

• Gọi PeekMessageA() cho cửa sổ Unicode có thể làm mất dữ liệu
• Nhất thiết phải dùng bản W (PeekMessageW, DispatchMessageW) khi xử lý cửa sổ Unicode

Các dự án sử dụng MFC hay trực tiếp thao tác MSG cần đặc biệt cẩn trọng. Đây là hệ quả từ thiết kế API “tử tế” nhưng dễ gây nhầm lẫn của Microsoft.

Thú vị về font chữ trên Windows

Khi thử nghiệm với các ký tự hiếm:

• Font thông thường (Arial, Times New Roman) thiếu hỗ trợ SIP
• Windows có cơ chế “fallback” thông qua registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack\SurrogateFallback
• Ví dụ: Khi cần hiển thị chữ Hán hiếm, hệ thống sẽ tìm trong simsunb.ttf (C:\Windows\Fonts)

Kết luận

Trải nghiệm sửa bug này dạy tôi bài học quý giá: Đừng bao giờ đánh giá thấp độ phức tạp của Unicode. Đặc biệt trên Windows, nơi lịch sử và hiện đại giao thoa, cần hiểu rõ từng API trước khi sử dụng. Hãy nhớ rằng:

• UTF-16 không phải “Unicode đơn giản”
• Surrogate pair là quy tắc, không phải ngoại lệ
• Luôn kiểm tra kỹ tài liệu MSDN trước khi xử lý tin nhắn Unicode

Ứng dụng nào muốn tồn tại lâu dài, đặc biệt trong môi trường đa văn hóa, phải đầu tư nghiêm túc vào hỗ trợ Unicode toàn diện.