UTF8MB4 จะถูกนำมาใช้แทนที่ UTF8 – MySQL

การประกาศซัพพอร์ตรูปแบบการเข้ารหัสตัวอักษรแบบ utf8mb4 ของ MySQL ตั้งแต่เวอร์ชั่น 5.5.3 ทำให้เราเห็นการเปลี่ยนแปลงของรูปแบบการเก็บข้อมูลของเว็บไซต์ต่างๆ เปลี่ยนไปจากเดิม WordPress เองก็เป็นหนึ่งในนั้นที่เปลี่ยนรูปแบบการติดตั้งมาตรฐานมาใช้ utf8mb4 (WordPress #21212) ในขณะที่ PHP The Right Way ก็แนะนำให้ใช้ utf8mb4 เช่นกัน ในตอนนี้เรามาดูกันครับ ว่า UTF8MB4 คืออะไร แล้วทำไมถึงเปลี่ยนมาใช้ตัวนี้กัน

จากเดิมนักพัฒนาเว็บจะนิยมใช้ utf8 เป็น Character Set ต้องบอกก่อนว่า utf8 ใน MySQL มันเป็น Subset ของ UTF-8 เอ๊ะยังไง

ก็คือ utf8 Character Set ใน MySQL ไม่ได้เป็น UTF-8 อย่างสมบูรณ์ เป็นเพียง Subset เท่านั้น 1 ตัวอักษรจะใช้พื้นที่โดยประมาณ 1-3 ไบต์ (MySQL Ref) ขึ้นอยู่กับว่าอักษรที่เราเก็บนั้นเข้ารูปแบบการจัดเก็บแบบไหน แต่ว่า ก็ไม่ได้เก็บทุกอย่าง ตาม UTF-8 Specification ครับ เพราะว่า พื้นที่ในส่วนของ Supplementary Character นั้นหายไป ดังนั้น ถ้าเราเก็บข้อมูลประมาณอักขระพิเศษ Emoji อะไรเทือกนั้น มันจะสูญสลายหายไป เพราะว่าด้วยตัวโครงสร้าง utf8 ของ MySQL มันยังเก็บไม่ได้ครับ

ดังนั้น utf8mb4 เป็น Character Set ชุดใหม่ที่เริ่มจะมีมาได้ MySQL 5.3.3 โดยที่เป็น UTF-8 อย่างแท้จริง ใช้พื้นที่เก็บอักขระหนึ่งตัวอยู่ระหว่าง 1-4 ไบต์ เป็นไปตามข้อกำหนดของ UTF-8 โดยที่หนึ่งไบต์ที่เพิ่มขึ้นมานั้น มันเอาไปทำอะไรกัน

คำตอบก็คือว่าในรูปแบบการจัดเก็บแบบ UTF8 อักษรประหลาดพิเศษๆ (supplementary character) ที่ขาดหายไปใน Character Set แบบ utf8 ครับ ดังนั้นในแบบ utf8mb4 นี้ เราจะสามารถเก็บพวก emoji พวกภาพสัญลักษณ์อะไรต่างๆ เข้าไปเพิ่มได้แล้ว รวมถึง ถ้าหาก นักพัฒนา ก่อนหน้าใช้พวก Latin1 อะไรอย่างนี้ ถ้าจะ Convert มาเป็น UTF8MB4 มันก็จะไม่ต้องกังวลการสูญเสียข้อมูลจากอักขระที่อยู่นอกกรอบของBasic Multilingual Plane (BMP) ซึ่ง Character แบบเดิมนั้นจะไม่เก็บให้ครับ

เปลี่ยนมาใช้ UTF8MB4

การเปลี่ยน Character Set จาก UTF8 มาเป็น UTF8MB4 สามารถติดตามได้จากคู่มือของ MySQL ครับ

ข้อควรระวังในการเปลี่ยนก็คือ จากการที่ UTF8MB4 อาจมีการใช้พื้นที่เก็บเพิ่ม 1 ตัวอักษร ในแต่ละตัวอักษรที่ใส่เข้าไป ในขณะที่ Index ของ InnoDB ถูกจำกัดอยู๋ที่ 767 ไบต์ ดังนั้น จึงมีความเป็นไปได้ว่า ถ้าหาก Column ที่เราต้องการ Convert นั้นเป็น Key อยู่ด้วย จะต้องดูว่าสามารถทำการ Convert ได้หรือเปล่า หรือ Convert แล้วมันจะล้นออกมา อย่างเช่นของ WordPress จะมี Column ที่ถูกลดขนาดลงบางตัว เพื่อให้ใช้งานได้ เป็นต้นครับ ส่วนเว็บแอพลิเคชั่นอื่น อาจทดสอบสำเนาข้อมูลไว้ก่อน แล้วลอง Convert ดูได้ครับ ถ้าหากว่าความยาวเกิน ก็จะเจอ Error Message ในขั้นตอนของการ ALTER TABLE เอง

เปรียบเทียบกับแบบอื่น

จริงๆ utf8mb4 ก็คือ UTF-8 แบบสมบูรณ์นั่นเอง ข้อดีของมันคือมันจัดเก็บอักขระแบบใช้พื้่นที่ไม่แน่นอน ระหว่าง 1-4 ไบต์ มีประโยชน์ในด้านลดพื้นที่จัดเก็บข้อมูล แตกต่างจาก UTF-16 / UTF-32 ตรงที่ว่า สองตัวนั้นจะมีการจัดเก็บข้อมูล 2,4 ไบต์และ 4 ไบต์เสมอ ซึ่งเปลืองพื้นที่กว่ามาก และก็ไม่รองรับไฟล์ที่เป็น ASCII แบบเดิมๆ ครับ

แนวทางพัฒนา

ถ้าสมมุติว่าแอพลิเคชั่นเรายังใช้ Character Set ประเภท Latin1 แนะนำให้ Convert มาเป็นแบบ UTF8MB4 ไปเลยครับ ไม่ต้อง Convert ไปเป็น UTF8 ก่อน วิธีการนี้จะช่วยให้ข้อมูลของ User พวกที่เป็น Emoji สัญลักษณ์ภาพทั้งหลาย ถูกนำมาเก็บอย่างถูกต้องครับ

ถ้าแอพลิเคชั่นเราใช้ Character set แบบ utf8 อยู่ อย่าลืมดูเรื่องขนาดของ Index ครับ โดยปกติก็ควรจะสลับมาใช้ได้เลย เพราะเป็น Subset ของ utf8mb4 อยู่แล้วครับ

สำหรับแอพลิเคชั่นใหม่ แนะนำให้เริ่มต้นใช้แบบ utf8mb4 ไปยาวๆ ได้เลยครับ ตรงตามมาตรฐาน UTF-8 อนาคต ใช้ไปจนลูกโตเลยครับ

อ่านเพิ่มเติม

How to support full Unicode in MySQL databases