Internet Engineering Task Force ( IETF ) ได้เผยแพร่ RFC 9839 ซึ่งเป็นมาตรฐานใหม่ที่แก้ไขปัญหาตัวอักษร Unicode ที่สร้างปัญหาให้กับระบบซอฟต์แวร์และโปรโตคอลเครือข่าย แม้ว่า Unicode จะได้รับการยอมรับอย่างกว้างขวางในฐานะมาตรฐานการเข้ารหัสข้อความ แต่ตัวอักษรทั้งหมดไม่เหมาะสมสำหรับทุกแอปพลิเคชัน
RFC นี้ซึ่งเขียนโดย Tim Bray และ Paul Hoffman ระบุตัวอักษร Unicode เฉพาะที่ก่อให้เกิดปัญหาในระบบจริง และเสนอชุดย่อยที่เรียบง่ายสามชุดที่นักพัฒนาสามารถใช้แทนกรอบงาน PRECIS ที่ซับซ้อนกว่าจากปี 2017
ปัญหาของตัวอักษร Bad Unicode
ปัญหาหลักอยู่ที่ตัวอักษร Unicode บางตัวที่แม้จะถูกต้องทางเทคนิค แต่สร้างปัญหาร้ายแรงเมื่อใช้ในฟิลด์ข้อความ ซึ่งรวมถึง null bytes ที่รบกวนภาษาโปรแกรม, unpaired surrogates จากการเข้ารหัส UTF-16 ที่ไม่ควรมีอยู่ใน UTF-8 และ noncharacters ที่ Unicode ห้ามใช้อย่างชัดเจนสำหรับการแลกเปลี่ยนข้อมูล
ตัวอย่างที่สร้างปัญหาเป็นพิเศษคือรหัสควบคุมเก่าอย่าง CHARACTER TABULATION WITH JUSTIFICATION ซึ่งเป็นคำสั่งจัดรูปแบบที่คลุมเครือที่สืบทอดมาจากมาตรฐานในทศวรรษ 1990 ที่ไม่มีประโยชน์ในทางปฏิบัติในแอปพลิเคชันสมัยใหม่ แต่อาจทำให้เกิดพฤติกรรมที่คาดเดาไม่ได้ในระบบต่างๆ
การอภิปรายในชุมชนเผยให้เห็นการถกเถียงที่ยังคงดำเนินอยู่เกี่ยวกับตำแหน่งที่ควรบังคับใช้ข้อจำกัดเหล่านี้ นักพัฒนาบางคนโต้แย้งว่าโปรโตคอลระดับต่ำอย่าง JSON ควรยังคงเปิดกว้าง โดยปล่อยให้การกรองตัวอักษรเป็นหน้าที่ของชั้นการตรวจสอบเฉพาะแอปพลิเคชัน ในขณะที่คนอื่นๆ ยืนยันว่าการล้มเหลวอย่างปลอดภัยในระดับโปรโตคอลป้องกันปัญหาที่เกิดขึ้นในระบบปลายทาง
ประเภทของอักขระ Unicode ที่มีปัญหา:
- Surrogates: สิ่งประดิษฐ์จากการเข้ารหัส UTF-16 ที่ไม่มีคู่ (เช่น U+DEAD)
- Legacy Controls: คำสั่งจัดรูปแบบที่ล้าสมัยจากมาตรฐานยุค 1990s (เช่น U+0089)
- Noncharacters: จุดรหัสที่ถูกห้ามอย่างชัดเจนสำหรับการแลกเปลี่ยนข้อมูล (เช่น U+7FFFF)
- Null Bytes: อักขระ U+0000 ที่รบกวนการทำงานของภาษาโปรแกรม
ความท้าทายในการใช้งานและข้อกังวลด้านความปลอดภัย
ผลกระทบด้านความปลอดภัยขยายไปเกินกว่าข้อผิดพลาดในการแยกวิเคราะห์ธรรมดา ตัวอักษรที่เปลี่ยนทิศทางสามารถทำให้ชื่อผู้ใช้ปรากฏว่าอ่านจากขวาไปซ้าย ซึ่งอาจทำให้อินเทอร์เฟซผู้ดูแลระบบอ่านไม่ได้ ที่ร้ายแรงกว่านั้น ตัวอักษรเหล่านี้เปิดใช้งานการโจมตี Trojan source ที่โค้ดที่แสดงไม่ตรงกับไบต์จริงที่ถูกประมวลผล
รูปแบบข้อมูลต่างๆ จัดการตัวอักษรที่สร้างปัญหาอย่างไม่สอดคล้องกัน JSON อนุญาตให้ใช้ประเภทที่สร้างปัญหาทั้งหมด ในขณะที่ XML และ YAML ให้การป้องกันบางส่วน ความไม่สอดคล้องนี้สร้างปัญหาความเข้ากันได้เมื่อระบบแลกเปลี่ยนข้อมูลระหว่างรูปแบบต่างๆ
ฉันจะห้ามไม่ให้ใช้อีโมจิล่าสุดที่เพิ่งออกมาในชื่อผู้ใช้แทนที่จะปล่อยให้มันทำลายทุกหน้าที่แสดงชื่อผู้ใช้
RFC เสนอชุดย่อยสามชุดที่มีข้อจำกัดเพิ่มขึ้นเป็นลำดับ: Scalars (ยกเว้นเฉพาะ surrogates), XML (ตรงกับข้อจำกัดของ XML) และ Assignables (ยกเว้นประเภทที่สร้างปัญหาทั้งหมด) วิธีการแบบค่อยเป็นค่อยไปนี้ช่วยให้นักพัฒนาเลือกข้อจำกัดที่เหมาะสมตามความต้องการเฉพาะของพวกเขา
ชุดย่อยที่เสนอใน RFC 9839:
| ชื่อชุดย่อย | ไม่รวม Surrogates | ไม่รวม Legacy Controls | ไม่รวม Noncharacters |
|---|---|---|---|
| Scalars | ใช่ | ไม่ | ไม่ |
| XML | ใช่ | บางส่วน | บางส่วน |
| Assignables | ใช่ | ใช่ | ใช่ |
การตอบรับจากชุมชนและการนำไปใช้ในทางปฏิบัติ
ปฏิกิริยาของนักพัฒนามีความหลากหลายแต่โดยทั่วไปเป็นไปในทางบวก หลายคนชื่นชมที่มีข้อมูลอ้างอิงมาตรฐานสำหรับข้อจำกัดตัวอักษรแทนที่แต่ละโครงการจะสร้างกฎของตัวเอง อย่างไรก็ตาม บางคนกังวลเกี่ยวกับข้อจำกัดที่กว้างเกินไปที่อาจบล็อกกรณีการใช้งานที่ถูกต้อง เช่น ตัวอักษรควบคุมในแอปพลิเคชันเทอร์มินัลหรือเนื้อหาไฟล์ที่ต้องการลำดับ Unicode ที่ผิดปกติจริงๆ
เวลานี้ดูเหมือนจะเหมาะสมสำหรับการนำไปใช้ ไม่เหมือนกรอบงาน PRECIS ที่ครอบคลุมแต่ซับซ้อน RFC 9839 เสนอวิธีการที่เรียบง่ายกว่าที่ไม่ผูกการใช้งานกับเวอร์ชัน Unicode เฉพาะ ความยืดหยุ่นนี้ดึงดูดนักพัฒนาที่ต้องการสนับสนุนอีโมจิและตัวอักษรล่าสุดโดยไม่ต้องประสานงานเวอร์ชันอย่างกว้างขวางระหว่างระบบ
RFC นี้แสดงถึงการประนีประนอมที่เป็นจริงระหว่างความเป็นสากลที่ทะเยอทะยานของ Unicode และความต้องการในทางปฏิบัติของระบบซอฟต์แวร์ที่แข็งแกร่ง เมื่อนักพัฒนาจำนวนมากขึ้นนำแนวทางเหล่านี้ไปใช้ เราควรจะเห็นบั๊กการจัดการข้อความที่ลึกลับน้อยลงและพฤติกรรมที่คาดเดาได้มากขึ้นในแพลตฟอร์มและแอปพลิเคชันต่างๆ
อ้างอิง: RFC 9839 and Bad Unicode