ควรถือว่า UTF-16 เป็นอันตรายหรือไม่?

ฉันจะถามสิ่งที่อาจเป็นคำถามโต้เถียง: "หนึ่งในการเข้ารหัสที่นิยมมากที่สุด UTF-16 ถือว่าเป็นอันตรายหรือไม่"

ทำไมฉันถึงถามคำถามนี้

มีโปรแกรมเมอร์กี่คนที่ตระหนักถึงความจริงที่ว่า UTF-16 เป็นความยาวแปรผันได้หรือไม่? โดยสิ่งนี้ฉันหมายความว่ามีจุดรหัสที่แสดงเป็นคู่ตัวแทนแทนใช้องค์ประกอบมากกว่าหนึ่ง

ฉันรู้ว่า; แอปพลิเคชั่นเฟรมเวิร์กและ API จำนวนมากใช้ UTF-16 เช่นสตริงของ Java, สตริง C #, Win32 APIs, ไลบรารี Qt GUI, ไลบรารี ICU Unicode เป็นต้นอย่างไรก็ตามจากทั้งหมดนี้มีข้อบกพร่องพื้นฐานมากมายในการประมวลผล ของอักขระจาก BMP (อักขระที่ควรเข้ารหัสโดยใช้สององค์ประกอบ UTF-16)

ตัวอย่างเช่นลองแก้ไขหนึ่งในตัวละครเหล่านี้:

• LE ( U + 1D11E ) ดนตรีซิมโฟนี G CLEF
• 𝕥 ( U + 1D565 ) คณิตศาสตร์สองชั้นซ้อนขนาดเล็ก
• 𝟶 ( U + 1D7F6 ) ศูนย์หลักสี่เชิงคณิตศาสตร์
• 𠂊 ( U + 2008A ) ตัวละครฮัน

คุณอาจพลาดบางอย่างขึ้นอยู่กับแบบอักษรที่คุณติดตั้ง ตัวละครเหล่านี้ล้วนอยู่นอก BMP (Basic Multilingual Plane) หากคุณไม่สามารถมองเห็นตัวละครเหล่านี้คุณยังสามารถลองมองพวกเขาในการอ้างอิงอักขระ Unicode

ตัวอย่างเช่นลองสร้างชื่อไฟล์ใน Windows ที่มีอักขระเหล่านี้ พยายามลบอักขระเหล่านี้ด้วย "backspace" เพื่อดูว่าอักขระเหล่านั้นทำงานอย่างไรในแอปพลิเคชันต่างๆที่ใช้ UTF-16 ฉันทำการทดสอบและผลลัพธ์ค่อนข้างแย่:

• Opera มีปัญหาในการแก้ไข (ลบ 2 กดที่ backspace)
• Notepad ไม่สามารถจัดการกับมันได้อย่างถูกต้อง (ลบ 2 กดบน backspace ที่จำเป็น)
• การแก้ไขชื่อไฟล์ในหน้าต่างไดอะล็อกเสีย (ต้องลบ 2 กดที่ backspace)
• ทุกการใช้งาน Qt3 ไม่สามารถจัดการกับพวกเขา - การแสดงสองสี่เหลี่ยมที่ว่างแทนสัญลักษณ์หนึ่ง
• Python เข้ารหัสอักขระดังกล่าวไม่ถูกต้องเมื่อใช้โดยตรงu'X'!=unicode('X','utf-16')ในบางแพลตฟอร์มเมื่อ X เป็นอักขระนอก BMP
• Python 2.5 unicodedata ล้มเหลวในการรับคุณสมบัติของอักขระดังกล่าวเมื่อไพ ธ อนคอมไพล์ด้วยสตริง UTF-16 Unicode
• StackOverflow ดูเหมือนจะลบอักขระเหล่านี้ออกจากข้อความหากแก้ไขโดยตรงในรูปแบบอักขระ Unicode (อักขระเหล่านี้แสดงโดยใช้ HTML Unicode escapes)
• กล่องข้อความ WinForms อาจสร้างสตริงที่ไม่ถูกต้องเมื่อถูก จำกัด ด้วย MaxLength

ดูเหมือนว่าข้อผิดพลาดดังกล่าวหาได้ง่ายมากในหลาย ๆ แอปพลิเคชั่นที่ใช้ UTF-16

ดังนั้น ... คุณคิดว่า UTF-16 น่าจะถือว่าเป็นอันตรายหรือไม่?

นี่คือคำตอบเก่า
ดูUTF-8 ทุกที่สำหรับการอัพเดทล่าสุด

ความคิดเห็นที่: ใช่ UTF-16 ควรได้รับการพิจารณาเป็นอันตราย เหตุผลที่มันมีอยู่ก็เพราะว่าเมื่อก่อนเคยมีความเชื่อที่เข้าใจผิดว่า Widechar จะเป็นสิ่งที่ UCS-4 เป็นอยู่ตอนนี้

แม้จะมี "แองโกล - centrism" ของ UTF-8 แต่ก็ควรได้รับการพิจารณาให้เป็นประโยชน์สำหรับการเข้ารหัสข้อความเท่านั้น หนึ่งสามารถยืนยันว่าซอร์สโค้ดของโปรแกรม, หน้าเว็บและไฟล์ XML, ชื่อไฟล์ OS และส่วนต่อประสานข้อความข้อความจากคอมพิวเตอร์สู่คอมพิวเตอร์อื่น ๆ ไม่ควรมีอยู่ แต่เมื่อพวกเขาทำข้อความไม่ได้มีไว้สำหรับผู้อ่านที่เป็นมนุษย์เท่านั้น

ในทางตรงกันข้ามค่าใช้จ่าย UTF-8 เป็นราคาขนาดเล็กที่ต้องจ่ายในขณะที่มีข้อได้เปรียบที่สำคัญ char*ข้อดีเช่นเข้ากันได้กับรหัสไม่รู้ว่าเพียงแค่ผ่านสตริง นี่คือสิ่งที่ดี มีอักขระที่มีประโยชน์น้อยซึ่งเป็น SHORTER ใน UTF-16 มากกว่าอักขระ UTF-8

ฉันเชื่อว่าการเข้ารหัสอื่น ๆ ทั้งหมดจะตายในที่สุด สิ่งนี้เกี่ยวข้องกับ MS-Windows, Java, ICU, python หยุดใช้มันเป็นรายการโปรด หลังจากการวิจัยและการอภิปรายเป็นระยะเวลานานข้อตกลงการพัฒนาที่บริษัท ของฉันสั่งห้ามใช้ UTF-16 ทุกที่ยกเว้นการเรียกใช้ OS API และสิ่งนี้แม้จะมีความสำคัญของประสิทธิภาพในแอปพลิเคชันของเราและข้อเท็จจริงที่ว่าเราใช้ Windows ฟังก์ชั่นการแปลงถูกพัฒนาขึ้นเพื่อแปลงเสมอสันนิษฐาน-UTF8 std::stringเพื่อพื้นเมือง UTF-16 ซึ่ง Windows เองไม่สนับสนุนอย่างถูกต้อง

สำหรับผู้ที่พูดว่า " ใช้สิ่งที่ต้องการในที่ที่จำเป็น " ฉันพูดว่า: มีประโยชน์มากในการใช้การเข้ารหัสแบบเดียวกันทุกที่และฉันไม่เห็นเหตุผลเพียงพอที่จะทำเช่นนั้น โดยเฉพาะอย่างยิ่งฉันคิดว่าการเพิ่มwchar_tใน C ++ นั้นเป็นข้อผิดพลาดและดังนั้นการเพิ่ม Unicode ใน C ++ 0x สิ่งที่จะต้องได้รับการเรียกร้องจากการใช้งาน STL ว่าเป็นที่ทุกคนstd::stringหรือchar*พารามิเตอร์ที่จะได้รับการพิจารณา Unicode ที่เข้ากันได้

ฉันต่อต้านการใช้ " สิ่งที่คุณต้องการ " ด้วย ฉันไม่เห็นเหตุผลใด ๆ สำหรับเสรีภาพดังกล่าว มีความสับสนในเรื่องของข้อความมากพอทำให้เกิดซอฟต์แวร์ที่เสียทั้งหมดนี้ จากที่กล่าวมาข้างต้นฉันเชื่อว่าในที่สุดผู้เขียนโปรแกรมต้องบรรลุฉันทามติใน UTF-8 เป็นวิธีที่เหมาะสม (ฉันมาจากประเทศที่ไม่พูดภาษาอัสโกและโตมากับวินโดวส์ดังนั้นฉันคาดว่าจะถูกโจมตี UTF-16 ครั้งสุดท้ายตามพื้นที่ทางศาสนา)

ฉันต้องการแบ่งปันข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่ฉันทำข้อความบน Windows และสิ่งที่ฉันแนะนำให้คนอื่น ๆ สำหรับการคอมไพล์เวลาที่ตรวจสอบความถูกต้องแบบ Unicode เวลาใช้งานง่ายและดีกว่าหลายแพลตฟอร์มของรหัส ข้อเสนอแนะแตกต่างอย่างมากจากสิ่งที่มักจะแนะนำว่าเป็นวิธีที่เหมาะสมในการใช้ Unicode บน windows แต่ในการวิจัยเชิงลึกของคำแนะนำเหล่านี้ส่งผลให้ข้อสรุปเดียวกัน ดังนั้นที่นี่ไป:

• ห้ามใช้wchar_tหรือstd::wstringในสถานที่อื่นนอกเหนือจากจุดติดกับ API ที่ยอมรับ UTF-16
• อย่าใช้_T("")หรือL""UTF-16 ตัวอักษร (IMO เหล่านี้ควรถูกนำออกจากมาตรฐานซึ่งเป็นส่วนหนึ่งของการคัดค้าน UTF-16)
• อย่าใช้ประเภทฟังก์ชั่นหรืออนุพันธ์ของพวกเขาที่มีความไวต่อความ_UNICODEคงที่เช่นหรือLPTSTRCreateWindow()
• กระนั้น_UNICODEก็มีการกำหนดไว้เสมอเพื่อหลีกเลี่ยงการส่งผ่านสchar*ตริไปยัง WinAPI ในการรวบรวมอย่างเงียบ ๆ
• std::stringsและchar*ที่ใดก็ได้ในโปรแกรมถือว่าเป็น UTF-8 (ถ้าไม่ได้พูดเป็นอย่างอื่น)
• สตริงทั้งหมดของฉันมีstd::stringแต่คุณสามารถส่งผ่าน char * convert(const std::string &)หรือสตริงตัวอักษรที่จะ

• ใช้ฟังก์ชัน Win32 เท่านั้นที่ยอมรับ widechars ( LPWSTR) ผู้ที่ไม่เคยยอมรับหรือLPTSTR LPSTRผ่านพารามิเตอร์ด้วยวิธีนี้:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (นโยบายใช้ฟังก์ชันการแปลงด้านล่าง)

• ด้วยสตริง MFC:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• การทำงานกับไฟล์ชื่อไฟล์และ fstream บน Windows:

  • อย่าส่งต่อstd::stringหรือconst char*โต้แย้งชื่อไฟล์ไปยังfstreamครอบครัว MSVC STL ไม่สนับสนุนอาร์กิวเมนต์ UTF-8 แต่มีส่วนขยายที่ไม่ได้มาตรฐานซึ่งควรใช้ดังนี้:

  • แปลงstd::stringข้อโต้แย้งstd::wstringกับUtils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    เราจะต้องลบการแปลงด้วยตนเองเมื่อทัศนคติของ MSVC ต่อการfstreamเปลี่ยนแปลง

  • รหัสนี้ไม่ใช่หลายแพลตฟอร์มและอาจต้องเปลี่ยนด้วยตนเองในอนาคต
  • ดูfstreamงานวิจัย unicode / การอภิปราย 4215 สำหรับข้อมูลเพิ่มเติม
  • ไม่ผลิตไฟล์ข้อความที่มีเนื้อหาที่ไม่ใช่ UTF8
  • หลีกเลี่ยงการใช้fopen()เหตุผล RAII / OOD หากจำเป็นให้ใช้_wfopen()และจัดการประชุม WinAPI ด้านบน

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

ตัวเข้ารหัส Unicode ไม่ใช่อักขระ! บางครั้งพวกเขาก็ไม่ได้ร่ายมนตร์ (รูปแบบภาพ)

ตัวอย่างบางส่วน:

• codepoints ตัวเลขโรมันเช่น "ⅲ" (อักขระตัวเดียวที่ดูเหมือน "iii")
• อักขระที่เน้นเสียงเช่น "á" ซึ่งสามารถแสดงเป็นอักขระที่รวมกันอย่างเดียว "\ u00e1" หรืออักขระและแยกเครื่องหมายกำกับ "\ u0061 \ u0301"
• ตัวอักษรเช่นกรีกตัวพิมพ์เล็กซิกซึ่งมีรูปแบบที่แตกต่างกันสำหรับกลาง ("σ") และจุดสิ้นสุด ("ς") ของตำแหน่งคำ แต่ควรพิจารณาคำพ้องความหมายสำหรับการค้นหา
• เครื่องหมายขีดคั่นที่มีเครื่องหมายกำกับ Unicode U + 00AD ซึ่งอาจแสดงหรือไม่แสดงให้เห็นด้วยสายตาขึ้นอยู่กับบริบทและจะถูกละเว้นสำหรับการค้นหาความหมาย

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

มีกฎง่ายๆเกี่ยวกับสิ่งที่ Unicode Transformation Form (UTF) ที่จะใช้: - utf-8 สำหรับการจัดเก็บและการสื่อสาร - utf-16 สำหรับการประมวลผลข้อมูล - คุณอาจใช้ utf-32 ถ้าแพลตฟอร์ม API ส่วนใหญ่ที่คุณใช้คือ utf-32 (พบได้ทั่วไปในโลก UNIX)

ระบบส่วนใหญ่ในปัจจุบันใช้ utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt) ดูเอกสารนี้: http://unicode.org/notes/tn12/

กลับไปที่ "UTF-16 เป็นอันตราย" ฉันจะพูดว่า: ไม่แน่นอน

คนที่กลัวตัวแทน (คิดว่าพวกเขาเปลี่ยน Unicode เป็นการเข้ารหัสแบบความยาวผันแปร) ไม่เข้าใจความซับซ้อนอื่น ๆ (ใหญ่กว่า) ที่ทำให้การแมประหว่างตัวละครและจุดโค้ด Unicode ซับซ้อนมาก: การรวมตัวอักษร, ตัวเลือกการเปลี่ยนแปลง ตัวควบคุม ฯลฯ

เพียงอ่านซีรี่ส์นี้ที่นี่http://www.siao2.com/2009/06/29/9800913.aspxและดูว่า UTF-16 กลายเป็นปัญหาง่ายได้อย่างไร

ใช่แล้ว

ทำไม? มันจะทำอย่างไรกับรหัสการออกกำลังกาย

หากคุณดูสถิติการใช้งาน codepointเหล่านี้ในคลังข้อมูลขนาดใหญ่โดย Tom Christiansen คุณจะเห็นว่า codepoints BMP trans-8bit นั้นถูกใช้หลายคำสั่งถ้าขนาดมากกว่า codepoint ที่ไม่ใช่ BMP:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

ใช้ TDD dictum: "รหัสที่ไม่ผ่านการทดสอบเป็นรหัสที่ใช้งานไม่ได้" และใช้ถ้อยคำใหม่เป็น "รหัสที่ไม่ได้ใช้งานเป็นรหัสที่ใช้งานไม่ได้" และคิดว่าโปรแกรมเมอร์ต้องจัดการ codepoints ที่ไม่ใช่ BMP บ่อยเพียงใด

ข้อบกพร่องที่เกี่ยวข้องกับการไม่ได้ติดต่อกับ UTF-16 เป็นเข้ารหัสตัวแปรความกว้างมากมีแนวโน้มที่จะไปไม่มีใครสังเกตเห็นข้อบกพร่องกว่าเทียบเท่า UTF-8 ภาษาการเขียนโปรแกรมบางภาษายังไม่รับประกันว่าจะให้ UTF-16 แทน UCS-2 และภาษาโปรแกรมระดับสูงบางภาษาเสนอการเข้าถึงหน่วยรหัสแทนรหัสจุด (แม้แต่ C ควรให้คุณเข้าถึง codepoints ถ้าคุณใช้wchar_tโดยไม่คำนึงถึงสิ่งที่บางแพลตฟอร์มอาจทำ)

ฉันขอแนะนำว่าการคิด UTF-16 อาจถือว่าเป็นอันตรายกล่าวว่าคุณต้องเข้าใจยูนิโค้ดมากขึ้น

เนื่องจากฉันถูก downvoted ในการนำเสนอความคิดเห็นของฉันเกี่ยวกับคำถามแบบอัตนัยให้ฉันทำอย่างละเอียด อะไรคือสิ่งที่รบกวนจิตใจคุณเกี่ยวกับ UTF-16 คุณจะชอบไหมถ้าทุกอย่างถูกเข้ารหัสใน UTF-8 UTF-7? หรือวิธีการเกี่ยวกับ UCS-4 แน่นอนว่าแอปพลิเคชั่นบางตัวไม่ได้รับการออกแบบมาเพื่อจัดการกับรหัสอักขระทุกตัว แต่มีความจำเป็นโดยเฉพาะอย่างยิ่งในโดเมนข้อมูลทั่วโลกในปัจจุบันสำหรับการสื่อสารระหว่างขอบเขตระหว่างประเทศ

แต่จริงๆแล้วถ้าคุณรู้สึกว่า UTF-16 ควรได้รับการพิจารณาว่าเป็นอันตรายเพราะมันทำให้เกิดความสับสนหรือสามารถนำไปใช้งานได้อย่างไม่เหมาะสม (ยูนิโค้ดสามารถทำได้อย่างแน่นอน) แล้วการเข้ารหัสตัวอักษรวิธีใดบ้าง

แก้ไข: เพื่อชี้แจง: เหตุใดจึงพิจารณาการใช้งานที่ไม่เหมาะสมของมาตรฐานเป็นภาพสะท้อนของคุณภาพของมาตรฐานเอง? ดังที่คนอื่น ๆ ได้กล่าวไว้ในภายหลังเพียงเพราะแอปพลิเคชันใช้เครื่องมือที่ไม่เหมาะสมไม่ได้หมายความว่าเครื่องมือนั้นเสีย หากเป็นกรณีนี้เราอาจพูดได้ว่า "คำหลัก var ถือว่าเป็นอันตราย" หรือ "เกลียวถือว่าเป็นอันตราย" ฉันคิดว่าคำถามสร้างความสับสนให้กับคุณภาพและลักษณะของมาตรฐานกับความยากลำบากที่โปรแกรมเมอร์จำนวนมากมีในการนำไปใช้และใช้งานอย่างเหมาะสมซึ่งฉันรู้สึกว่าเกิดจากการขาดความเข้าใจในการทำงานของยูนิโค้ด

ไม่มีอะไรผิดปกติกับการเข้ารหัส Utf-16 แต่ภาษาที่ใช้กับหน่วย 16 บิตเป็นอักขระที่ควรได้รับการพิจารณาว่าออกแบบมาไม่ดี การมีประเภทชื่อ ' char' ซึ่งไม่ได้แสดงถึงตัวละครเสมอไปนั้นค่อนข้างสับสน เนื่องจากนักพัฒนาซอฟต์แวร์ส่วนใหญ่คาดว่าคนประเภท char จะเป็นตัวแทนของรหัสจุดหรือตัวอักษรรหัสจำนวนมากอาจจะแตกเมื่อสัมผัสกับตัวอักษรบียอนด์ BMP

อย่างไรก็ตามโปรดทราบว่าแม้การใช้ utf-32 ไม่ได้หมายความว่าจุดรหัส 32- บิตแต่ละจุดจะแสดงถึงตัวละครเสมอ เนื่องจากการรวมอักขระอักขระที่แท้จริงอาจประกอบด้วยจุดรหัสหลายจุด Unicode นั้นไม่สำคัญเลย

BTW อาจมีคลาสของบั๊กที่เหมือนกันกับแพลตฟอร์มและแอพพลิเคชั่นซึ่งคาดว่าอักขระจะเป็น 8 บิตซึ่งถูกเลี้ยงด้วย Utf-8

ตัวเลือกส่วนตัวของฉันคือใช้ UTF-8 เสมอ เป็นมาตรฐานบน Linux สำหรับเกือบทุกอย่าง มันเข้ากันได้กับแอปรุ่นเก่าหลายรุ่น มีค่าใช้จ่ายน้อยมากในแง่ของพื้นที่พิเศษที่ใช้สำหรับตัวอักษรที่ไม่ใช่ละตินเทียบกับรูปแบบ UTF อื่น ๆ และมีการประหยัดที่สำคัญในพื้นที่สำหรับตัวอักษรละติน บนเว็บภาษาลาตินครองตำแหน่งสูงสุดและฉันคิดว่าพวกเขาจะทำในอนาคตอันใกล้ และเพื่อกล่าวถึงหนึ่งในข้อโต้แย้งหลักในโพสต์ต้นฉบับ: เกือบโปรแกรมเมอร์ทุกคนทราบว่าบางครั้ง UTF-8 จะมีอักขระหลายไบต์ในนั้น ไม่ใช่ทุกคนที่เกี่ยวข้องกับเรื่องนี้อย่างถูกต้อง แต่พวกเขามักจะตระหนักซึ่งเป็นมากกว่าที่สามารถพูดได้สำหรับ UTF-16 แต่แน่นอนคุณต้องเลือกอันที่เหมาะสมที่สุดสำหรับการสมัครของคุณ นั่นเป็นเหตุผลที่มีมากกว่าหนึ่งในสถานที่แรก

มีการเข้ารหัสที่ใช้สัญลักษณ์ขนาดคงที่ ฉันหมายถึง UTF-32 อย่างแน่นอน แต่ 4 ไบต์สำหรับแต่ละสัญลักษณ์นั้นเปลืองเนื้อที่มากเกินไปทำไมเราจะใช้มันในสถานการณ์ประจำวัน

ในใจของฉันปัญหาส่วนใหญ่ปรากฏขึ้นจากความจริงที่ว่าซอฟต์แวร์บางตัวตกอยู่ภายใต้มาตรฐาน Unicode แต่ไม่รวดเร็วในการแก้ไขสถานการณ์ Opera, Windows, Python, Qt - ทั้งหมดปรากฏขึ้นก่อนที่ UTF-16 จะกลายเป็นที่รู้จักอย่างกว้างขวางหรือแม้กระทั่งมีอยู่จริง ฉันสามารถยืนยันได้ว่าใน Opera, Windows Explorer และ Notepad ไม่มีปัญหากับตัวละครนอก BMP อีกต่อไป (อย่างน้อยในพีซีของฉัน) แต่อย่างไรก็ตามหากโปรแกรมไม่รู้จักคู่ตัวแทนแทนพวกเขาจะไม่ใช้ UTF-16 ปัญหาใด ๆ ก็ตามที่เกิดขึ้นจากการจัดการกับโปรแกรมดังกล่าวพวกเขาไม่มีอะไรเกี่ยวข้องกับ UTF-16 เอง

อย่างไรก็ตามฉันคิดว่าปัญหาของซอฟต์แวร์รุ่นเก่าที่สนับสนุน BMP เพียงอย่างเดียวนั้นค่อนข้างเกินจริง อักขระนอก BMP พบเฉพาะในกรณีและพื้นที่ที่เฉพาะเจาะจงเท่านั้น จากคำถามที่พบบ่อยอย่างเป็นทางการของยูนิโค้ด "แม้ในเอเชียตะวันออกข้อความการเกิดตัวแทนคู่ควรจะน้อยกว่า 1% ของการจัดเก็บข้อความโดยเฉลี่ย" แน่นอนว่าตัวละครนอก BMP ไม่ควรถูกมองข้ามเพราะโปรแกรมนั้นไม่สอดคล้องกับ Unicode แต่โปรแกรมส่วนใหญ่ไม่ได้มีไว้สำหรับการทำงานกับข้อความที่มีตัวอักษรดังกล่าว นั่นเป็นเหตุผลว่าทำไมหากพวกเขาไม่สนับสนุนมันก็ไม่เป็นที่พอใจ แต่ไม่ใช่ความหายนะ

ทีนี้ลองพิจารณาทางเลือกอื่น หากไม่มี UTF-16 เราจะไม่มีการเข้ารหัสที่เหมาะสำหรับข้อความที่ไม่ใช่ ASCII และซอฟต์แวร์ทั้งหมดที่สร้างขึ้นสำหรับ UCS-2 จะต้องได้รับการออกแบบใหม่ทั้งหมดเพื่อให้สอดคล้องกับ Unicode หลังส่วนใหญ่มีแนวโน้มที่จะชะลอการยอมรับ Unicode เท่านั้น นอกจากนี้เราจะไม่สามารถรักษาความสามารถในการใช้งานกับข้อความใน UCS-2 เช่นเดียวกับ UTF-8 ที่เกี่ยวข้องกับ ASCII

ทีนี้ถ้าทิ้งประเด็นที่เป็นมรดกทั้งหมดเอาไว้สิ่งที่ขัดแย้งกับการเข้ารหัสนั้นคืออะไร? ฉันสงสัยจริงๆว่านักพัฒนาทุกวันนี้ไม่รู้ว่า UTF-16 นั้นมีความยาวผันแปรได้ถูกเขียนขึ้นทุกที่ที่มีวิกิพีเดีย UTF-16 นั้นแยกได้ยากกว่า UTF-8 น้อยมากถ้ามีคนชี้ให้เห็นความซับซ้อนว่าเป็นปัญหาที่เป็นไปได้ นอกจากนี้ยังเป็นเรื่องที่ผิดที่คิดว่ามันจะเลอะง่ายด้วยการกำหนดความยาวของสตริงใน UTF-16 เท่านั้น หากคุณใช้ UTF-8 หรือ UTF-32 คุณควรทราบว่าจุดโค้ด Unicode หนึ่งจุดนั้นไม่ได้แปลว่าตัวละครตัวเดียว นอกจากนั้นฉันไม่คิดว่ามันจะมีอะไรมากมายที่จะต่อต้านการเข้ารหัส

ดังนั้นฉันไม่คิดว่าการเข้ารหัสเองควรถือว่าเป็นอันตราย UTF-16 คือการประนีประนอมระหว่างความเรียบง่ายและความเป็นปึกแผ่นและไม่มีอันตรายในการใช้สิ่งที่จำเป็นซึ่งเป็นสิ่งจำเป็น ในบางกรณีคุณต้องยังคงใช้งานร่วมกับ ASCII ได้และคุณต้องใช้ UTF-8 ในบางกรณีคุณต้องการทำงานกับ Han ideographs และประหยัดพื้นที่โดยใช้ UTF-16 ในบางกรณีคุณต้องนำเสนออักขระสากลที่กำหนด การเข้ารหัสความยาว ใช้สิ่งที่เหมาะสมกว่าเพียงทำอย่างถูกต้อง

หลายปีที่ Windows ทำงานให้เป็นสากลโดยเฉพาะอย่างยิ่งในภาษาเอเชียตะวันออกอาจทำให้ฉันเสียหาย แต่ฉันพึ่งพา UTF-16 สำหรับการแทนสตริงภายในโปรแกรมไปยังโปรแกรมและ UTF-8 สำหรับเครือข่ายหรือการจัดเก็บไฟล์ของเอกสารที่เหมือนข้อความธรรมดา ปกติแล้ว UTF-16 จะสามารถประมวลผลได้เร็วขึ้นบน Windows ดังนั้นนี่คือประโยชน์หลักของการใช้ UTF-16 ใน Windows

การก้าวกระโดดสู่ UTF-16 ช่วยปรับปรุงความเพียงพอของผลิตภัณฑ์โดยเฉลี่ยที่จัดการกับข้อความระหว่างประเทศ มีเพียงไม่กี่กรณีที่แคบเมื่อคู่ตัวแทนจะต้องพิจารณา (การลบแทรกและทำลายเส้นโดยทั่วไป) และกรณีเฉลี่ยส่วนใหญ่เป็นตรงผ่าน และแตกต่างจากการเข้ารหัสก่อนหน้านี้เช่นตัวแปร JIS, UTF-16 จำกัด คู่ตัวแทนให้อยู่ในช่วงที่แคบมากดังนั้นการตรวจสอบจึงรวดเร็วมากและทำงานไปข้างหน้าและข้างหลัง

จริงอยู่ที่มันเป็น UTF-8 ที่เข้ารหัสอย่างรวดเร็วเช่นกัน แต่ยังมีแอปพลิเคชั่น UTF-8 ที่แตกหักจำนวนมากที่เข้ารหัสคู่ตัวแทนแทนอย่างไม่ถูกต้องเป็นสองลำดับ UTF-8 ดังนั้น UTF-8 จึงไม่รับประกันความรอดเช่นกัน

IE จัดการคู่ของตัวแทนเสมือนได้ดีพอสมควรตั้งแต่ปี 2000 เป็นต้นไปแม้ว่าโดยทั่วไปแล้วมันจะแปลงพวกมันจากหน้า UTF-8 ไปเป็น UTF-16 ที่เป็นตัวแทนภายใน ฉันค่อนข้างแน่ใจว่า Firefox ได้รับมันถูกต้องเช่นกันดังนั้นฉันไม่สนใจสิ่งที่ Opera ทำ

UTF-32 (aka UCS4) นั้นไม่มีประโยชน์สำหรับแอพพลิเคชั่นส่วนใหญ่เนื่องจากเป็นพื้นที่ที่มีความต้องการสูง

UTF-8 นั้นเป็นวิธีที่แน่นอนซึ่งอาจมาพร้อมกับ UTF-32 สำหรับการใช้งานภายในในอัลกอริทึมที่ต้องการการเข้าถึงแบบสุ่มประสิทธิภาพสูง (แต่ไม่สนใจการรวมตัวอักษร)

ทั้ง UTF-16 และ UTF-32 (รวมถึงตัวแปร LE / BE ของพวกเขา) ประสบปัญหาของ endianess ดังนั้นจึงไม่ควรใช้ภายนอก

UTF-16? อันตรายอย่างแน่นอน เพียงแค่เม็ดเกลือของฉันที่นี่ แต่มีการเข้ารหัสข้อความที่ยอมรับได้สามรายการในโปรแกรม:

• ASCII: เมื่อจัดการกับสิ่งต่าง ๆ ในระดับต่ำ (เช่น: ไมโครคอนโทรลเลอร์) ที่ไม่สามารถจ่ายได้ดีกว่า
• UTF8: ที่เก็บข้อมูลในสื่อที่มีความกว้างคงที่เช่นไฟล์

• codepoints จำนวนเต็ม ("CP"?): อาร์เรย์ของจำนวนเต็มที่ใหญ่ที่สุดที่สะดวกสำหรับภาษาการเขียนโปรแกรมและแพลตฟอร์มของคุณ (สลายตัวไปเป็น ASCII ในขีด จำกัด ของหน่วยความจำต่ำ) ควรเป็น int32 ในคอมพิวเตอร์รุ่นเก่าและ int64 ในทุกอย่างที่มีการระบุที่อยู่ 64 บิต

• เห็นได้ชัดว่าส่วนต่อประสานกับรหัสดั้งเดิมใช้การเข้ารหัสที่จำเป็นเพื่อให้รหัสเดิมทำงานได้

Unicodeกำหนดรหัสได้สูงสุด 0x10FFFF (1,114,112 รหัส) แอปพลิเคชันทั้งหมดที่ทำงานในสภาพแวดล้อมหลายภาษาที่จัดการกับสตริง / ชื่อไฟล์ ฯลฯ ควรจัดการอย่างถูกต้อง

Utf-16 : ครอบคลุมเฉพาะ 1,112,064 รหัส ถึงแม้ว่าส่วนท้ายของUnicodeจะมาจากเครื่องบิน 15-16 (พื้นที่ใช้งานส่วนตัว) มันไม่สามารถเติบโตได้อีกในอนาคตยกเว้นการทำลายแนวคิดUtf-16

Utf-8 : ครอบคลุมในทางทฤษฎี 2,216,757,376 รหัส ช่วงปัจจุบันของรหัสUnicodeสามารถแสดงด้วยลำดับสูงสุด 4 ไบต์ มันไม่ได้ประสบกับปัญหาการสั่งซื้อไบต์มันเป็น "เข้ากันได้" กับ ascii

Utf-32 : ครอบคลุมตามหลักวิชา 2 ^ 32 = 4,294,967,296 รหัส ขณะนี้ยังไม่ได้เข้ารหัสความยาวผันแปรและอาจจะไม่เป็นในอนาคต

ข้อเท็จจริงเหล่านั้นอธิบายตนเอง ฉันไม่เข้าใจการสนับสนุนการใช้งานUtf-16ทั่วไป มันเป็นความยาวแปรผันเข้ารหัส (ไม่สามารถเข้าถึงได้โดยดัชนี) มันมีปัญหาที่จะครอบคลุมช่วงUnicodeทั้งหมดแม้ในปัจจุบันต้องมีการจัดการลำดับไบต์เป็นต้นฉันไม่เห็นข้อได้เปรียบใด ๆ ยกเว้นว่ามันถูกใช้ใน Windows และบางอย่าง สถานที่อื่น ๆ. แม้ว่าเมื่อเขียนโค้ดหลายแพลตฟอร์มก็น่าจะดีกว่าถ้าใช้Utf-8แบบดั้งเดิมและทำการแปลงเฉพาะที่จุดสิ้นสุดในลักษณะที่ขึ้นกับแพลตฟอร์ม (ตามที่แนะนำไว้แล้ว) เมื่อจำเป็นต้องเข้าถึงโดยตรงโดยใช้ดัชนีและหน่วยความจำไม่ใช่ปัญหาควรใช้Utf-32

ปัญหาหลักคือโปรแกรมเมอร์จำนวนมากที่เกี่ยวข้องกับ Windows Unicode = Utf-16ไม่ทราบหรือเพิกเฉยต่อความจริงที่ว่ามีการเข้ารหัสความยาวแปรผัน

วิธีการก็มักจะอยู่ใน* ระวังแพลตฟอร์มที่ดีงาม, สาย C (char *) ตีความว่าเป็นUTF-8เข้ารหัสสตริงคกว้าง (wchar_t *) ตีความว่าเป็นUTF-32

เพิ่มลงในรายการ:

สถานการณ์ที่นำเสนอนั้นง่าย (ยิ่งง่ายกว่าที่ฉันจะนำเสนอที่นี่มากกว่าเดิม!): 1. กล่องข้อความ WinForms ตั้งอยู่บนแบบฟอร์มเปล่า แต่ก็มี MaxLength ตั้งค่าเป็น20

2. ผู้ใช้พิมพ์ลงในกล่องข้อความหรืออาจวางข้อความลงไป

3. ไม่ว่าคุณจะพิมพ์หรือวางลงในกล่องข้อความคุณถูก จำกัด ไว้ที่ 20 แม้ว่ามันจะส่งเสียงบี๊บเกินกว่า 20 ข้อความ (เห็นนี่ YMMV ฉันเปลี่ยนรูปแบบเสียงของฉันเพื่อให้ผลนั้น!)

4. ข้อความขนาดเล็กจะถูกส่งไปที่อื่นเพื่อเริ่มการผจญภัยที่น่าตื่นเต้น

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

ฉันตั้งชื่อรูปแบบMagic Carpet Rideเพื่อช่วยเยียวยาความเบื่อหน่าย

สิ่งนี้ไม่ได้ผลสำหรับสิ่งที่คุ้มค่า

ดังนั้นฉันจึงป้อน ตัวอักษร20ตัวต่อไปนี้ลงในแบบฟอร์มMagic Carpet Rideของฉัน:

0123401234012340123 𠀀

เอ่อโอ้.

ตัวละครตัวสุดท้ายนั่นคือ U + 20000 ซึ่งเป็นตัวเสริมนามสกุล B ตัวแรกของ Unicode (หรือที่ U + d840 U + dc00 ให้กับเพื่อนสนิทของเขาซึ่งเขาไม่ละอายที่จะถูก disrobed เหมือนตอนก่อน) ....

และตอนนี้เรามีเกมบอล

เพราะเมื่อTextBox.MaxLengthพูดถึง

รับหรือตั้งค่าจำนวนอักขระสูงสุดที่สามารถป้อนด้วยตนเองลงในกล่องข้อความ

ความหมายจริงๆคืออะไร

รับหรือตั้งค่าจำนวนสูงสุดของหน่วยรหัส UTF-16 LE ที่สามารถป้อนด้วยตนเองลงในกล่องข้อความด้วยตนเองและจะตัดทอนอึชีวิตอย่างไร้ความปราณีออกจากสตริงใด ๆ ที่พยายามเล่นเกม cutesy ด้วยความคิดเชิงภาษาที่มีเพียงคนที่หลงไหล เพื่อนชาวแคปแลนจะรู้สึกไม่พอใจ (เขาต้องออกไปอีก!)

ฉันจะลองและดูเกี่ยวกับการอัปเดตเอกสาร ....
ผู้อ่านปกติที่จำชุดUCS-2 ถึง UTF-16ของฉันจะสังเกตความไม่พอใจของฉันด้วยความคิดที่เรียบง่ายของTextBox.MaxLengthและวิธีจัดการกับกรณีนี้ให้น้อยที่สุด ที่ซึ่งพฤติกรรมแบบ draconian ของมันสร้างลำดับที่ผิดกฎหมายหนึ่งที่ส่วนอื่น ๆ ของ. Net Framework อาจโยน

• System.Text.EncoderFallbackException: ไม่สามารถแปลอักขระ Unicode \ uD850 ที่ดัชนี 0 ไปยังหน้ารหัสที่ระบุ *

ข้อยกเว้นถ้าคุณส่งสตริงนี้ที่อื่นใน. Net Framework (ขณะที่ Dan Thompson เพื่อนร่วมงานของฉันกำลังทำอยู่)

ตอนนี้ก็โอเคบางทีUCS-2 ถึง UTF-16 ซีรีส์แบบเต็มนั้นก็ไม่สามารถเข้าถึงได้มากมาย
แต่มันไม่สมเหตุสมผลที่จะคาดหวังว่า TextBox Text จะไม่สร้าง System.Stringที่จะไม่ทำให้ส่วนอื่นของ. Net Framework โยน? ฉันหมายความว่ามันไม่เหมือนมีโอกาสในรูปแบบของเหตุการณ์บางอย่างในตัวควบคุมที่บอกคุณถึงการตัดทอนที่กำลังจะเกิดขึ้นซึ่งคุณสามารถเพิ่มการตรวจสอบความถูกต้องได้อย่างชาญฉลาด - การตรวจสอบว่าตัวควบคุมไม่สนใจ ฉันจะบอกว่าการควบคุมพังค์นี้เป็นการละเมิดสัญญาความปลอดภัยซึ่งอาจนำไปสู่ปัญหาด้านความปลอดภัยหากคุณสามารถเรียนทำให้เกิดข้อยกเว้นที่ไม่คาดคิดในการยกเลิกแอปพลิเคชันเป็นการปฏิเสธบริการ ทำไมกระบวนการ WinForms หรือวิธีการหรืออัลกอริทึมหรือเทคนิคใด ๆ ควรให้ผลลัพธ์ที่ไม่ถูกต้อง

ที่มา: Michael S. Kaplan MSDN Blog

ฉันไม่จำเป็นต้องพูดว่า UTF-16 เป็นอันตราย มันไม่ได้สวยงาม แต่มันมีจุดประสงค์ในการใช้งานร่วมกันได้กับ UCS-2 เช่นเดียวกับ GB18030 กับ GB2312 และ UTF-8 ทำกับ ASCII

แต่การเปลี่ยนแปลงโครงสร้างพื้นฐานของ Unicode ในช่วงกลางคันหลังจาก Microsoft และ Sun ได้สร้าง API ขนาดใหญ่รอบตัวอักษร 16 บิตเป็นอันตราย ความล้มเหลวในการแพร่กระจายการรับรู้ของการเปลี่ยนแปลงเป็นอันตรายมากขึ้น

UTF-16 คือการประนีประนอมที่ดีที่สุดระหว่างการจัดการและพื้นที่และนั่นเป็นเหตุผลว่าทำไมแพลตฟอร์มหลักส่วนใหญ่ (Win32, Java, .NET) จึงใช้เพื่อการแสดงสตริงภายใน

ฉันไม่เคยเข้าใจประเด็นของ UTF-16 หากคุณต้องการตัวแทนที่ประหยัดพื้นที่มากที่สุดให้ใช้ UTF-8 หากคุณต้องการให้ข้อความเป็นความยาวคงที่ให้ใช้ UTF-32 หากคุณไม่ต้องการให้ใช้ UTF-16 ที่แย่ไปกว่านั้นเนื่องจากตัวอักษรธรรมดา (ระนาบหลายภาษาพื้นฐาน) ใน UTF-16 นั้นพอดีในจุดรหัสเดียวจุดบกพร่องที่คิดว่า UTF-16 นั้นมีความยาวคงที่จะละเอียดและหายากในขณะที่ถ้าคุณพยายามทำ ด้วย UTF-8 รหัสของคุณจะล้มเหลวอย่างรวดเร็วและดังทันทีที่คุณพยายามทำให้เป็นสากล

_{เนื่องจากฉันยังไม่สามารถแสดงความคิดเห็นได้ฉันโพสต์สิ่งนี้เป็นคำตอบเนื่องจากดูเหมือนว่าฉันไม่สามารถติดต่อผู้เขียนutf8everywhere.orgได้ มันเป็นความอัปยศที่ฉันไม่ได้รับสิทธิ์ความคิดเห็นโดยอัตโนมัติเนื่องจากฉันมีชื่อเสียงเพียงพอในการแลกเปลี่ยนสแต็กอื่น ๆ}

นี่เป็นความเห็นต่อความคิดเห็น: ใช่ UTF-16 ควรได้รับการพิจารณาคำตอบที่เป็นอันตราย

แก้ไขเพียงเล็กน้อย:

เพื่อป้องกันไม่ให้คนหนึ่งบังเอิญผ่าน UTF-8 char*เข้ามาในรุ่น ANSI-สตริงของฟังก์ชั่นที่ใช้ Windows API หนึ่งควรกำหนดไม่ได้UNICODE ฟังก์ชั่นแผนที่เหมือนจะไม่ได้ไป แต่การกำหนดจะดูแลหลัง เพื่อพิสูจน์สิ่งนี้มาจากส่วนหัวของ MS Visual Studio 2005 :_UNICODE_UNICODE_tcslenwcslenMessageBoxMessageBoxWUNICODEWinUser.h

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

utf8everywhere.orgที่ต่ำมากข้อผิดพลาดนี้ควรได้รับการแก้ไขใน

ข้อเสนอแนะ:

บางทีคู่มือควรมีตัวอย่างของการใช้โครงสร้างข้อมูลแบบ Wide-string เพื่อทำให้พลาด / ลืมได้ง่ายขึ้น การใช้โครงสร้างข้อมูลแบบ Wide-string ด้านบนของการใช้ฟังก์ชั่น Wide-string ทำให้มีความเป็นไปได้น้อยที่หนึ่งจะเรียกรุ่น ANSI-string ของฟังก์ชันดังกล่าวโดยไม่ตั้งใจ

ตัวอย่างของตัวอย่าง:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

บางคนกล่าวว่า UCS4 และ UTF-32 เหมือนกัน ไม่เช่นนั้น แต่ฉันรู้ว่าคุณหมายถึงอะไร หนึ่งในนั้นคือการเข้ารหัสของอีกอันหนึ่ง ฉันหวังว่าพวกเขาจะคิดว่าจะระบุ endianness จากครั้งแรกดังนั้นเราจะไม่ได้ต่อสู้ endianess ต่อสู้ที่นี่เช่นกัน พวกเขาไม่เห็นว่ามาหรือไม่ อย่างน้อย UTF-8 จะเหมือนกันทุกที่ (ยกเว้นบางคนกำลังติดตามข้อมูลจำเพาะดั้งเดิมที่มีขนาด 6 ไบต์)

หากคุณใช้ UTF-16 คุณต้องรวมการจัดการสำหรับตัวอักษรหลายไบต์ คุณไม่สามารถไปที่อักขระ Nth ได้โดยการทำดัชนี 2N เป็นอาร์เรย์ไบต์ คุณต้องเดินหรือมีตัวอักษร มิฉะนั้นคุณจะเขียนข้อผิดพลาด

ข้อมูลจำเพาะฉบับร่างปัจจุบันของ C ++ บอกว่า UTF-32 และ UTF-16 สามารถมีรูปแบบที่แตกต่างกันเล็กน้อย, แบบปลายใหญ่และแบบไม่ระบุรายละเอียด จริงๆ? ถ้า Unicode ได้ระบุว่าทุกคนต้องทำตัวเล็ก ๆ น้อย ๆ ตั้งแต่ต้นมันก็จะง่ายขึ้น (ฉันจะได้ดีกับ big-endian เช่นกัน.) บางคนใช้มันในทางหนึ่งอื่น ๆ และตอนนี้เรากำลังติดอยู่กับความโง่เขลาสำหรับอะไร บางครั้งมันก็น่าอายที่เป็นวิศวกรซอฟต์แวร์

ฉันไม่คิดว่ามันจะเป็นอันตรายหากนักพัฒนามีความระมัดระวังเพียงพอ
และพวกเขาควรยอมรับการแลกเปลี่ยนนี้หากพวกเขารู้ดีเช่นกัน

ในฐานะนักพัฒนาซอฟต์แวร์ชาวญี่ปุ่นฉันพบว่า UCS-2 มีขนาดใหญ่พอและ จำกัด พื้นที่ได้ง่ายกว่าตรรกะและลดหน่วยความจำรันไทม์ดังนั้นการใช้ utf-16 ภายใต้ข้อ จำกัด UCS-2 ก็ถือว่าดีพอ

มีระบบไฟล์หรือแอพพลิเคชั่นอื่น ๆ ที่ถือว่า codepoints และ bytes เป็นสัดส่วนดังนั้นจำนวน codepoint แบบดิบสามารถรับประกันได้ว่าจะพอดีกับที่เก็บข้อมูลขนาดคงที่

ตัวอย่างหนึ่งคือNTFS และ VFAT ที่ระบุ UCS-2เป็นการเข้ารหัสที่เก็บข้อมูลชื่อไฟล์

หากตัวอย่างเหล่านั้นต้องการขยายเพื่อรองรับ UCS-4 ฉันสามารถตกลงใช้ utf-8 สำหรับทุกสิ่งได้ แต่ความยาวคงที่มีจุดที่ดีเช่น:

1. สามารถรับประกันขนาดตามความยาว (ขนาดข้อมูลและความยาว codepoint เป็นสัดส่วน)
2. สามารถใช้หมายเลขการเข้ารหัสสำหรับการค้นหาแฮช
3. ข้อมูลที่ไม่บีบอัดมีขนาดที่สมเหตุสมผล (เมื่อเทียบกับ utf-32 / UCS-4)

ในอนาคตเมื่อหน่วยความจำ / กำลังการประมวลผลราคาถูกแม้ในอุปกรณ์ฝังใด ๆ เราอาจยอมรับว่าอุปกรณ์ช้าลงเล็กน้อยสำหรับการแคชที่ผิดพลาดหรือการผิดพลาดของหน้าและการใช้หน่วยความจำเพิ่มเติม แต่สิ่งนี้จะเกิดขึ้นในอนาคตอันใกล้นี้

"หนึ่งในการเข้ารหัสที่นิยมมากที่สุด UTF-16 ถือว่าเป็นอันตรายหรือไม่"

ค่อนข้างจะเป็นไปได้ แต่ทางเลือกไม่ควรถูกมองว่าดีกว่ามากนัก

ปัญหาพื้นฐานคือมีแนวคิดที่แตกต่างกันมากมายเกี่ยวกับ: ร่ายมนตร์, อักขระ, codepoints และลำดับไบต์ การทำแผนที่ระหว่างสิ่งเหล่านี้ไม่ใช่เรื่องไร้สาระแม้แต่ความช่วยเหลือของไลบรารีการทำให้เป็นมาตรฐาน (ตัวอย่างเช่นตัวละครบางตัวในภาษายุโรปที่เขียนด้วยสคริปต์แบบละตินไม่ได้เขียนด้วยรหัส Unicode ตัวเดียวและนั่นคือจุดสิ้นสุดของความซับซ้อนที่เรียบง่ายกว่า!) สิ่งนี้หมายความว่าการได้รับทุกอย่างถูกต้องค่อนข้างน่าอัศจรรย์ ยาก; คาดว่าจะมีข้อผิดพลาดที่แปลกประหลาด (และแทนที่จะส่งเสียงครวญครางที่นี่ให้ผู้ดูแลระบบของซอฟต์แวร์ที่เกี่ยวข้องทราบ)

วิธีเดียวที่ UTF-16 ถือได้ว่าเป็นอันตรายเมื่อเทียบกับ UTF-8 ก็คือมันมีวิธีการเข้ารหัสรหัสที่แตกต่างออกไปนอก BMP (เป็นคู่ของตัวแทน) หากรหัสต้องการเข้าถึงหรือวนซ้ำตามจุดรหัสหมายความว่าจำเป็นต้องตระหนักถึงความแตกต่าง OTOH หมายความว่าเนื้อความที่มีอยู่ของรหัสที่มีอยู่ซึ่งสมมติว่า "ตัวอักษร" สามารถใส่ลงในปริมาณสองไบต์ได้ - โดยทั่วไปหากผิดสมมุติฐาน - อย่างน้อยก็สามารถทำงานต่อไปได้โดยไม่ต้องสร้างใหม่ทั้งหมด อย่างน้อยที่สุดคุณก็จะได้เห็นตัวละครเหล่านั้นที่ไม่ได้รับการจัดการที่ถูกต้อง!

ฉันหันคำถามของคุณไปที่หัวแล้วบอกว่า Shebang ทั้งหมดของ Unicode ควรได้รับการพิจารณาว่าเป็นอันตรายและทุกคนควรใช้การเข้ารหัสแบบ 8 บิตยกเว้นว่าฉันเคยเห็น (มากกว่า 20 ปีที่ผ่านมา) ที่นำไปสู่: น่ากลัว ความสับสนเกี่ยวกับการเข้ารหัส ISO 8859 ต่างๆรวมถึงชุดทั้งหมดที่ใช้สำหรับ Cyrillic และชุด EBCDIC และ ... ดี Unicode สำหรับความผิดพลาดทั้งหมดของมัน หากเพียง แต่มันก็ไม่ได้เป็นการประนีประนอมที่น่ารังเกียจระหว่างความเข้าใจผิดของประเทศต่างๆ