Mojibake Fixer: แก้ปัญหาข้อความเพี้ยน UTF-8, TIS-620 และ Shift-JIS ในเบราว์เซอร์

ใครที่เคยเปิดไฟล์จากระบบเก่า ๆ คงเคยเจอฉากนี้: เปิดไฟล์ CSV จากโปรแกรมสำเร็จรูปยุคก่อนขึ้นมา แล้วช่องชื่อลูกค้าที่ควรจะเป็น "สวัสดี" กลับกลายเป็น สวัสà¸"ี หรือเปิดอีเมลสมัย 2000s แล้วเจอคำว่า é แทนที่จะเป็น é อาการแบบนี้เรียกว่า mojibake คือข้อความที่ถูกบันทึกด้วย encoding หนึ่ง แต่ถูกอ่านกลับด้วยอีก encoding หนึ่ง มันระบาดอยู่ในฐานข้อมูลเก่า, ไฟล์ export และระบบภาษาไทยรุ่นเก่าที่สร้างมาก่อนยุค UTF-8 ข่าวดีคือข้อความต้นฉบับมักยังซ่อนอยู่ข้างใน และ Mojibake Fixer สกัดมันกลับมาได้ในไม่กี่วินาที

สิ่งสำคัญที่ต้องเข้าใจก่อนคือ mojibake ส่วนใหญ่ไม่ใช่ข้อมูลเสียหายจริง ๆ byte ด้านหลังยังอยู่ครบ แค่ถูกตีความด้วยตัวถอดรหัส (decoder) ที่ผิดเท่านั้น เพราะความผิดพลาดแบบนี้เกิดขึ้นแบบแน่นอน (deterministic) จึงย้อนกลับได้: แค่ encode ข้อความที่เพี้ยนกลับเป็น charset ที่อ่านผิด แล้ว decode ด้วย charset ที่ถูกต้อง ซึ่งเป็นสิ่งที่เครื่องมือนี้ทำให้อัตโนมัติ รวมถึง TIS-620 ของไทยและ Shift-JIS ของญี่ปุ่น ซึ่งเป็นสอง encoding รุ่นเก่าที่สร้างปัญหาให้ข้อมูลจริงมากที่สุด

บทความนี้จะพาคุณไปดูว่าทำไมข้อความถึงกลายเป็นตัวอักษรประหลาด วิธีแก้ใน 5 ขั้นตอน และวิธีป้องกันไม่ให้ปัญหานี้กลับมาอีก

ทำไมต้องใช้ Mojibake Fixer

• ย้อนความเสียหายจริง ไม่ใช่แค่ปิดบัง — เครื่องมือแบบ "ทำความสะอาดอักขระ" มักลบหรือแทนที่สัญลักษณ์แปลก ๆ ทิ้งไปเฉย ๆ ทำให้ชื่อคนเสียหายโดยไม่รู้ตัว แต่เครื่องมือนี้ decode ลำดับ byte เดิมใหม่ ทำให้ สวัสà¸"ี กลับเป็น สวัสดี และ é กลับเป็น é ได้จริง
• ตรวจจับคู่ encoding อัตโนมัติ — วางข้อความเพี้ยนลงไปแล้วเครื่องมือจะให้คะแนนทุกคู่ encoding ที่รองรับ และชี้คู่ที่น่าจะเป็นสาเหตุของปัญหา
• รองรับ TIS-620 ของไทยโดยเฉพาะ — ระบบหน่วยงานราชการ ธนาคาร และ ERP ไทยนับพันระบบยังคงส่งออกข้อมูลเป็น TIS-620 ซึ่งเป็น 8-bit charset รุ่นเก่า ข้อความเพี้ยนจากระบบพวกนี้คืองานหลักของเครื่องมือนี้ ไม่ใช่ฟีเจอร์ตกท้าย
• รองรับ Shift-JIS ของญี่ปุ่น — mojibake แบบ ‚±‚ñ‚É‚¿‚Í จากไฟล์ญี่ปุ่นรุ่นเก่าก็กู้คืนได้เช่นกัน ครอบคลุมข้อมูลจาก supplier หรือ archive ญี่ปุ่นยุคเก่า
• ประมวลผล 100% ในเบราว์เซอร์ — ทุกการแปลงเกิดขึ้นบนเครื่องคุณเอง ข้อมูลลูกค้า ข้อมูลเงินเดือน และเอกสารภายในไม่เคยถูกส่งไปที่ server ใด ๆ
• ฟรี รวดเร็ว ไม่ต้องสมัคร — ไม่มีคิว ไม่มีข้อจำกัดขนาดไฟล์ วาง กด แล้ว copy

ฟีเจอร์เด่น

สองฟีเจอร์ที่ควรเน้นเป็นพิเศษคือ auto-detect ที่เปลี่ยนเครื่องมือจากปริศนาให้กลายเป็นทางออก — คุณไม่จำเป็นต้องรู้ว่า Latin-1 หรือ TIS-620 คืออะไรก็ได้คำตอบที่อ่านออก และการรองรับ Shift-JIS กับ TIS-620 ที่สำคัญกว่าที่ฟังดู เพราะ converter ทั่วไปมักรองรับแค่คู่ encoding ของยุโรปตะวันตก แล้วยอมแพ้กับ charset เอเชียรุ่นเก่าตั้งแต่ยังไม่ได้ลอง

วิธีใช้งาน

1. วางข้อความที่เพี้ยน — copy mojibake มาแบบตรง ๆ ทุกสัญลักษณ์แปลก ๆ คือเบาะแส อย่าแต่งข้อความหรือลบอะไรก่อน
2. ลองกด auto-detect — เครื่องมือจะวิเคราะห์รูปแบบ byte แล้วเสนอคู่ encoding ที่น่าจะก่อปัญหา ในกรณีส่วนใหญ่คำตอบแรกก็ใช่แล้ว
3. ไล่ลองคู่ encoding ถ้ายังไม่ถูก — ถ้าคำแนะนำยังไม่สมบูรณ์ ให้ไล่ผ่านคู่ที่รองรับ ได้แก่ UTF-8, Latin-1, Windows-1252, Shift-JIS และ TIS-620 พร้อมดูพรีวิวอัปเดตทีละแบบ
4. ตรวจสอบผลลัพธ์ — ดูว่าสระและวรรณยุกต์ไทยวางตัวถูกต้อง ตัว kana ญี่ปุ่นอ่านเป็นธรรมชาติ และอักษรละตินที่มีเครื่องหมายอย่าง é, ü, ñ ยังครบถ้วน
5. คัดลอกข้อความที่แก้แล้ว — คลิกเดียวได้ข้อความที่ซ่อมเสร็จบน clipboard พร้อมวางกลับเข้าระบบต้นทาง

ทำไมข้อความไทยถึงกลายเป็นตัวอักษรประหลาด

mojibake คือความผิดพลาดตอนถอดรหัส ไม่ใช่ข้อมูลที่พัง — คอมพิวเตอร์ไม่ได้เก็บ "ตัวอักษร" แต่เก็บ byte ล้วน ๆ encoding คือตารางแปลงที่ map byte กลับไปเป็นรูปอักษร เมื่อข้อความถูกเขียนด้วยตารางหนึ่งแต่ถูกอ่านด้วยอีกตารางหนึ่ง mojibake ก็เกิดขึ้น ตราบใดที่ byte ยังไม่ถูกเขียนทับ ความเสียหายก็ย้อนกลับได้เสมอ

ห่วงโซ่การ encode ซ้อนแบบคลาสสิก — mojibake ตะวันตกที่พบบ่อยที่สุดเริ่มจากข้อความ UTF-8 ที่มี é (byte C3 A9) ถูกอ่านเป็น Latin-1 ซึ่งเปลี่ยนสอง byte นั้นให้กลายเป็นอักษรสองตัวคือ é ถ้าข้อความที่อ่านผิดนี้ถูกบันทึกซ้ำเป็น UTF-8 อีกที ความเสียหายก็จะทบไปเรื่อย ๆ วิธีแก้คือเดินย้อนห่วงโซ่: encode ข้อความเพี้ยนเป็น Latin-1 เพื่อเรียก byte เดิม C3 A9 กลับมา แล้ว decode เป็น UTF-8

ข้อความเดิม:          café
byte แบบ UTF-8:       63 61 C3 A9
อ่านผิดเป็น Latin-1:   café          <- mojibake ที่คุณเห็น
encode กลับเป็น Latin-1: 63 61 C3 A9  <- ได้ byte เดิมคืน
decode เป็น UTF-8:     café           <- ความเสียหายถูกย้อน

ระบบไทยรุ่นเก่ากับ TIS-620 — วงการไอทีไทยใช้ TIS-620 (และลูกพี่ลูกน้องอย่าง Windows-874) มานานก่อน UTF-8 จะมาแพร่หลาย เมื่อข้อความไทย UTF-8 ถูกอ่านเป็น Latin-1 หรือ Windows-1252 คำว่า สวัสดี จะกลายเป็น สวัสà¸"ี — เป็นห่วงโซ่ encode ซ้อนแบบเดิม แค่สวมเสื้อผ้าไทย เพราะพยัญชนะไทยหนึ่งตัวถูกเก็บเป็น byte 3 ตัวใน UTF-8 แล้วแต่ละ byte ก็ถูกแสดงเป็นอักษรยุโรปหนึ่งตัว ทิศตรงข้ามก็เกิดได้เหมือนกัน: byte TIS-620 ของแท้ที่ถูกเปิดเป็น Latin-1 จะเปลี่ยนคำว่า กรุงเทพ ให้กลายเป็น ¡Ã¸§À·¾ เพราะทั้งสองทิศเกิดขึ้นจริงในข้อมูลจริง การลองคู่ encoding ได้ทั้งสองทิศจึงจำเป็นมาก

ภาษาญี่ปุ่นกับ Shift-JIS — ข้อมูลญี่ปุ่นรุ่นเก่ามักอยู่ในรูปแบบ Shift-JIS เมื่ออ่านด้วย decoder ที่ผิด คำว่า こんにちは จะกลายเป็น ‚±‚ñ‚É‚¿‚Í โรคเดิม ยาเดิม: encode กลับด้วยตัวที่อ่านผิด แล้ว decode ใหม่ด้วยตัวที่ถูก

auto-detect เดาอย่างไร — ตัวตรวจจับจะส่องหาลายเซ็นอันโด่งดังในข้อความเพี้ยน ลำดับอย่าง Ã, ภหรือ †คือลายนิ้วมือของข้อความ UTF-8 ที่ถูกอ่านเป็น single-byte charset ส่วนค่า byte ที่สมเหตุสมผลแค่ใน TIS-620 หรือ Shift-JIS ก็ชี้ไปทางตรงข้าม เครื่องมือให้คะแนนทุกคู่ที่รองรับแล้วดันคำตอบที่แข็งแรงที่สุดขึ้นมาเป็นคำเดาแรก ซึ่งคุณแทนที่เองได้เสมอ

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

ไฟล์ export จากฐานข้อมูลเก่า

ระบบยุค 1990s–2000s มักเก็บข้อมูลลูกค้าหลายสิบปีไว้เป็น Latin-1 หรือ TIS-620 เมื่องาน migration หรือรายงาน dump ข้อมูลออกมาพร้อม encoding ที่ประกาศผิด ทุกชื่อและที่อยู่จะมาเป็นตัวอักษรประหลาด ให้ลองแก้ตัวอย่างก่อน ยืนยันคู่ encoding แล้วค่อยแก้ทั้งไฟล์ก่อนนำเข้าฐานข้อมูล UTF-8 สมัยใหม่

ไฟล์ CSV จากระบบ ERP ไทยรุ่นเก่า

พอร์ทัลราชการไทยและโปรแกรม ERP ฝั่งผลิตภัณฑ์ยัง export CSV เป็น TIS-620 อยู่มาก พอเปิดใน spreadsheet ที่ตั้งเป็น UTF-8 คอลัมน์ภาษาไทยจะแตกเป็นตัวอักษรไร้ความหมาย วาง cell ที่เพี้ยนเข้าไปแก้ กู้คำว่า สวัสดี คืนมา แล้วคุณจะได้ทั้งข้อความที่ถูกต้องและความรู้ว่าไฟล์นี้ใช้ encoding อะไรกันแน่

อีเมลเก็บถาวร

อีเมลยุค 2000s บ่อยครั้งที่ header ระบุ charset หลุดหายระหว่างทาง ทำให้โปรแกรมอ่านเมลต้องเดาเอง การกู้เนื้อหาเธรดเก่าให้อ่านออกมักใช้การ decode ใหม่เพียงรอบเดียว มีประโยชน์ทั้งงาน compliance งาน legal discovery หรือแค่หาใบสั่งซื้อที่ลืมไปแล้ว

เว็บไซต์เก่าที่ scrape มา

หน้าเว็บที่ไม่ประกาศ charset บังคับให้เบราว์เซอร์และ scraper ต้องเดา ซึ่งเขาเดาผิดบ่อยกว่าที่คิด ถ้าการ crawl เว็บเก่าของคุณเก็บ mojibake มาไว้ในไฟล์ การ decode ใหม่จะคืนเนื้อหาต้นฉบับโดยไม่ต้อง crawl ซ้ำ

แนวปฏิบัติที่แนะนำ

• แก้ที่ต้นทาง ไม่ใช่แค่อาการ — ย้ายระบบไปใช้ UTF-8 ทุกจุดเพื่อให้ mojibake กลับมาไม่ได้ ดีกว่ามานั่งแก้ export เดิมทุกเดือน
• เก็บข้อความเพี้ยนต้นฉบับไว้ — ถือสำเนาไว้จนกว่าจะยืนยันว่าแก้สำเร็จ เพราะการ decode ใหม่ผิดทางสามารถทำลายข้อมูลได้หนักเท่ากับความผิดพลาดครั้งแรกเลย
• ตรวจว่าไทยและญี่ปุ่นเรนเดอร์ถูกต้อง — สระบนล่างและวรรณยุกต์ซ้อนกัน (อย่าง ี และ ั) บวกกับ kana คือเข็มทิศที่ไวต่อความสำเร็จของการแก้ encoding ที่สุด
• แปลงครั้งเดียว แล้วมาตรฐานเดียว — ทุกรอบการแปลงคือโอกาสให้ความเสียหายทบต้น แก้ครั้งเดียวเป็น UTF-8 แล้วจบ
• ประกาศ encoding ให้ชัดเจน — ตั้ง charset ใน HTTP header, metadata ของไฟล์ และคอลัมน์ฐานข้อมูล อย่าปล่อยให้ซอฟต์แวร์เดาเอาเอง
• ทดสอบด้วยประโยคมาตรฐาน — เก็บตัวอย่างอย่าง สวัสดี café こんにちは ไว้แล้วลองรันผ่าน pipeline ใหม่ ๆ ก่อนไว้ใจให้มันแตะข้อมูลจริง

พร้อมกู้ข้อมูลของคุณกลับคืนหรือยัง เปิด Mojibake Fixer วางข้อความเพี้ยนลงไป แล้วรับข้อความที่อ่านออกกลับมาในไม่กี่วินาที — ทำงานทั้งหมดในเบราว์เซอร์ของคุณ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Text Case Converter — จัดรูปแบบตัวพิมพ์ใหญ่เล็กของข้อความที่แก้แล้วในรอบเดียว
• Find and Replace — ล้างข้อความที่แก้แล้วด้วยการค้นหาและแทนที่จำนวนมาก
• ASCII to Binary Converter — ตรวจดูว่าอักขระแต่ละตัวผลิต byte อะไรออกมาจริง ๆ

การแก้ mojibake แท้ ๆ คือการแปลภาษาระหว่าง encoding — พอมองเห็น byte แล้ว ตัวอักษรประหลาดก็ไม่น่ากลัวอีกต่อไป

คำถามที่พบบ่อย

ถ: mojibake ทุกกรณีแก้ได้ไหม?

ตอบ: แก้ได้เกือบทั้งหมด ตราบใดที่ byte ต้นฉบับยังไม่หาย ความเสียหายจะถาวรก็ต่อเมื่อมีเครื่องมือกลางทางเปลี่ยนอักษรแปลก ๆ เป็นเครื่องหมายคำถามหรือลบทิ้งไปแล้ว เพราะข้อมูลที่ใช้ย้อนการถอดรหัสไม่มีเหลืออยู่ ยิ่งแก้เร็ว โอกาสสำเร็จยิ่งสูง

ถ: ทำไมข้อความไทยถึงขึ้นเป็น สวัสà¸"ี?

ตอบ: ลายเซ็นแบบนี้หมายความว่าข้อความไทย UTF-8 ถูกอ่านเป็น Latin-1 หรือ Windows-1252 พยัญชนะไทยหนึ่งตัวถูกเก็บเป็น byte 3 ตัวใน UTF-8 และแต่ละ byte ถูกแสดงเป็นอักษรยุโรปแยกกัน การ decode ใหม่ด้วยคู่ encoding ที่ถูกต้องจะคืนข้อความไทยเดิมกลับมา

ถ: ข้อความของฉันถูกอัปโหลดไปที่ server หรือเปล่า?

ตอบ: ไม่ Mojibake Fixer ทำงานทั้งหมดในเบราว์เซอร์ด้วย JavaScript และ API ถอดรหัสข้อความที่มากับเบราว์เซอร์โดยตรง ทุกอย่างที่วางลงไปไม่เคยออกจากเครื่องคุณแม้แต่ byte เดียว

ถ: Latin-1 กับ Windows-1252 ต่างกันอย่างไร?

ตอบ: ทั้งสองตัวทับซ้อนกันเกือบทั้งหมด แต่ Windows-1252 กำหนดอักขระที่มองเห็นได้อย่างเครื่องหมายคำพูดโค้งและสัญลักษณ์ยูโร ไว้ในช่วง 0x80–0x9F ที่ Latin-1 สงวนไว้ให้ control code ถ้า mojibake มีลำดับอย่าง “ แปลว่ามักมี Windows-1252 เข้ามาเกี่ยวข้อง ซึ่งเป็นเหตุผลที่เครื่องมือรองรับทั้งสองแบบ