ข้อเสนอใหม่สำหรับ Corrected UTF-8 มีเป้าหมายเพื่อแก้ไขสิ่งที่ผู้สร้างมองว่าเป็นข้อบกพร่องพื้นฐานในการออกแบบของมาตรฐานการเข้ารหัสข้อความ UTF-8 ที่ใช้กันอย่างแพร่หลาย อย่างไรก็ตาม ชุมชนเทคโนโลยีได้ตอบสนองด้วยความสงสัยอย่างมาก โดยแสดงความกังวลอย่างจริงจังเกี่ยวกับความเข้ากันได้และการนำไปใช้งานจริง
ข้อเสนอนี้พยายามแก้ไขปัญหาหลักสามประการของ UTF-8 ปัจจุบัน ได้แก่ การกำจัดการเข้ารหัสที่ยาวเกินไปซึ่งเคยก่อให้เกิดช่องโหว่ด้านความปลอดภัย การลบการสนับสนุนสำหรับอักขระควบคุมบางตัวและรหัส surrogate และการขยายพื้นที่อักขระเกินขีดจำกัดปัจจุบัน แม้ว่าเป้าหมายเหล่านี้อาจฟังดูสมเหตุสมผลบนกระดาษ แต่ปฏิกิริยาของชุมชนชี้ให้เห็นว่าการรักษาอาจแย่กว่าโรค
ความแตกต่างหลักจาก UTF-8 มาตรฐาน
- การแก้ไข Overlength Encoding: เพิ่ม offset ให้กับลำดับ multi-byte แทนที่จะปฏิเสธลำดับที่ไม่ถูกต้อง
- การยกเว้นตัวอักษร: ไม่สามารถเข้ารหัส C1 controls (U+0080-U+009F) หรือ Unicode surrogates (U+D800-U+DFFF)
- ขยายช่วงการใช้งาน: รองรับการเข้ารหัสถึง U+8421 109F (เทียบกับ U+10 FFFF ใน UTF-8 มาตรฐาน)
- Magic Number: ใช้ลำดับ 8-byte EF B7 9D ED B2 AE 00 0A เพื่อระบุข้อความ corrected UTF-8
- ข้อจำกัดการขึ้นบรรทัดใหม่: ห้ามใช้การขึ้นบรรทัดใหม่แบบ \r\n ( Windows ) กำหนดให้ใช้เฉพาะแบบ Unix-style \n เท่านั้น
การทำลายความเข้ากันได้สร้างปัญหามากกว่าที่จะแก้ไข
การวิพากษ์วิจารณ์ที่สำคัญที่สุดมุ่งเน้นไปที่แนวทางของข้อเสนอในการแก้ไขการเข้ารหัสที่ยาวเกินไป แทนที่จะปฏิเสธลำดับที่ไม่ถูกต้องเหมือนที่ UTF-8 ปัจจุบันทำ ระบบใหม่จะเพิ่ม offset ให้กับลำดับหลายไบต์ ซึ่งหมายความว่าข้อความ UTF-8 ที่มีอยู่จะถอดรหัสเป็นอักขระที่แตกต่างกันโดยสิ้นเชิงภายใต้ระบบใหม่ ในขณะที่ข้อความที่แก้ไขใหม่ยังคงสามารถถอดรหัสได้โดยระบบ UTF-8 เก่า - เพียงแต่ไม่ถูกต้อง
สมาชิกชุมชนชี้ให้เห็นว่าสิ่งนี้สร้างสถานการณ์อันตรายที่ข้อความดูเหมือนจะทำงานได้ แต่ให้ผลลัพธ์ที่ผิด ความซับซ้อนของการจัดการ offset เหล่านี้ โดยเฉพาะอย่างยิ่งรอบ ๆ ช่องว่างในพื้นที่อักขระ จะทำให้ตัวเข้ารหัสและตัวถอดรหัสซับซ้อนมากกว่าที่เป็นอยู่ในปัจจุบัน
ช่วงลำดับไบต์ UTF-8 ที่แก้ไขแล้ว
| ช่วงลำดับไบต์ | ออฟเซ็ต | ช่วง Codepoint |
|---|---|---|
| 00...7F | 0 | 0000 0000...0000 007F |
| C0 80...DF BF | 160 | 0000 00A0...0000 089F |
| E0 80 80...EC BD 9F | 2,208 | 0000 08A0...0000 D7FF |
| EC BD A0...EF BF BF | 4,256 | 0000 E000...0001 109F |
| F0 80 80 80...F7 BF BF BF | 69,792 | 0001 10A0...0021 109F |
| F8 80 80 80 80...FB BF BF BF BF | 2,166,944 | 0021 10A0...0421 109F |
| FC 80 80 80 80 80...FD BF BF BF BF BF | 69,275,808 | 0421 10A0...8421 109F |
การลบอักขระที่ถูกต้องจุดประกายการถกเถียง
อีกแง่มุมหนึ่งที่ก่อให้เกิดการถกเถียงคือการทำให้อักขระ Unicode บางตัวไม่สามารถเข้ารหัสได้โดยเจตนา ข้อเสนอนี้ข้ามอักขระควบคุม C1 และ Unicode surrogate ทั้งหมด โดยอ้างว่าไม่ควรปรากฏในข้อความปกติอยู่แล้ว อย่างไรก็ตาม การตัดสินใจนี้ได้รับการวิพากษ์วิจารณ์อย่างรุนแรงจากนักพัฒนาที่ต้องจัดการกับข้อมูลเก่าหรือทำงานกับระบบที่มีอยู่
ดูเหมือนว่าเป็นข้อเสนอที่กล้าหาญมากที่จะมี codepoint ที่ไม่สามารถเข้ารหัสได้โดยเจตนา
ข้อจำกัดขยายไปถึงอักขระทั่วไปเช่น horizontal tab และ carriage return โดยข้อเสนอนี้ห้ามแม้แต่การขึ้นบรรทัดใหม่แบบ Windows นักวิจารณ์โต้แย้งว่าสิ่งนี้สร้างอุปสรรคที่ไม่จำเป็นต่อการยอมรับและบังคับให้นักพัฒนาปฏิเสธข้อความที่ถูกต้องอย่างสมบูรณ์ที่ผู้ใช้อาจต้องการประมวลผล
Magic Number และความกังวลเชิงปฏิบัติ
ข้อเสนอนี้รวมถึง magic number - ลำดับไบต์พิเศษที่ระบุข้อความ corrected UTF-8 คล้ายกับ byte order mark ใน UTF-16 อย่างไรก็ตาม ข้อเสนอแนะจากชุมชนชี้ให้เห็นว่าแนวทางนี้ได้พิสูจน์แล้วว่าเป็นปัญหาในทางปฏิบัติ เครื่องหมายเหล่านี้มักจะแอบเข้าไปในตรงกลางของสตริงข้อความและก่อให้เกิดปัญหาที่ไม่คาดคิดในแอปพลิเคชันในโลกจริง
ชุมชนยังตั้งคำถามว่าการขยายพื้นที่อักขระนั้นจำเป็นจริงหรือไม่ การเติบโตของ Unicode ปัจจุบันมาจากการเพิ่มอักขระจีน ญี่ปุ่น และเกาหลีเป็นหลัก แต่การขยายตัวนี้จะไม่ดำเนินต่อไปอย่างไม่มีกำหนด ด้วยอัตราการจัดสรรปัจจุบัน พื้นที่ที่มีอยู่ควรใช้ได้ประมาณ 600 ปี
ทางเลือกอื่นที่มีอยู่แล้ว
สมาชิกชุมชนหลายคนชี้ไปที่โซลูชันที่มีอยู่ซึ่งแก้ไขปัญหาที่คล้ายกันโดยไม่ทำลายความเข้ากันได้ มาตรฐาน UCSX ที่พัฒนาโดยผู้มีส่วนร่วมใน Unicode จริง ๆ ให้การขยายพื้นที่อักขระเมื่อจำเป็น ในขณะเดียวกัน มาตรฐาน IETF ที่กำลังจะมาถึงจะให้คำแนะนำเกี่ยวกับอักขระ Unicode ใดที่ควรหลีกเลี่ยงในการปฏิบัติ ซึ่งแก้ไขความกังวลเดียวกันบางส่วนโดยไม่ต้องการการเข้ารหัสใหม่
ความท้าทายพื้นฐานที่เผชิญหน้ากับการทดแทน UTF-8 ใด ๆ คือฐานที่ติดตั้งขนาดใหญ่ของระบบและข้อมูลที่มีอยู่ ความสำเร็จของ UTF-8 มาจากการเข้ากันได้อย่างสมบูรณ์กับ ASCII ในขณะที่จัดการอักขระ Unicode ทั้งหมด การทดแทนใด ๆ ที่ทำลายความเข้ากันได้นี้เผชิญกับการต่อสู้ขึ้นเขาเพื่อการยอมรับ โดยไม่คำนึงถึงข้อดีทางเทคนิค
ฉันทามติของชุมชนดูชัดเจน: แม้ว่า UTF-8 อาจมีข้อแปลกประหลาดทางประวัติศาสตร์บางประการ แต่ประโยชน์เชิงปฏิบัติของการเข้ารหัสใหม่ไม่ได้มีน้ำหนักมากกว่าต้นทุนของการแยกส่วนระบบนิเวศ สำหรับตอนนี้ ดูเหมือนว่าโลกเทคโนโลยีจะยังคงใช้ชีวิตกับ UTF-8 ที่ไม่ได้แก้ไขต่อไป
อ้างอิง: Corrected UTF-8