RFC 9839 และยูนิโค้ดที่มีปัญหา

• RFC 9839 นิยาม อักขระยูนิโค้ดที่เป็นปัญหา ซึ่งอาจอยู่ในฟิลด์ข้อความระหว่างการพัฒนาซอฟต์แวร์ไว้อย่างชัดเจน
• RFC นี้กล่าวถึงปัญหาจากการที่ ภาษาและไลบรารีที่แตกต่างกัน จัดการกับอักขระเหล่านี้ได้ไม่สอดคล้องกัน
• ใน 9839 มีการเสนอ ชุดย่อยสามแบบ ที่มีปัญหาน้อยกว่า เพื่อให้เลือกใช้งานได้ตามต้องการ
• เมื่อเทียบกับ PRECIS framework เดิมแล้ว นำไปใช้ได้ง่ายและเรียบง่ายกว่า
• มีการเผยแพร่ ไลบรารีภาษา Go สำหรับ RFC 9839 ควบคู่กันไป เพื่อช่วยให้ใช้งานจริงได้สะดวกขึ้น

---

ภูมิหลังและภาพรวมของ RFC 9839

• ยูนิโค้ดถูกใช้เป็นมาตรฐานในการจัดการข้อมูลข้อความแทบทุกประเภท
• แต่ในการออกแบบโครงสร้างข้อมูลหรือโปรโตคอลจริง หากอนุญาตอักขระยูนิโค้ดทั้งหมด อาจทำให้เกิดปัญหาได้
• Paul Hoffman และผู้เขียนได้ส่ง individual draft ไปยัง IETF เพื่อเสนอเกณฑ์ที่ชัดเจนต่อปัญหายูนิโค้ดที่เกิดซ้ำอยู่เรื่อย ๆ
• หลังจากการหารือเป็นเวลา 2 ปี จึงได้รับการรับรองเป็นมาตรฐานอย่างเป็นทางการและประกาศเป็น RFC 9839
• เอกสารนี้อธิบายอย่างละเอียดถึง ประเภทของอักขระที่เป็นปัญหา เหตุใดจึงเป็นปัญหา (ทั้งในเชิงเทคนิคและเชิงมาตรฐาน) และชุดย่อยสามแบบที่ผู้ใช้สามารถเลือกใช้ได้

เนื้อหาหลักของ RFC 9839

• เป็นเอกสารที่ควรอ้างอิงโดยจำเป็นเมื่อต้องออกแบบ ฟิลด์ข้อความ ในซอฟต์แวร์และสภาพแวดล้อมเครือข่าย
• RFC 9839 มีความยาว 10 หน้า ซึ่งถือว่าค่อนข้างกระชับเมื่อเทียบกับเอกสารมาตรฐานของ IETF
• อธิบายไว้ให้เข้าใจง่าย โดยมุ่งไปที่นักพัฒนาซอฟต์แวร์และวิศวกรเครือข่ายเป็นหลัก

ตัวอย่างอักขระยูนิโค้ดที่เป็นปัญหา

• ตัวอย่างเช่น ในฟิลด์ username ของ JSON อาจมีสตริงดังนี้

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• ปัญหาของแต่ละ code point
  • U+0000 : อักขระ NULL ที่ไม่มีความหมายและอาจรบกวนการทำงานของภาษาโปรแกรมบางภาษา
  • U+0089 : โค้ดควบคุม C1 (CHARACTER TABULATION WITH JUSTIFICATION) ซึ่งมีพฤติกรรมซับซ้อนและไม่สม่ำเสมอ
  • U+DEAD : surrogate ที่ไม่ได้จับคู่ เป็นปัญหาที่เกิดจากข้อจำกัดของ UTF-16 ทำให้เกิดข้อมูลที่ไม่พึงประสงค์
  • \uD9BF\uDFFF (U+7FFFF จริง) : noncharacter ซึ่งตามมาตรฐานห้ามใช้ในการแลกเปลี่ยนข้อมูล
• code point ลักษณะนี้ทำให้เกิด การจัดการที่ไม่สอดคล้องกัน ภายในโครงสร้างข้อมูลและโปรโตคอล และอาจก่อให้เกิดข้อผิดพลาดที่คาดไม่ถึง
• RFC 9839 จึงนิยามอักขระปัญหาเหล่านี้อย่างเป็นทางการ และ ระบุประเภทที่ควรถูกตัดออกอย่างชัดเจน

การออกแบบของ JSON และข้อจำกัด

• ไม่ใช่ความรับผิดของ Doug Crockford ผู้สร้าง JSON
• JSON ถูกออกแบบขึ้นในช่วงที่ยูนิโค้ดยังไม่เติบโตเต็มที่ จึงไม่สามารถจำกัดชุดอักขระได้อย่างเข้มงวด
• ตอนนี้ไม่สามารถเปลี่ยนมาตรฐานได้แล้ว จึงจำเป็นต้องใช้วิธี ตัดอักขระที่เป็นปัญหาออกตามประสบการณ์ที่พบจริง

ความแตกต่างจาก PRECIS framework ของ IETF

• ก่อน RFC 9839 ในปี 2025 ทาง IETF ก็มีมาตรฐานหลากหลายฉบับ เช่น RFC 8264 (PRECIS Framework)
  • framework นี้อธิบายวิธีการปรับแต่ง การประยุกต์ใช้ และการเปรียบเทียบสตริงสากลไว้อย่างละเอียด
  • มีความยาว 43 หน้า และ ครอบคลุมทั้งคำอธิบายพื้นหลังและแนวทางแก้ปัญหา
• PRECIS พึ่งพาเวอร์ชันของยูนิโค้ดอย่างมาก และมีข้อเสียคือซับซ้อนและนำไปใช้ได้ยาก
• RFC 9839 กระชับและเน้นการใช้งานจริงมากกว่า ทำให้ นำไปใช้ได้รวดเร็ว เมื่อต้องนิยามโปรโตคอลใหม่

ชุดย่อยของ RFC 9839 และตัวอย่างการใช้งาน

• 9839 นำเสนอชุดย่อยที่ใช้งานได้จริง 3 แบบ ได้แก่ scalars, XML และ assignables
• แต่ละชุดย่อยมีขอบเขตของอักขระที่เป็นปัญหาซึ่งจะถูกตัดออกแตกต่างกันเล็กน้อย
• ต่อไปนี้คือสรุปตารางว่าฟอร์แมตข้อมูลหลัก ๆ และชุดย่อยของ RFC 9839 จัดการกับอักขระที่เป็นปัญหาอย่างไร
  • ฟอร์แมตบางชนิด เช่น CBOR, TOML, XML, YAML จะตัด surrogate หรืออักขระควบคุมออกบางส่วน
  • I-JSON ตัด surrogate และ noncharacter ออก
  • JSON ทั่วไป, Protobufs ไม่ได้ตัดออก
  • XML, YAML เนื่องจากคุณสมบัติของ charset จึงตัด noncharacter/โค้ดควบคุมออกได้เพียงบางส่วน
    • หมายเหตุ: XML และ YAML ไม่ได้ตัด noncharacter ที่อยู่นอก Basic Multilingual Pane ออก

ไลบรารี RFC 9839 สำหรับภาษา Go

• มีการเผยแพร่ไลบรารี Go ขนาดเล็กที่รองรับ การตรวจสอบอักขระ สำหรับชุดย่อยทั้งสามของ RFC 9839
• มีการทดสอบอย่างเพียงพอแล้ว แต่การปรับแต่งประสิทธิภาพยังอยู่ระหว่างดำเนินการ
• ยินดีรับการทดสอบและข้อเสนอแนะจากการใช้งานจริง

ความสำคัญของ RFC 9839 และกระบวนการทำงาน

• RFC 9839 ผ่านการรับฟังความคิดเห็นจากผู้เขียนร่วมหลายครั้ง และมีการแก้ไข draft มากกว่า 15 รอบก่อนประกาศอย่างเป็นทางการ
• ด้วยการอภิปรายและการมีส่วนร่วมจากผู้เชี่ยวชาญในชุมชนจำนวนมาก จึงพัฒนาเป็น เอกสารที่สมบูรณ์กว่าร่างแรกอย่างมาก
• มีการระบุผู้มีส่วนร่วมไว้ในส่วน “Acknowledgements”

ประสบการณ์จากการส่ง RFC แบบ individual submission

• RFC 9839 ดำเนินการในรูปแบบ individual submission
• เมื่อเทียบกับวิธีดั้งเดิมผ่าน Working Group แล้ว มี ภาระทั้งด้านความพยายามและขั้นตอน มากกว่า
• เมื่อเทียบกับประสบการณ์ในการเข้าร่วม Working Group วิธีดั้งเดิมมีประสิทธิภาพมากกว่าและน่าแนะนำกว่า