Một ký tự tiếng Việt chiếm bao nhiêu byte trong UTF-8
Trong UTF-8, một chữ tiếng Việt ở dạng dựng sẵn chiếm 1, 2 hoặc 3 byte, tùy chữ đó có dấu hay không và thuộc dải điểm mã nào trong Unicode. Nếu chữ có dấu được biểu diễn bằng nhiều điểm mã kết hợp (dạng tổ hợp), tổng số byte có thể lớn hơn. Ở dạng dựng sẵn, chữ không dấu như a chiếm 1 byte, các chữ à, ă, đ, ơ, ư chiếm 2 byte, còn phần lớn chữ mang dấu thanh như ạ, ế, ồ, ệ chiếm 3 byte.
Emoji không phải chữ tiếng Việt nhưng thường xuất hiện trong bình luận, tin nhắn và mô tả sản phẩm. Một emoji đơn như 😀 chiếm 4 byte, còn emoji ghép từ nhiều điểm mã có thể cần nhiều byte hơn dù hiển thị thành một biểu tượng. Khi ước lượng dung lượng, cũng đừng mặc định mọi chữ có dấu đều có cùng số byte. Chữ ệ cần 3 byte, nhiều hơn chữ à một byte.
| Nhóm chữ | Ví dụ | Mã Unicode | Số byte (dựng sẵn) |
|---|---|---|---|
| Chữ cái không dấu | a | U+0061 | 1 |
| Chữ có dấu trong khối Latin-1 Supplement | à | U+00E0 | 2 |
| Chữ trong khối Latin Extended-A | ă, đ | U+0103, U+0111 | 2 |
| Chữ trong khối Latin Extended-B | ơ, ư | U+01A1, U+01B0 | 2 |
| Chữ trong khối Latin Extended Additional | ạ, ế, ồ, ệ | U+1EA1, U+1EBF, U+1ED3, U+1EC7 | 3 |
| Emoji | 😀 | U+1F600 | 4 |
Các con số trong bảng được tính bằng Python ngày 29/10/2026, dùng thư viện unicodedata để chuẩn hóa rồi mã hóa sang UTF-8. Đây là cách UTF-8 vận hành theo chuẩn, không phải kết quả đo trên một công cụ cụ thể nào.
Vì sao chữ tiếng Việt có dấu chiếm 2 hoặc 3 byte
Trong UTF-8, mỗi ký tự chiếm từ 1 đến 4 byte tùy vị trí của nó trong bảng mã Unicode. Theo mục 3 của RFC 3629, đặc tả chính thức của UTF-8 (đọc ngày 29/10/2026), các ký tự trong khoảng U+0000 đến U+10FFFF được mã hóa bằng chuỗi từ 1 đến 4 byte, chia thành bốn vùng.
| Khoảng mã Unicode | Số byte trong UTF-8 | Chữ tiếng Việt thuộc vùng này |
|---|---|---|
| U+0000 đến U+007F | 1 | a, b, c và các chữ không dấu khác |
| U+0080 đến U+07FF | 2 | à (U+00E0), ă (U+0103), đ (U+0111), ơ (U+01A1), ư (U+01B0) |
| U+0800 đến U+FFFF | 3 | ạ (U+1EA1), ế (U+1EBF), ồ (U+1ED3), ệ (U+1EC7) |
| U+10000 đến U+10FFFF | 4 | Không có chữ tiếng Việt, nhưng emoji như 😀 (U+1F600) nằm ở đây |
Nói cách khác, chữ càng nằm xa đầu bảng mã thì càng cần nhiều byte. Khối Latin Extended Additional, nơi chứa phần lớn chữ tiếng Việt mang dấu thanh, nằm sau mốc U+0800 nên mỗi chữ trong đó tốn 3 byte. Bài viết chỉ đề cập Unicode; các bảng mã cũ như TCVN3 hay VNI hoạt động theo cách khác và nằm ngoài phạm vi bài này.
Unicode dựng sẵn và tổ hợp khác nhau thế nào
Unicode dựng sẵn biểu diễn mỗi chữ có dấu bằng một mã duy nhất, còn Unicode tổ hợp dùng chữ gốc kèm một hoặc nhiều dấu ghép đứng sau. Hai dạng này trông giống hệt nhau trên màn hình nhưng có số byte khác nhau.
Báo cáo Unicode Standard Annex #15 về chuẩn hóa Unicode (bản Unicode 18.0.0, Revision 58 ngày 12/8/2026, đọc ngày 29/10/2026) định nghĩa hai dạng chuẩn hóa liên quan. NFD là “Canonical Decomposition”, tức là phân tách chữ thành chữ gốc và dấu ghép. NFC là “Canonical Decomposition, followed by Canonical Composition”, tức là phân tách rồi ghép lại thành mã dựng sẵn khi có thể. Cũng theo báo cáo này, các chuỗi tương đương chính tắc (canonical equivalent) khi hiển thị đúng sẽ trông giống nhau và hoạt động như nhau. Dạng dựng sẵn quen thuộc ở Việt Nam gần tương ứng với NFC. Dạng tổ hợp gồm chữ gốc và dấu ghép, chẳng hạn kết quả của chuẩn hóa NFD.
| Chuỗi | Số điểm mã (NFC) | Byte dạng dựng sẵn (NFC) | Byte dạng tổ hợp (NFD) |
|---|---|---|---|
| a | 1 | 1 | 1 |
| à | 1 | 2 | 3 |
| ă | 1 | 2 | 3 |
| đ | 1 | 2 | 2 |
| ơ, ư | 1 | 2 | 3 |
| ạ | 1 | 3 | 3 |
| ế, ồ, ệ | 1 | 3 | 5 |
| Việt | 4 | 6 | 8 |
| Tiếng Việt | 10 | 14 | 18 |
| Nguyễn | 6 | 8 | 10 |
| Xin chào | 8 | 9 | 10 |
| 😀 | 1 | 4 | 4 |
Chữ ệ minh họa rõ nhất sự chênh lệch này. Ở dạng dựng sẵn, ệ là một mã U+1EC7 dài 3 byte. Ở dạng tổ hợp, nó trở thành chữ e (1 byte) cộng hai dấu ghép (mỗi dấu 2 byte), tổng cộng 5 byte. Vì thế, cụm “Tiếng Việt” trông như nhau ở cả hai dạng nhưng chiếm lần lượt 14 và 18 byte. Chữ đ không có dạng phân tách nên giữ nguyên 2 byte.
Vì sao tìm kiếm và so sánh chuỗi bị lỗi
Khi so sánh trực tiếp theo điểm mã hoặc theo byte, “Việt” dựng sẵn và “Việt” tổ hợp là hai chuỗi khác nhau dù mắt người không phân biệt được. Một số hệ thống có bước chuẩn hóa hoặc đối chiếu riêng nên kết quả còn tùy cách hệ thống xử lý. Hậu quả có thể là tìm kiếm không ra kết quả, bước kiểm tra trùng lặp bỏ sót dữ liệu, hoặc độ dài đo được lớn hơn dự kiến. Văn bản sao chép từ nhiều nguồn có thể ở những dạng khác nhau, vì vậy đừng mặc định mọi dữ liệu đều đã ở dạng dựng sẵn.
Với hệ thống cần coi hai dạng này là một, cách xử lý thường dùng là chuẩn hóa về NFC trước khi lưu, so sánh hoặc tìm kiếm. Hãy chuẩn hóa cả dữ liệu đã lưu lẫn chuỗi người dùng gõ vào ô tìm kiếm để hai bên luôn ở cùng một dạng.
Khi nào số byte của văn bản tiếng Việt quan trọng
Số byte trở nên quan trọng khi hệ thống đặt giới hạn theo byte thay vì theo ký tự, hoặc khi công cụ bạn dùng đếm theo một đơn vị khác. Dưới đây là ba trường hợp thường gây nhầm lẫn.
Cơ sở dữ liệu MySQL
Theo tài liệu MySQL 8.4 về kiểu CHAR và VARCHAR (đọc ngày 29/10/2026), độ dài khai báo của CHAR và VARCHAR là số ký tự tối đa. VARCHAR(50) giới hạn 50 ký tự chứ không phải 50 byte, nhưng tổng kích thước một hàng vẫn tính bằng byte. Giới hạn này là 65.535 byte cho cả hàng. Theo tài liệu MySQL 8.4 về giới hạn kích thước hàng (đọc ngày 29/10/2026), cột TEXT và BLOB chỉ tính 9 đến 12 byte vào giới hạn này vì nội dung được lưu riêng, và InnoDB còn có giới hạn riêng theo kích thước trang. Ngoài dữ liệu, mỗi giá trị VARCHAR còn có 1 hoặc 2 byte tiền tố để lưu độ dài.
Theo trang tài liệu MySQL 8.4 về bộ ký tự utf8mb4, utf8mb4 cần tối đa 4 byte cho mỗi ký tự nhiều byte. Do đó, độ dài tối đa thực tế của một cột VARCHAR còn phụ thuộc vào giới hạn hàng và bộ ký tự bạn chọn. Một bảng có nhiều cột văn bản dài có thể chạm giới hạn hàng dù số ký tự của từng cột có vẻ không lớn.
API và biểu mẫu giới hạn theo byte
Một số API, biểu mẫu hay trường dữ liệu đặt giới hạn theo byte. Giả sử một trường chỉ nhận tối đa 16 byte. Cụm “Tiếng Việt” có 10 ký tự, nên nếu đếm theo ký tự, bạn sẽ tưởng vẫn còn dư nhiều. Thực tế, ở dạng dựng sẵn cụm này đã chiếm 14 byte, còn ở dạng tổ hợp thì lên tới 18 byte, vượt giới hạn. Hãy đọc kỹ tài liệu của hệ thống bạn dùng để biết giới hạn tính theo ký tự hay theo byte.
Thuộc tính length trong JavaScript không đếm byte
Theo tài liệu MDN về String length (đọc ngày 29/10/2026), thuộc tính length trả về độ dài chuỗi tính bằng đơn vị mã UTF-16. "Việt".length trả về 4 nhưng chuỗi này chiếm 6 byte UTF-8 ở dạng dựng sẵn. MDN cũng nêu ví dụ "😄".length bằng 2 dù trên màn hình chỉ có một emoji. Vì vậy, dùng length để kiểm tra giới hạn byte sẽ cho kết quả sai với văn bản tiếng Việt có dấu.
Đếm ký tự và byte bằng Python và JavaScript
Trong Python, len đếm số điểm mã Unicode trong chuỗi, không nhất thiết bằng số chữ người đọc nhìn thấy; muốn có số byte thì phải gọi len trên chuỗi đã mã hóa UTF-8. Trong JavaScript, length đếm đơn vị UTF-16, còn Blob.size cho số byte. Theo đặc tả W3C File API (bản Working Draft ngày 12/9/2026, đọc ngày 29/10/2026), khi tạo Blob từ chuỗi, trình duyệt mã hóa chuỗi sang UTF-8 và size trả về kích thước của chuỗi byte đó. Các dòng mã dưới đây chỉ mang tính minh họa.
| Ngôn ngữ | Dòng mã | Kết quả |
|---|---|---|
| Python | s = "Tiếng Việt" | Gán chuỗi ở dạng dựng sẵn |
| Python | len(s) | 10 ký tự |
| Python | len(s.encode("utf-8")) | 14 byte |
| Python | import unicodedata rồi len(unicodedata.normalize("NFD", s).encode("utf-8")) | 18 byte |
| JavaScript | "Việt".length | 4 (đơn vị UTF-16) |
| JavaScript | new Blob(["Việt"]).size | 6 byte |
| JavaScript | "Việt".normalize("NFC") | Đưa chuỗi về dạng dựng sẵn trước khi so sánh hoặc lưu |
Khi kiểm tra giới hạn byte của một API hay tệp dữ liệu, hãy đo đúng chuỗi sẽ được gửi hoặc lưu. Nếu quy trình của bạn chuẩn hóa về NFC trước khi lưu, hãy chuẩn hóa rồi mới đếm byte để con số khớp với dữ liệu thật.
Cách tính dung lượng văn bản tiếng Việt bằng Trình tính kích thước văn bản
Để biết nhanh một đoạn văn bản chiếm bao nhiêu byte, bạn có thể dán nó vào Trình tính kích thước văn bản trên Digily Link. Digily Link là sản phẩm của chúng tôi, và công cụ này mở cho mọi người dùng.
- Mở Trình tính kích thước văn bản trên digily.link.
- Dán văn bản vào ô Văn bản.
- Xem dòng Kích thước. Kết quả hiện ngay khi bạn gõ, không cần bấm nút.
- Nếu cần, sửa hoặc rút gọn văn bản ngay trong ô. Con số sẽ tự cập nhật sau mỗi lần gõ.
Kích thước được tính ngay trong trình duyệt, văn bản không được gửi lên máy chủ. Công cụ dùng phép tính new Blob([text]).size, tức là đếm số byte UTF-8 của chuỗi đúng như khi bạn dán vào, giống dòng mã JavaScript ở phần trên.
Một vài lưu ý để đọc kết quả cho đúng.
- Công cụ quy đổi theo hệ nhị phân, 1 KB trên giao diện bằng 1024 byte (theo quy ước đơn vị chuẩn, 1024 byte là 1 KiB). Kết quả hiển thị theo các đơn vị B, KB, MB, GB, TB và làm tròn đến 2 chữ số thập phân.
- Văn bản dài đúng 1024 byte vẫn hiển thị là “1024 B”. Chỉ khi vượt quá 1024 byte, kết quả mới chuyển sang KB.
- Ký tự xuống dòng LF chiếm 1 byte, còn cặp CRLF chiếm 2 byte. Trong ô Văn bản, dấu xuống dòng thường được đọc là LF nên tính 1 byte.
- Nếu con số lớn hơn mức bạn ước tính theo bảng ở trên, có thể văn bản đang ở dạng tổ hợp. Bạn có thể chuẩn hóa về NFC rồi đo lại nếu dữ liệu thật cũng được lưu ở dạng này.
Khi cần kiểm tra một đoạn mô tả, một trường dữ liệu hay nội dung gửi qua API trước khi lưu, bạn có thể đo kích thước văn bản theo byte ngay trên trình duyệt rồi so sánh với giới hạn của hệ thống mình dùng.
