เครื่องคำนวณความยาวของสตริง

ตัวอย่าง

ทำไมตัวเลขจึงแตกต่างกัน

สตริงใน JavaScript อยู่ในรูปแบบ UTF-16 ดังนั้นจุดรหัสที่สูงกว่า U+FFFF จะถูกจัดเก็บเป็นคู่แทน (surrogate pair) ซึ่งประกอบด้วยหน่วยรหัส UTF-16 สองตัว จึงทำให้ "😀".length === 2 ผู้ใช้มักไม่ชอบเรื่องนี้ เพราะพวกเขามองว่า 😀 เป็นตัวอักษรเพียงตัวเดียว

กราฟีมไปไกลกว่านั้นอีก ธงของประเทศประกอบด้วยจุดรหัสบ่งชี้ภูมิภาคสองจุด แต่ผู้ใช้มองเห็นเป็นธงเดียว เช่น "🇺🇸".length === 4 ใน JavaScript ซึ่งฟังดูไร้เหตุผล แต่ก็เป็นเช่นนั้นจริง หากต้องการวนซ้ำทีละกราฟีม ให้ใช้ Intl.Segmenter (แบบสมัยใหม่) หรือไลบรารี grapheme-splitter หรือจัดการเองด้วยมือ

ไบต์ UTF-8: สิ่งที่ฐานข้อมูลของคุณจัดเก็บ

สำหรับคอลัมน์ชนิด VARCHAR(255):

• ใน MySQL utf8 (จริง ๆ คือ utf8mb3) ค่า 255 หมายถึงจำนวนไบต์ ส่วน café ใช้ 5 ไบต์ จึงเก็บได้ 51 ชุด
• ใน MySQL utf8mb4 (UTF-8 จริงที่รวมอีโมจิ) ยังคงนับเป็นไบต์ แต่การเข้ารหัสรองรับลำดับยาว 4 ไบต์
• ใน Postgres VARCHAR(255) ค่า 255 หมายถึงจำนวนตัวอักษร (จุดรหัส) ไม่ใช่ไบต์
• ใน SQL Server VARCHAR ค่าจะต่างกันไปตามการเรียงลำดับ (collation) ส่วน NVARCHAR จะนับหน่วย UCS-2 ขนาด 2 ไบต์

หากคุณกำหนดขนาดฟิลด์ในฐานข้อมูลตามจำนวนตัวอักษรที่ผู้ใช้มองเห็น ให้ใช้ค่า “จำนวนไบต์ × 4” เพื่อความปลอดภัยในคอลัมน์ UTF-8 เพราะแต่ละกราฟีมอาจใช้พื้นที่ได้ถึง 4 ไบต์ต่อจุดรหัส และลำดับ ZWJ ยังเพิ่มขึ้นอีก

การนับตัวอักษรแบบ Twitter

Twitter นับทวีตตามกฎเฉพาะของตน คือนับเป็นจุดรหัส แต่อีโมจิและอักษรภาพ CJK จะนับเป็น 2 ทวีตที่เป็น ASCII ล้วนสามารถมีได้ถึง 280 ตัวอักษร ส่วนทวีตที่ใช้อีโมจิ 140 ตัวจะถึงเพดานที่ 140 “ตัวอักษร”

การนับ SMS: GSM 7 บิตได้ 160 ตัวอักษร หากมีตัวอักษรที่ไม่ใช่ GSM (เช่น á, é, ñ หรืออีโมจิ) แม้แต่ตัวเดียว การเข้ารหัสจะเปลี่ยนไปเป็น UCS-2 และความยาวข้อความจะลดลงเหลือ 70 ตัวอักษร

การใช้งานจริง

• การกำหนดขนาดคอลัมน์ในฐานข้อมูล, ตรวจสอบจำนวนไบต์ก่อนเขียนสคริปต์ย้ายฐานข้อมูล (migration)
• การบังคับใช้โควตา API, API ส่วนใหญ่นับเป็นไบต์ ไม่ใช่ตัวอักษร
• การตรวจสอบฟอร์ม, แสดงจำนวนตัวอักษรที่ถูกต้องตรงกับความคาดหวังของผู้ใช้ (กราฟีม)
• การดีบักประสิทธิภาพ, ทำไม regex นี้จึงวนซ้ำช้า? เพราะข้อมูลขาเข้ายาวกว่าในหน่วยรหัสถึง 3 เท่าเมื่อเทียบกับในหน่วยกราฟีม