ทำไมตัวอักษรไทยบนเว็บหรือ e-reader ถึงตัดอักษรผิด

บทความแรกของบล็อกนี้เขียนเป็นภาษาไทย จนกระทั่งมีคนทักมาว่า “อ่านบนมือถือแล้วตัวอักษรมันขาดๆ” ผมถึงได้รู้ว่าเว็บของตัวเองมีปัญหาการตัดคำภาษาไทยที่ไม่เคยสังเกตมาก่อน บทความนี้คือบันทึกการแก้ไขทั้งหมด ตั้งแต่จุดที่คิดผิดในตอนแรก ไปจนถึงคำตอบจริง และสิ่งที่เรียนรู้ระหว่างทางว่าเป็นเรื่องใหญ่กว่าที่คิดไว้มาก ทั้งเรื่อง Thai word tokenizer หลายตัวที่ไม่เห็นตรงกันด้วยซ้ำว่า “คำ” คืออะไร ไปจนถึงว่าภาษาอื่นที่เป็นระบบ Abugida (อักษรสระประกอบ; ระบบการเขียนรูปแบบหนึ่งที่พยัญชนะแต่ละตัวจะมีสระติดมาด้วย) และ Scriptio Continua (ระบบการเขียนที่ไม่มีการเว้นวรรค) เช่น ภาษาลาว, ภาษาเขมร, ภาษาพม่า, ภาษาทิเบต เป็นต้น แก้ปัญหานี้กันอย่างไรบ้าง

(Click the language switcher (globe icon) at the top of this post to read the Thai version)

อาการ: ตัวอักษรที่ “โดนตัด” ไปกลางคำ

เรื่องเกิดจากมีผู้อ่านส่ง screenshot มาสองภาพ ภาพแรกจาก LINE in-app browser บนมือถือ ส่วนภาพที่สองคือบทความที่ export จาก Safari mobile เป็น PDF ทั้งสองภาพแสดงย่อหน้าเปิดของบทความหนึ่ง และคำว่า “เตรียม” ถูกตัดกลางคำจนเหลือ “เ” ตัวเดียวลอยอยู่ท้ายบรรทัด แล้วส่วนที่เหลือ “ตรียม” ก็ไปขึ้นบรรทัดใหม่

ปัญหาที่เจอ

ทั้งสอง screenshot มาจากมือถือ แต่ บนคอมพิวเตอร์ของผมเอง เปิดหน้าเดียวกันใน Chrome แล้วไม่เจอปัญหานี้เลย ข้อความถูกตัดสวยงามปกติทุกอย่าง

นี่คือจุดเริ่มต้นของการหาคำตอบทั้งหมด: ทำไมหน้าเดียวกัน เนื้อหาเดียวกัน ถึง render ต่างกันขนาดนี้ระหว่างเครื่อง

สมมติฐานแรก (ที่ผิด)

“WebKit ไม่รองรับการตัดคำภาษาไทย”

สมมติฐานแรกที่ดูสมเหตุสมผลที่สุดคือ Safari/WebKit (ซึ่ง LINE ใน iOS ก็ใช้ WebKit เป็น engine ข้างในผ่าน WKWebView) ไม่มีระบบตัดคำภาษาไทยแบบ dictionary-based เหมือนที่ Chrome มี เพราะ Chrome ฝัง ICU (International Components for Unicode) ที่มี Thai dictionary segmentation มาให้เต็มรูปแบบ

แต่สมมติฐานนี้ผิดทันทีเมื่อผมลองเทียบกับเว็บข่าว BBC Thai ด้วย engine WebKit จริงๆ (ผ่าน Playwright) แล้วพบว่า ข้อความภาษาไทยของ BBC wrap ได้ปกติดี ไม่มีปัญหาเลย ทั้งที่ BBC ไม่ได้ตั้งค่า CSS พิเศษอะไรสำหรับภาษาไทยเลยด้วยซ้ำ

ผมเลยลองทำการ Controlled test โดยสร้างหน้า HTML เปล่าๆ ใส่ย่อหน้าภาษาไทยเดียวกัน 5 ชุด แต่ละชุดใช้ CSS word-break/overflow-wrap คนละแบบ แล้ว render ทั้ง 5 ชุดด้วย WebKit ตัวเดียวกัน เทียบกัน:

CSS ที่ใช้	ผลลัพธ์ใน WebKit
ไม่ตั้งค่าอะไรเลย (browser default)	wrap ถูก ไม่มีคำขาด
`overflow-wrap: break-word` อย่างเดียว	wrap ถูก
`word-break: break-word` (legacy)	wrap ถูก
`word-break: normal; overflow-wrap: normal;`	wrap ถูก
`word-break: keep-all` + `overflow-wrap: break-word` (ค่าที่เว็บผมใช้อยู่ ณ ตอนนั้น)	มีคำขาดกลางคำ

สาเหตุที่แท้จริง

มันคือ Bug ที่ผมสร้างเอง

เว็บผมเคยตั้ง CSS เพื่อพยายามแก้ปัญหาอักษรไทยนี้มาก่อนในอดีต แต่กลายเป็นทำให้ปัญหาแย่ลงกว่าค่า default ของ browser อีก

/* ก่อนแก้ */
.markdown-body[lang="th"] {
  line-height: 1.8;
  word-break: keep-all;
  overflow-wrap: break-word;
}

word-break: keep-all ถูกออกแบบมาสำหรับตัวอักษรแบบจีน/ญี่ปุ่น/เกาหลี (CJK) เป็นหลัก เพื่อบอกว่า “อย่าตัดคำกลาง sequence ของตัวอักษร CJK” แต่เมื่อใช้กับภาษาไทยใน WebKit กลับกลายเป็นว่า WebKit หาจุดตัดคำ (break opportunity) ที่ถูกต้องไม่เจอเลยสักจุดในข้อความไทยที่ไม่มีช่องว่าง (เพราะ keep-all ไปปิดกลไกการหา word boundary ตามปกติ) สุดท้ายเลยต้องพึ่ง overflow-wrap: break-word ซึ่งเป็นกลไก fallback ที่ตัดตรงไหนก็ได้ที่ทำให้บรรทัดไม่ล้นขอบจอ ผลคือตัดกลางพยางค์แบบสุ่มๆ ตามที่เห็นใน screenshot

ตัวอย่างจริงจากบทความอื่นบนเว็บนี้ ก่อนแก้บั๊ก

อีกตัวอย่างจากย่อหน้าเปิดของบทความเดียวกัน คำภาษาไทยถูกตัดกลางคำตั้งแต่บรรทัดแรก ย่อหน้าเปิดของบทความเดียวกัน คำถูกตัดกลางคำตั้งแต่บรรทัดแรก

ทางแก้คือลบบรรทัดเดียว:

  .markdown-body[lang="th"] {
    line-height: 1.8;
-   word-break: keep-all;
    overflow-wrap: break-word;
  }

ยืนยันผลด้วย WebKit จริงอีกครั้ง คำที่เคยขาด (เตรียม → เ + ตรียม) กลับมาเป็นคำเดียวปกติ และ Chrome ก็ยังคง render ถูกต้องเหมือนเดิม ไม่มี regression

แต่ปัญหาที่เหลืออยู่: คำจริงที่ dictionary ของ browser เองก็ยังตัดผิด

หลังแก้ CSS แล้วปัญหาส่วนใหญ่หายไป แต่ยังมีคำที่เหลือ ลองเอาบทความจริงบทความหนึ่งที่มีความยาว 35,436 ตัวอักษร (เนื้อหา 38 นาทีอ่าน) มาวิเคราะห์ พบว่า จาก 934 คำที่ไม่ซ้ำกัน มี 70 คำที่ browser’s native segmenter (Intl.Segmenter) ยังตัดผิดตำแหน่งอยู่ ตัวอย่างที่เจอบ่อยและกระทบการอ่านจริงๆ ในบทความประเภทเกี่ยวกับวีซ่า/ทุนการศึกษา:

ตัวเอง คำสรรพนามที่ใช้บ่อยมาก ถูกตัดเป็น ตัว + เอง
ขั้นตอน คำที่ใช้ทุกหัวข้อ ถูกตัดเป็น ขั้น + ตอน
เจ้าหน้าที่, สถานทูต, พาสปอร์ต, ต้นสังกัด, เร่งด่วน, ใบเสร็จ, สถานกงสุล คำที่ปรากฏซ้ำๆ ตลอดทั้งบทความ รวมแล้วเจอจุดที่ตัดผิด 253 ครั้ง

ทำให้ผมเปลี่ยนคำถามจาก “แก้ CSS ก็จบ” เป็น “ต้องมีวิธีหาคำที่ dictionary ของ browser ตัดผิด อย่างเป็นระบบ”

ไปหา “ความจริง” จาก Thai word tokenizer

วิธีคือ: หา tokenizer ตัวอื่นที่แม่นยำกว่ามาเป็น “ground truth” แล้ว diff ผลลัพธ์กับ Intl.Segmenter ของ browser ดูว่าตรงไหนไม่ตรงกัน ผมลองมาหลายตัว:

Tokenizer	แนวทาง	รันบน browser ได้ไหม	ขนาด dictionary	ความเร็ว (บทความเดิม)
`Intl.Segmenter` (built-in)	ICU dictionary	ได้ ฟรี ไม่ต้องโหลดอะไรเพิ่ม	0	~11-13ms
`wordcut`	Lexitron/NECTEC dictionary	ไม่ได้ เพราะใช้ `fs`/`glob` ของ Node ข้างในตรงๆ	105KB (gzip)	~61-76ms
`nlpo3-newmm-typescript`	อัลกอริทึม NewMM เดียวกับ PyThaiNLP เขียนใหม่เป็น TypeScript ล้วน	ได้ ไม่มี dependency เลย	314KB (gzip)	~12-13ms (เร็วกว่า wordcut ~5 เท่า)
PyThaiNLP เอง (`attacut`/`deepcut`)	Deep learning (CNN)	ไม่ได้ เพราะรองรับแค่ Python + PyTorch/TensorFlow เท่านั้น	-	-
ICU เต็มรูปแบบผ่าน WASM	ICU ทั้งก้อน	ได้ทางเทคนิค แต่…	12.8MB (gzip)	ตัดออกจากการพิจารณาทันที

เมื่อทดลองใช้ wordcut ตัดคำว่า “สหรัฐฯ” (สหรัฐอเมริกา แบบย่อ) พบปัญหาตัดคำผิดซ้ำๆ ทุกครั้งที่เจอเครื่องหมาย ฯ ส่วน nlpo3-newmm-typescript จัดการกรณีนี้ได้ถูกต้อง และเร็วกว่าด้วย แต่มีเรื่องสำคัญคือ README บน repo บอกไว้ว่า “Project VibeCode use deepseek 4 Pro” เป็นโค้ดที่สร้างจาก AI คนเดียว เพิ่ง publish มาแค่ 4 สัปดาห์ (ณ ขณะที่เขียนบทความนี้) ยังไม่มี track record อะไรเลย

สิ่งที่พบระหว่างทาง

พอลอง benchmark wordcut เต็มรูปแบบ (ไม่ใช่แค่ dictionary) พบว่า init (โหลด dictionary + สร้าง prefix tree) ใช้เวลา ~88ms และแยกออกมาชัดว่า ~71ms ในนั้นเป็น CPU ล้วนๆ ไม่ใช่การอ่านไฟล์ แปลว่าต่อให้ dictionary ถูกฝังมาพร้อม bundle แล้ว (ไม่ต้องโหลดผ่าน network) ต้นทุนตรงนี้ก็ยังหนีไม่พ้น บวกกับเวลาตัดคำบทความจริงอีก ~61-76ms รวมแล้วบนคอมพิวเตอร์จริงของมือถือรุ่นทั่วไป (ซึ่งช้ากว่าเครื่อง dev 2-4 เท่า) น่าจะขึ้นไปถึง 300-500ms ของการบล็อก main thread จนรู้สึกได้จริงว่าหน้าเว็บกระตุก

สิ่งที่คาดไม่ถึง: เปลี่ยน ground truth แล้วคำตอบเปลี่ยนไป 6 เท่า

ลองเอา nlpo3-newmm-typescript มาเป็น ground truth แทน wordcut คาดว่าน่าจะได้ผลใกล้เคียงกันหรือดีกว่า แต่กลับได้ผลลัพธ์ 431 คำที่ “ตัดผิด” แทนที่จะเป็น 70 มากกว่าเดิมถึง 6 เท่า

พอไล่ดูรายการจริงถึงเข้าใจว่าทำไม: คำอย่าง เพื่อให้ (in order to), ไม่ต้อง (don’t need to), อยู่แล้ว (already) ถูก dictionary ของ nlpo3-newmm-typescript นับเป็น “คำเดียว” ทั้งที่จริงๆ มันคือคำสองคำธรรมดาที่ต่อกันตามหลักไวยากรณ์ ผู้อ่านทั่วไปไม่รู้สึกแปลกอะไรเลยถ้าเห็นคำพวกนี้ถูกตัดขึ้นบรรทัดใหม่ (เหมือนคนอ่านภาษาอังกฤษไม่รู้สึกแปลกถ้า “in order to” ถูกตัดกลางวลี) นี่ไม่ใช่ปัญหาแบบเดียวกับ “ตัวเอง” ที่ตัดแล้วดูแปลกตาเพราะเป็นหน่วยคำที่แนบแน่นในการอ่านจริง

ข้อสรุปที่สำคัญที่สุดของบทความนี้

Tokenizer แต่ละตัวไม่ได้แค่ “แม่นยำมากน้อยต่างกัน” แต่มันนิยาม “คำ” ไม่เหมือนกันเลยตั้งแต่ต้น เพราะภาษาไทยไม่มีเครื่องหมายแบ่งคำในตัวอักษรเอง งานนี้จึงเป็นปัญหาที่ไม่มีคำตอบถูกผิดตายตัวแบบ binary Tool ที่ออกแบบมาเพื่องาน NLP (ค้นหา, POS tagging) จะจงใจรวมกลุ่มคำที่ใช้ร่วมกันบ่อยๆ ให้เป็น token เดียว ซึ่งเป็นคนละเป้าหมายกับ “ตัดบรรทัดให้อ่านง่าย” ถ้าเอา ground truth จากเครื่องมือผิดประเภทมาใช้ อาจทำให้ปัญหาแย่ลงกว่าเดิมได้

แล้ว “e-reader” จัดการเรื่องนี้ยังไง?

คำถามต่อมาคือ: มีใครแก้ปัญหานี้ได้ดีแล้วบ้างไหม เลยไปสำรวจว่า e-reader ตัวจริงๆ ที่คนใช้อ่านหนังสือกันอยู่ทุกวันนี้ทำยังไง สรุปคือยังไม่มีคำตอบ โดย

KOReader (ซอฟต์แวร์ e-reader โอเพนซอร์สที่ใช้งานจริงบน Kindle/Kobo hardware ที่ jailbreak แล้ว) เจอปัญหาตัดคำไทยกลางคำเหมือนกันเป๊ะ มี issue #11701 รายงานเรื่องนี้ไว้ตรงๆ สาเหตุคือ KOReader ใช้ libunibreak (ไลบรารีขนาดเล็ก) ซึ่งไม่มีข้อมูล dictionary สำหรับภาษากลุ่มเอเชียตะวันออกเฉียงใต้เลย ทีมพัฒนาคุยกันถึงทางแก้ 4 แบบ (เปลี่ยนไปใช้ ICU4C เต็มรูปแบบ, ใช้ libthai ที่เบากว่า, แทรก zero-width space ด้วยตัวเอง, หรือเพิ่ม neural network เข้าไปใน libunibreak) สุดท้าย ปิด issue เป็น “not planned” เหตุผลหลักคือ ICU เต็มรูปแบบทำให้ตัว executable ใหญ่ขึ้นมากเกินไปสำหรับ e-reader ที่เน้นความเบา เหมือนกับ trade-off ขนาด/คุณภาพที่ผมเจอเองตอน test ICU-WASM (12.8MB)

Kindle ของ Amazon เอง แย่กว่าเดิมอีก มีรายงานว่าวรรณยุกต์/สระบนตัวอักษรไทยแสดงผลคลาดเคลื่อนหรือหายไปเลยบน Kindle Paperwhite ซึ่งเป็นปัญหาระดับพื้นฐานกว่าเรื่องตัดคำเสียอีก (คือ render ตัวอักษรผิดตั้งแต่ต้น ไม่ใช่แค่ตัดบรรทัดผิดที่)

แม้แต่ browser engine ที่ดีที่สุดในบรรดาที่เทสต์มา (Chromium) ก็ยังมี bug ภาษาไทยที่ W3C ยืนยันแล้วว่ายังไม่มีใครแก้ โดย Thai Gap Analysis ของ W3C ระบุชัดว่า Gecko, Blink, และ WebKit ทั้งสามตัวพัง เรื่อง “Maiyamok wrapping” คือกฎที่ว่าเครื่องหมาย ๆ (ไม้ยมก, ๆ, U+0E46) ห้ามขึ้นต้นบรรทัดเด็ดขาด เพราะมันไม่มีความหมายอะไรเลยถ้าไม่มีคำก่อนหน้า และยังไม่มี engine ไหนแก้ปัญหานี้ได้ถูกต้อง

แล้วภาษาอื่นที่ “ไม่มีช่องว่างระหว่างคำ” เหมือนไทยล่ะ?

ขยายการสำรวจออกไปอีกขั้น ภาษา/ตัวอักษรที่เขียนติดกันไม่มีช่องว่าง (scriptio continua) ไม่ได้มีแค่ไทย และที่น่าสนใจคือ ไม่ใช่ทุกภาษาที่เขียนติดกันจะเจอปัญหาแบบเดียวกัน

กลุ่มที่เจอปัญหาเหมือนไทยเป๊ะ: ภาษาลาว, ภาษาเขมร, ภาษาพม่า ภาษาเหล่านี้เป็นทั้ง abugida (พยัญชนะมีสระในตัว ต้องเติมเครื่องหมายเพื่อเปลี่ยนเสียงสระ) และเขียนติดกันไม่มีช่องว่าง ทำให้ตัดพยางค์ผิดตำแหน่งก็อ่านไม่รู้เรื่องเหมือนไทย ที่น่าตกใจคือปัญหานี้ยังไม่ถูกนิยามชัดเจนด้วยซ้ำ โดย open issue ของ W3C เรื่อง ภาษาเขมร และ open issue ของ W3C เรื่อง ภาษาลาว ยังถามอยู่เลยว่า “ควรตัดตรงพยางค์ได้เลย หรือต้องตัดตรงคำเท่านั้น” ซึ่งยังไม่มีคำตอบที่ยืนยันแน่ชัด

ภาษาพม่า มีปัญหาซ้อนปัญหา ก่อนจะพูดถึงเรื่องตัดคำได้ด้วยซ้ำ พม่าผ่านการที่ต้องเลือก encoding ระหว่าง Zawgyi กับ Unicode มาก่อน สองระบบใช้ code point ช่วงเดียวกัน (U+1000–U+109F) ทำให้ font ตัวเดียวไม่สามารถ render ถูกทั้งคู่ได้ ข้อความชุดเดียวกันอาจอ่านได้ถูกด้วย font หนึ่งแต่กลายเป็นตัวอักษรอื่นเมื่อใช้กับอีก font เทียบแล้วปัญหาของไทยดูเบาไปเลยเมื่อเทียบกัน

จุดที่ผิดคาดที่สุด: ภาษาทิเบต แก้ปัญหานี้ไปแล้วตั้งแต่ระดับตัวอักษรเอง ไม่ใช่ระดับซอฟต์แวร์ ภาษาทิเบตมีเครื่องหมาย tsheg (་, U+0F0B) ที่คนเขียนใส่ต่อท้ายทุกพยางค์เป็นเรื่องปกติของการเขียนอยู่แล้ว (ไม่ใช่สิ่งที่เพิ่งเสริมเข้ามาทีหลัง) ทำให้ซอฟต์แวร์ตัดบรรทัดได้ทันทีตรงเครื่องหมายนี้โดยไม่ต้องใช้ dictionary หรือ NLP อะไรเลย และที่น่าตื่นเต้นกว่านั้นคือ Unicode ยังมีอักขระคู่แฝดสำหรับกรณีที่ ไม่ควร ตัดตรงนั้น คือ “non-breaking tsheg” (U+0F0C) ซึ่งเป็น concept เดียวกับ ZWSP กับ WORD JOINER ที่ผมลองใช้แก้ปัญหาไทยเลย เพียงแต่ทิเบตฝังมันไว้ในตัวอักษรมาแต่ต้นตั้งแต่ก่อนมีคอมพิวเตอร์ด้วยซ้ำ

ส่วนจีน/ญี่ปุ่น (CJK) หลีกเลี่ยงปัญหานี้ไปได้เลยทั้งกระบวน เพราะตัวอักษรแต่ละตัวอ่านเป็นหน่วยที่มีความหมายสมบูรณ์ในตัวเองอยู่แล้ว การตัดบรรทัดระหว่างตัวอักษรใดๆ ก็ตาม (ยกเว้นกฎเรื่องเครื่องหมายวรรคตอนบางตัว เช่น ห้ามขึ้นต้นบรรทัดด้วยเครื่องหมายปิดวงเล็บ) จึงไม่ทำให้อ่านไม่รู้เรื่อง กฎชุดนี้เรียกว่า kinsoku shori (禁則処理) มาตรฐาน JIS X 4051 ของญี่ปุ่น ซึ่งแก้เสร็จเรียบร้อยมาหลายสิบปีแล้ว เพราะเป็นปัญหาคนละระดับกับไทยตั้งแต่ต้น ไม่ใช่แค่ “ยากน้อยกว่า” แต่เป็น “ปัญหาคนละแบบ”

สิ่งที่เว็บนี้ใช้งานจริงตอนนี้

ลบ word-break: keep-all ออกจาก CSS แก้ปัญหาหลักได้เกือบทั้งหมด ต้นทุนศูนย์ นี่คือสิ่งเดียวที่ใช้จริงกับทุกหน้าของเว็บนี้ รวมถึงบทความที่กำลังอ่านอยู่ตอนนี้ด้วย
รายการคำ 70 คำที่ browser ยังตัดผิด เก็บไว้ที่ src/data/thai-word-joins.json สร้างขึ้นโดยใช้ nlpo3-newmm-typescript เป็นตัวช่วยหา candidate (เร็วกว่า wordcut และไม่มีบั๊ก สหรัฐฯ) diff กับ Intl.Segmenter แล้วกรองด้วยมือทุกคำ ตัดคำวลีธรรมดาแบบ “เพื่อให้” ออก เก็บเฉพาะคำที่เป็นหน่วยแนบแน่นจริงๆ แบบ “ตัวเอง” รายการนี้ถูกใช้ใน demo แบบโต้ตอบด้านล่าง ไม่ได้ถูกใช้กับหน้าเว็บจริงของเว็บนี้
มีสคริปต์ที่นำรายการนี้ไปใช้กับเนื้อหาจริงได้: scripts/apply-thai-word-joins.mjs ห่อแต่ละคำในรายการ (บวกไม้ยมก ๆ ทุกจุด) ด้วย white-space:nowrap span ลงใน HTML ที่ build เสร็จแล้วโดยตรง ข้ามส่วนที่เป็นโค้ด ลิงก์ และหัวข้อโดยอัตโนมัติ (เพื่อไม่ให้กระทบ anchor id) สคริปต์นี้มีอยู่จริงและทำงานได้จริง ลองใช้กับบทความนี้เองได้ผลตรงกับตัวเลขที่ประมาณไว้ คือ 253 จุดที่จะถูกแก้ มี live demo ท้าบบทความนี้ให้ลอง
เลือกไม่ส่ง tokenizer หรือ dictionary ใดๆ ไปให้ผู้อ่าน เพราะ nlpo3-newmm-typescript และ cheerio อยู่ใน devDependencies หน้าเว็บที่ผู้อ่านได้รับตามปกติยังคงเป็น static HTML ธรรมดา แต่หากเปิดใช้งาน tokenizer จะถูกโหลดในฝั่ง client สามารถลอง live demo ได้ในท้ายบทความ

สิ่งที่ตัดสินใจไม่ทำ ก็สำคัญพอกัน คือไม่ฝัง tokenizer engine เต็มรูปแบบไว้ในเว็บ (ทำให้โหลดนานเกินไปเทียบกับสิ่งที่ได้) และ ไม่ทำย่อหน้า หรือ text justification เหมือนในหนังสือ

ลองเล่นเองได้เลย

ด้านล่างคือ interactive demo สามารถพิมพ์ข้อความของตัวเองแทนที่ข้อความตัวอย่างได้เลย แล้วสลับ tab ดูว่าข้อความเดียวกันหน้าตาเป็นยังไงในแต่ละขั้นของการแก้ปัญหา ข้อความตัวอย่างตั้งใจใส่คำจากรายการจริงหลายคำ (เจ้าหน้าที่, สถานทูต, พาสปอร์ต, ใบเสร็จ, ขั้นตอน, สถานกงสุล, เร่งด่วน, ตัวเอง, เตรียม, ตรวจสอบ, รายละเอียด, ผิดพลาด) และคำซ้ำแบบ “ๆ” (ไม้ยมก) หลายจุด เพื่อให้เห็นผลกับข้อความความยาวจริง ไม่ใช่แค่คำเดียวโดดๆ

3 วิธี แรก (ไม่มีขอบเขต / ค่าเริ่มต้นเบราว์เซอร์ / หลังใส่ word-joiner) ไม่โหลด tokenizer หรือ dictionary อะไรเลย ส่วนวิธีที่ 4 (“nlpo3-newmm-typescript เต็มรูปแบบ”) จะโหลด dictionary จริง ขนาด ~314KB เฉพาะตอนกดเลือก tab นั้นเท่านั้น

พิมพ์ข้อความของคุณเองตรงนี้ได้เลย: