Kiểu chữ, Unicode và dấu câu tiếng Việt trong sản phẩm số

Ngày rà soát: 4 tháng 10 năm 2026

Trả lời nhanh

Tiếng Việt cần nhiều hơn phông hiển thị được vài chữ có dấu. Giữ văn bản đúng qua nhập, lưu và xuất; thống nhất chuẩn hóa; kiểm tra tệp phông, độ đậm, dấu câu và xuống dòng. Một ảnh chụp có thể đẹp nhưng tìm kiếm, cắt chuỗi hoặc xuất PDF vẫn lỗi. Cần tách và kiểm tra cả dữ liệu lẫn cách hiển thị.

Điểm cần nhớ

• Giữ dấu trong nội dung chính thức và tên khách hàng.
• Phân biệt chuẩn hóa với bỏ dấu hoặc sửa chính tả.
• Nêu giới hạn đếm byte, đơn vị mã hay cụm ký tự.
• Thử từng kiểu phông cùng phương án thay thế.
• Dùng dấu câu phù hợp văn xuôi, nhãn và giá trị kỹ thuật.
• Thử luồng nhập đến xuất, cả sao chép và dán.

Vì sao cần kiểm tra dấu tiếng Việt?

Chữ và dấu thanh có ý nghĩa ngôn ngữ. Bỏ dấu có thể đổi nghĩa hoặc làm sai tên khách. Không xem dấu là trang trí được loại để dễ hiển thị. Hãy sửa mã hóa, phông hoặc thành phần gây vấn đề.

Tạo mẫu gồm chữ thường, hoa, nhiều dấu, câu, số và dấu câu. Có thể bắt đầu với “ă”, “â”, “ê”, “ô”, “ơ”, “ư”, “đ” cùng “ắ”, “ệ”, “Ỡ”, “Ự”. Mẫu không chứng minh đủ mọi ký tự; bổ sung nội dung thật đã duyệt và dữ liệu tên dùng thử không nhạy cảm.

Xem tiêu đề, bảng dày, nút, gợi ý và câu nhiều dòng. Đoạn thường có thể đúng nhưng tiêu đề đậm dùng tệp phông khác thiếu chữ. Kiểm tra dấu trên và dưới, cả nhiều chữ có dấu cạnh nhau. Một màn hình thường đẹp không chứng minh mọi biến thể đều tốt.

NFC và NFD khác gì?

NFC, NFD là các dạng chuẩn hóa tương đương chính tắc trong Unicode Annex #15 [1]. Một chữ hiển thị có thể là điểm mã dựng sẵn hoặc chữ nền kèm dấu kết hợp. Vì vậy, độ dài mã khác nhau chưa có nghĩa là từ khác nhau. Chuẩn hóa không phải bỏ dấu.

Bảng sau được chạy bằng Node.js v24.18.0, ICU 78.3 và dữ liệu Unicode 17.0. Đây là kết quả của môi trường đó với ký tự đã có từ trước, không phải kiểm định toàn bộ phiên bản Unicode mới nhất. Đơn vị UTF-16 dùng độ dài chuỗi JavaScript; byte UTF-8 dùng TextEncoder. Số grapheme tính cả khoảng trắng và dấu câu.

“Đ” không thành “D” qua phân rã chính tắc. Không giả định mọi chữ Việt tách thành chữ ASCII cộng dấu để xóa. Nếu cần tìm kiếm không phân biệt dấu, xây chính sách chỉ mục riêng, không ghi đè bản gốc dùng hiển thị.

Chạy lại phép kiểm tra chuẩn hóa thế nào?

So cùng mẫu ở hai dạng và ghi rõ chỉ số. Mã dưới đây đã chạy để tạo bảng. Nó đo độ dài văn bản, không đo chất lượng nét chữ, chiều cao trình duyệt hoặc hành vi cơ sở dữ liệu. Cần kết hợp kiểm tra tích hợp.

const segmenter = new Intl.Segmenter('vi', {
  granularity: 'grapheme'
});
const encoder = new TextEncoder();
function inspect(value) {
  return ['NFC', 'NFD'].map(form => {
    const text = value.normalize(form);
    return {
      form,
      utf16Units: text.length,
      graphemes: [...segmenter.segment(text)].length,
      utf8Bytes: encoder.encode(text).length
    };
  });
}
console.log(inspect('ắ'));
// NFC: 1 unit, 1 grapheme, 3 bytes
// NFD: 3 units, 1 grapheme, 5 bytes

Chỉ chuẩn hóa ở điểm xử lý đã thống nhất và có mục đích, như so sánh hoặc chính sách lưu. Giữ đầu vào gốc nếu quy trình cần. Không âm thầm đổi dữ liệu đã ký, định danh hoặc giá trị giao thức cần biểu diễn chính xác. Chuẩn hóa chính tắc và tương thích có hệ quả khác nhau; không làm sạch hàng loạt mọi trường.

Kiểm tra phông và chiều cao dòng ra sao?

Xác nhận đúng tệp phông sản xuất, gồm tập con, đậm, nghiêng và thay thế. Tên họ phông trong thiết kế không chứng minh tệp web có đủ chữ. Xem mẫu tiếng Việt ở cỡ chữ và độ tương phản thật.

Thử trước, sau tải phông và khi tải thất bại. Chữ từ phông thay thế xen vào có thể đổi nét, kích thước dòng. Thử cả mẫu NFC và NFD để đường dữ liệu phân rã không thành lỗi ẩn. PDF cũng cần thử riêng vì công cụ xuất, phông nhúng có thể khác trình duyệt.

Chọn chiều cao dòng bằng thử nghiệm thay vì một con số chung. Tìm dấu trên bị cắt, dấu dưới bị che, dòng chồng nhau hoặc khung cố định giấu chữ. Tăng khoảng cách có thể giúp, nhưng cần xem lại bố cục điều hướng và bảng hẹp.

Ghi quy tắc dấu câu và viết hoa thế nào?

Ghi theo loại nội dung. Quy ước văn xuôi không tự áp dụng cho mã, khóa API, đường dẫn hoặc giá trị máy đọc. Ngoặc kép cong có thể hợp bài viết; ký tự ASCII thẳng có thể bắt buộc trong cú pháp. Giữ nguyên khi trích lệnh hoặc định danh.

Giao diện cần nhất quán dấu cuối câu và viết hoa. Nút ngắn thường không cần chấm; câu giải thích đầy đủ có thể cần. Thống nhất tiêu đề, danh sách, chữ viết tắt và tên sản phẩm. Tránh tự viết hoa mọi từ tiếng Việt mà không biên tập.

Phân biệt dấu ba chấm với ý nghĩa tác vụ. Nhãn bị rút cần cách xem phần quan trọng nếu quy trình đòi hỏi. Ba chấm sau lệnh cũng có thể là quy ước mở hộp thoại khác, không nên thêm cho đẹp. Ghi nghĩa dự kiến thay vì trộn cắt chữ và trạng thái thao tác.

Thống nhất gạch nối và gạch dài trong văn xuôi. Giữ dấu trừ, phiên bản, ký tự phân cách kỹ thuật khi có nghĩa xác định. Xem khoảng trắng quanh dấu và số, nhưng không đổi mọi khoảng thành khoảng không ngắt vì có thể gây tràn.

Xuống dòng và cắt chuỗi thế nào?

Thử trình duyệt cùng cấu hình CSS thật, không coi mỗi âm tiết ngăn bằng khoảng trắng là cả một từ vựng. Unicode mô tả cơ hội ngắt dòng; dòng cuối phụ thuộc chiều rộng và bố trí [2]. Quy tắc CSS cũng ảnh hưởng xuống dòng và ngắt từ [3].

Khi tự giới hạn chuỗi, tránh tách chữ nền khỏi dấu kết hợp. Cắt tại vị trí đơn vị mã tùy ý có thể làm hỏng chữ. Xác định giới hạn để lưu hay đếm cho khách và dùng ranh giới phù hợp. Cắt hiển thị của trình duyệt vẫn cần xem phần ẩn có quan trọng không.

Với tên tệp, URL hoặc mã dài, có cách xuống dòng hoặc mở xem phù hợp. Không dùng ngắt mọi nơi cho toàn văn chỉ để xử lý một giá trị bất thường. Thử giá trị dài cạnh câu Việt bình thường và giữ thao tác gắn đúng đối tượng.

Kiểm tra mã hóa qua luồng dữ liệu ra sao?

Hiểu rõ mã hóa của tài liệu, yêu cầu, nơi lưu và xuất. WHATWG Encoding Standard mô tả xử lý mã hóa, gồm UTF-8 [4]. Tệp nguồn đọc được không chứng minh mọi bước giải mã đúng. Xem header, thiết lập nhập và đầu ra của các hệ thống thật.

Thử vòng đầy đủ: gõ hoặc dán mẫu, lưu, đọc lại, sửa, xuất rồi nhập vào công cụ nhận. So nội dung ở từng bước. Tránh giải mã lại chuỗi đã giải mã hoặc coi byte thay đổi là nghĩa đổi khi chưa xét chuẩn hóa.

Phân biệt ký tự thay thế, dấu lộn xộn và ô thiếu chữ. Nguyên nhân có thể là giải mã, phông thiếu, tập con hoặc cắt chuỗi. Ghi nơi lỗi xuất hiện đầu tiên để sửa đúng bước thay vì gõ lại thủ công từng từ.

Ma trận QA thực tế nên có gì?

Ma trận cần cả biểu diễn lẫn hiển thị. Các mục dưới đây là đề xuất, không khẳng định sản phẩm đã đạt. Lưu ảnh chụp và phiên bản môi trường hoặc công cụ xuất.

Đề xuất của LocalizeZone

Khi hỏi dịch vụ bản địa hóa phần mềm, gửi thông tin phông, màn hình, định dạng xuất và giới hạn chuỗi. Rà soát ngôn ngữ cùng kiểu chữ, với kỹ thuật phụ trách mã hóa và hiển thị. Phạm vi rõ giúp phân biệt lỗi dịch với lỗi triển khai và chọn kiểm tra cần cho bản phát hành tiếng Việt.

Câu hỏi thường gặp

Chuẩn hóa có bỏ dấu tiếng Việt không?

Không. Chuẩn hóa chính tắc xử lý biểu diễn tương đương. Bỏ dấu là phép đổi khác, cần mục đích riêng.

Chỉ thử phông thường có đủ không?

Không. Thử tệp và biến thể thật, cả phông thay thế và đường xuất.

Mọi UI nên dùng ngoặc kép cong?

Chọn theo loại nội dung; giữ ký tự thẳng khi cú pháp kỹ thuật yêu cầu.

Đếm ký tự dùng làm giới hạn byte được không?

Phải định nghĩa chỉ số. Bảng cho thấy grapheme, đơn vị UTF-16 và byte UTF-8 khác nhau.

UTF-8 bảo đảm kiểu chữ đúng không?

Không. Phông, dựng chữ và bố cục vẫn cần kiểm tra.

Có nên lưu tên không dấu để tìm kiếm?

Giữ tên chính thức. Chỉ mục riêng có thể dùng chính sách tìm đã duyệt mà không thay bản gốc.

Nguồn và phương pháp

Nguồn Unicode, W3C, WHATWG được rà soát ngày 4 tháng 10 năm 2026. Năm mẫu tự chọn được đo tại máy với phiên bản đã ghi. Bài đề xuất kiểm tra phông và tích hợp, không báo phép đo trình duyệt, kiểm định Unicode đầy đủ hay chứng nhận khả năng tiếp cận. Quy tắc dấu câu là lựa chọn theo ngữ cảnh, không phải tiêu chuẩn xuất bản tiếng Việt chung.

Tài liệu tham khảo

[1] Unicode Consortium. Unicode Standard Annex #15: Unicode Normalization Forms.

[2] Unicode Consortium. Unicode Standard Annex #14: Unicode Line Breaking Algorithm.

[3] W3C. CSS Text Module Level 3.

[4] WHATWG. Encoding Standard.

Bài viết liên quan

• Cẩm nang bản địa hóa tiếng Việt cho phần mềm và SaaS
• Tên người Việt: Hướng dẫn cho biểu mẫu, cơ sở dữ liệu và giao diện
• Độ giãn văn bản tiếng Việt khi bản địa hóa phần mềm
• Hướng dẫn định dạng ngày giờ, số và tiền tệ trong tiếng Việt
• Định dạng địa chỉ Việt Nam cho biểu mẫu, thương mại điện tử và cơ sở dữ liệu
• Định dạng số điện thoại Việt Nam cho website và ứng dụng