Đếm ký tự & đếm từ

Về Công Cụ Đếm Ký Tự

Đếm ký tự nghe đơn giản — nhưng câu hỏi "chuỗi này có bao nhiêu ký tự?" có tới bốn câu trả lời hợp lệ tuỳ vào tầng bạn hỏi: byte (octet UTF-8, đơn vị mà lưu trữ đám mây tính tiền), code unit (mảnh UTF-16, giá trị mà str.length trả về trong JavaScript và giới hạn của NVARCHAR trong SQL Server), codepoint (ký tự Unicode, giá trị mà iterator chuỗi trả về trong Python 3 và JS hiện đại), hoặc grapheme cluster (cái mà mắt người coi là một ký tự). Bốn tầng có thể chênh nhau rất lớn — emoji gia đình 👨‍👩‍👧‍👦 là 1 grapheme nhưng 7 codepoint, 11 code unit UTF-16 và 25 byte UTF-8. Công cụ này báo số grapheme, nên kết quả khớp với những gì bạn thấy trên màn hình, và tách riêng phần đếm từ, dòng, đoạn và câu bằng cách phát hiện biên ngữ pháp Unicode (UAX #29). Vì giới hạn mỗi nền tảng phụ thuộc vào tầng — Twitter/X tính ký tự Hán-Hàn-Nhật là 2, SMS GSM-7 nhồi 160 ký tự ASCII vào 140 byte nhưng tụt xuống 70 ngay khi có một emoji (chuyển sang UCS-2), tiêu đề SEO của Google tính theo điểm ảnh (~580 px) chứ không phải ký tự, và tokenizer của các LLM trung bình ~4 ký tự một token cho tiếng Anh nhưng tiếng Việt có dấu chỉ 1-2 — hãy dùng máy này để soạn nháp rồi kiểm tra lại bằng bộ đếm chính thức của nền tảng trước khi đăng. Đếm chạy cục bộ với debounce 300 ms; không có dữ liệu nào được tải lên. Xem thêm Chuyển đổi chữ hoa thường và Tạo văn bản giả lập của chúng tôi.

Tại sao số ký tự khác nhau giữa công cụ này, Microsoft Word và Twitter?

Các nền tảng khác nhau đếm ký tự bằng quy tắc khác nhau. Công cụ này đếm mọi codepoint Unicode, coi mỗi glyph nhìn thấy là một đơn vị. "Characters" của Microsoft Word báo cáo hai số — có và không có khoảng trắng — và có thể loại trừ chú thích cuối trang theo mặc định. Twitter/X phức tạp nhất: đếm URL là 23 ký tự bất kể độ dài thực (gói link), đếm hầu hết emoji là 2 ký tự, coi các dãy Hán/Hangul/Hiragana là 2 ký tự mỗi, và áp dụng công thức có trọng số trong API xuất bản. Để giữ an toàn dưới giới hạn nền tảng, luôn đếm bằng bộ đếm chính thức của mỗi nền tảng cho xác thực cuối; công cụ này dành cho dự thảo chung và bảo thủ.

Emoji, chữ có dấu và ký tự kết hợp được đếm thế nào?

Đếm ký tự ngây thơ có thể cho kết quả bất ngờ vì mô hình Unicode bên dưới phức tạp hơn "một ký tự = một đếm." Một emoji đơn giản như 😀 là một codepoint và một ký tự cảm nhận — thẳng thắn. Nhưng emoji gia đình 👨‍👩‍👧‍👦 về kỹ thuật là bốn codepoint emoji nối bởi ba zero-width joiner — bảy codepoint, một glyph nhìn thấy. Chữ có dấu có thể là một codepoint dựng sẵn (ế, NFC) hoặc nhiều cái kết hợp (e + ̂ + ́, NFD) — đặc biệt quan trọng với tiếng Việt vì có nhiều dấu chồng. Công cụ này đếm ký tự cảm nhận (cụm grapheme) khi có thể, nên 👨‍👩‍👧‍👦 đọc là 1. Thuộc tính str.length của JavaScript vẫn trả về số codepoint — các công cụ khác nhau có thể không đồng ý do thiết kế.

Số ký tự tối ưu cho thẻ title SEO và meta description năm 2026 là bao nhiêu?

SERP của Google hiển thị title trong khoảng 580 pixel và description trong khoảng 920 pixel chiều rộng, không phải số ký tự cố định — chữ rộng (W, M) chiếm nhiều chỗ hơn chữ hẹp (i, l). Là proxy thực tế, nhắm: title 50-60 ký tự (di động cắt sớm hơn ở 50), description 120-160 ký tự (di động hiển thị ~120, desktop ~160). Tiếng Việt có dấu chiếm nhiều pixel hơn nên nên ngắn hơn 5-10 ký tự. Google không phạt văn bản dài hơn; chỉ cắt với dấu ba chấm, có thể hại CTR. Đặt các từ quan trọng nhất ở đầu. Với nền tảng khác: title Open Graph 60-90, description ~200; thẻ Twitter 70/200; chia sẻ LinkedIn 150 title, 250 description.

WCAG 2.2 nói gì về số ký tự lý tưởng mỗi dòng cho khả năng tiếp cận?

Tiêu chí Thành công 1.4.8 của WCAG 2.2 (Trình bày Trực quan, Mức AAA) khuyến nghị độ dài dòng tối đa 80 ký tự (40 cho tiếng Trung, Nhật và Hàn). Nghiên cứu từ các khảo cứu typography hội tụ ở 50-75 ký tự mỗi dòng là tối ưu cho tốc độ đọc và hiểu — dòng ngắn hơn (dưới 40) buộc quá nhiều bước nhảy mắt; dòng dài hơn (trên 90) khiến độc giả mất vị trí khi quay lại bắt đầu dòng mới. Với văn bản thân trên web, đặt CSS max-width khoảng 65ch (đơn vị ch bằng chiều rộng của ký tự 0). Tiếng Việt với dấu phụ tăng chiều cao dòng nhưng không thay đổi đáng kể đề xuất này. Công cụ này đếm tổng ký tự trong toàn văn bản, không theo dòng — để kiểm tra số mỗi dòng, tách theo dấu xuống dòng.

Các phân đoạn SMS hoạt động thế nào và tại sao một emoji chia văn bản của tôi thành nhiều tin nhắn?

SMS dùng hai mã hóa. GSM-7 (mặc định) gói 160 ký tự vào một SMS 140 byte dùng ký tự 7 bit — hoạt động cho ASCII cộng một số dấu cơ bản. Tiếng Việt có dấu thanh nằm ngoài GSM-7, nên hầu hết SMS tiếng Việt tự động chuyển sang UCS-2 (Unicode), giảm dung lượng còn 70 ký tự mỗi phân đoạn. Đây là lý do SMS marketing tiếng Việt thường tách thành 3-4 phân đoạn cho cùng độ dài mà tiếng Anh chỉ cần 1. SMS đa phân đoạn dùng 153 (GSM) hoặc 67 (UCS-2) mỗi phân đoạn vì header định tuyến chiếm phần còn lại. Twilio và các gateway khác tính phí theo phân đoạn, không theo ký tự. Bỏ dấu thanh (chuyển sang tiếng Việt không dấu) là cách rẻ tiền nhất cho SMS hàng loạt nhưng giảm dễ đọc.

Sự khác biệt giữa byte, codepoint, đơn vị mã và cụm grapheme là gì?

Bốn lớp này là nguồn của hầu hết nhầm lẫn về đếm ký tự. Byte: octet thô trong tệp mã hóa (UTF-8 dùng 1-4 byte mỗi codepoint; tiếng Việt thường 2-3 byte mỗi ký tự). Đơn vị mã: khối 16 bit trong UTF-16 (chuỗi JavaScript và Java, API Windows) — emoji trên U+FFFF dùng 2 đơn vị mã. Codepoint: ký tự Unicode thực (U+1F600 cho 😀) — bộ lặp chuỗi trong ngôn ngữ hiện đại trả về codepoint. Cụm grapheme: cái con người cảm nhận là một ký tự — 👨‍👩‍👧‍👦 là 1 grapheme nhưng 7 codepoint, 14 đơn vị mã UTF-16, 25 byte UTF-8. Công cụ này báo cáo số grapheme cảm nhận bởi người dùng. Khi làm việc với API tính phí theo byte (lưu trữ cloud), hoặc giới hạn theo đơn vị mã (SQL VARCHAR), chọn lớp đúng cho trường hợp dùng.

Làm sao ước tính thời gian đọc từ số ký tự hoặc số từ cho bài blog?

Tốc độ đọc thầm trung bình của người lớn tiếng Việt là 180-220 từ mỗi phút (WPM); đọc to chậm hơn ở 130-150 WPM. Nội dung kỹ thuật làm chậm độc giả xuống 60-100 WPM. Để ước tính thời gian đọc: chia số từ cho 200 (mặc định Medium cho tiếng Việt thấp hơn tiếng Anh) và làm tròn lên. Cho các ngôn ngữ khác: tiếng Anh 238, tiếng Tây Ban Nha 220, tiếng Pháp 195, tiếng Bồ Đào Nha 215 — ngôn ngữ châu Á không có khoảng trắng thường đo bằng ký tự mỗi phút thay vì từ (tiếng Trung ~300 cpm). Ước tính theo ký tự hữu ích khi ranh giới từ không rõ: chia tổng ký tự (có khoảng trắng) cho 1.200 để được phút cho tiếng Việt. Bộ đếm này hiển thị từ và ký tự; nhân hoặc chia để tính thời gian đọc.

Số token LLM liên quan thế nào đến số ký tự để ước tính chi phí prompt?

Mô hình ngôn ngữ lớn (GPT, Claude, Llama, Gemini) tính phí theo token, không theo ký tự. Quy tắc thô cho tiếng Anh, 1 token ≈ 4 ký tự ≈ 0,75 từ. Vậy một đoạn 1.000 ký tự khoảng 250 token. Nhưng tỷ lệ này biến thiên dữ dội: mã dùng ít ký tự hơn mỗi token (~3) vì cú pháp dày đặc; không phải tiếng Anh dùng nhiều ký tự hơn mỗi token vì tokenizer BPE được huấn luyện chủ yếu trên tiếng Anh. Tiếng Việt có thể đạt 1,5-2 token mỗi ký tự do mã hóa dấu thanh đa byte — nghĩa là prompt tiếng Việt 1.000 ký tự có thể là 1.500-2.000 token, gấp 6 lần tiếng Anh cùng độ dài. Tiếng Nhật và Trung thậm chí kém hiệu quả hơn. Để ngân sách chi phí API chính xác, dùng tokenizer chính thức của mô hình (tiktoken cho OpenAI, anthropic-tokenizer cho Claude). Bộ đếm ký tự này cho ước tính nhanh đầu tiên: chia ký tự cho 0,6 cho prompt tiếng Việt.

Ví dụ Kết quả