Unicode và UTF-8 khác nhau thế nào?

Điểm mã trước, byte sau

Unicode định nghĩa không gian mã từ U+0000 đến U+10FFFF, đủ chỗ cho 1.114.112 điểm mã, chia thành 17 mặt phẳng (plane), mỗi mặt phẳng 65.536 điểm. Hơn 150.000 điểm mã đã được gán cho ký tự, bao gồm các hệ chữ hiện đại và cổ, ký hiệu và emoji. Điểm mã được viết là U+ theo sau là ít nhất bốn chữ số thập lục phân.

Điểm mã chỉ là một con số. Để lưu hoặc truyền văn bản, nó phải được chuyển thành byte, và có nhiều cách làm việc đó: UTF-8, UTF-16 và UTF-32 đều là các bảng mã cho cùng những ký tự Unicode.

UTF-8 chọn 1, 2, 3 hay 4 byte thế nào

UTF-8, được đặc tả trong RFC 3629, là bảng mã có độ dài thay đổi. Các bit đầu của byte đầu tiên cho biết có bao nhiêu byte theo sau, và mọi byte tiếp nối đều bắt đầu bằng các bit 10. Nhờ vậy luồng dữ liệu tự đồng bộ: bộ giải mã rơi vào giữa một ký tự có thể bỏ qua để tới byte bắt đầu kế tiếp.

Ví dụ: "é" là U+00E9, nhị phân 000 1110 1001. Nó cần mẫu 2 byte. 5 bit cao 00011 được đặt vào 110xxxxx để thành 11000011 (C3), và 6 bit thấp 101001 được đặt vào 10xxxxxx để thành 10101001 (A9).

Vì 128 điểm mã đầu tiên được mã hóa thành đúng một byte giống hệt ASCII, mọi file ASCII hợp lệ đều đã là UTF-8 hợp lệ. Khả năng tương thích ngược này là lý do chính khiến UTF-8 trở thành mặc định trên web, nơi khoảng 98% website sử dụng nó.

UTF-8, UTF-16 và UTF-32

UTF-16 lưu các ký tự trên U+FFFF dưới dạng cặp thay thế (surrogate pair) gồm hai đơn vị 16 bit. Đó là lý do "😀".length trong JavaScript bằng 2: ngôn ngữ này đếm đơn vị UTF-16 chứ không đếm ký tự. Duyệt bằng [..."😀"].length sẽ trả về 1.

Với văn bản tiếng Anh, UTF-8 gọn nhất. Với văn bản chủ yếu là tiếng Trung, Nhật hoặc Hàn, UTF-16 có thể nhỏ hơn, vì các ký tự này chiếm 3 byte trong UTF-8 nhưng chỉ 2 byte trong UTF-16.

Dấu thứ tự byte (BOM)

BOM là ký tự U+FEFF đặt ở ngay đầu file. Trong UTF-16 và UTF-32, nó cho trình đọc biết các byte là big-endian hay little-endian. Trong UTF-8, nó được mã hóa thành EF BB BF và chỉ đóng vai trò chữ ký, vì UTF-8 không có thứ tự byte.

Phần FAQ của Unicode cho biết BOM trong UTF-8 không bắt buộc cũng không được khuyến nghị. Một số trình soạn thảo trên Windows vẫn tự thêm vào, và nó làm hỏng shell script (dòng #! không còn đứng đầu), tiêu đề CSV và các trình phân tích JSON không lường trước nó. Nếu đầu file hiện , đó là BOM UTF-8 bị đọc theo Windows-1252.

Vì sao chữ bị lỗi thành é hoặc ���

Chữ bị lỗi font, gọi là mojibake, xuất hiện khi các byte được giải mã bằng một bảng mã khác với bảng mã đã dùng để ghi chúng:

• é thay vì é: byte UTF-8 C3 A9 bị đọc theo Windows-1252 hoặc Latin-1, vốn ánh xạ C3 thành Ã và A9 thành ©.
• � (U+FFFD, ký tự thay thế): bộ giải mã gặp các byte không phải UTF-8 hợp lệ, thường là văn bản Latin-1 bị đọc như UTF-8.
• Dấu chấm hỏi trong cơ sở dữ liệu: cột hoặc kết nối dùng bộ ký tự không chứa được ký tự đó, nên nó đã bị thay thế khi ghi và mất hẳn.

Cách khắc phục là khai báo bảng mã ở mọi điểm giao tiếp: <meta charset="utf-8"> trong HTML, Content-Type: text/html; charset=utf-8 trong header HTTP, và UTF-8 cho cột cùng kết nối cơ sở dữ liệu. Trong MySQL, hãy dùng utf8mb4; bộ ký tự utf8 cũ chỉ lưu tối đa 3 byte mỗi ký tự và từ chối emoji.