UTF-16

จากวิกิพีเดีย สารานุกรมเสรี
ข้ามไปที่การนำทาง ข้ามไปที่การค้นหา
UTF-16
Unifont เต็ม Map.png
จุดโค้ด Unicode 2 16จุดแรก แถบสีเทาทึบบริเวณด้านล่างคือครึ่งตัวแทนที่ใช้โดย UTF-16 (พื้นที่สีขาวด้านล่างแถบคือพื้นที่ใช้งานส่วนตัว )
ภาษาระหว่างประเทศ
มาตรฐานมาตรฐานยูนิโค้ด
การจัดหมวดหมู่รูปแบบการแปลง Unicode , การเข้ารหัสตัวแปรความกว้าง
ขยายUCS-2
แปลง / เข้ารหัสISO 10646 ( ยูนิโค้ด )

UTF-16 ( รูปแบบการแปลงUnicode 16 บิต ) เป็นการเข้ารหัสอักขระที่สามารถเข้ารหัสจุดรหัสอักขระที่ถูกต้องทั้งหมด 1,112,064 จุดของ Unicode (อันที่จริงจำนวนจุดรหัสนี้กำหนดโดยการออกแบบ UTF-16) การเข้ารหัสเป็นตัวแปรที่มีความยาวเป็นจุดรหัสจะถูกเข้ารหัสด้วยหนึ่งหรือสอง 16 บิตหน่วยรหัส UTF-16 เกิดขึ้นจากการเข้ารหัสแบบ 16 บิตแบบความกว้างคงที่ที่ล้าสมัยก่อนหน้านี้ ซึ่งปัจจุบันรู้จักกันในชื่อUCS-2 (สำหรับชุดอักขระสากลขนาด 2 ไบต์) เมื่อเห็นได้ชัดว่าจำเป็นต้องใช้จุดโค้ดมากกว่า 2 16 (65,536) [1]

UTF-16 จะใช้ภายในระบบเช่นMicrosoft Windowsการเขียนโปรแกรมภาษาจาวาและจาวาสคริปต์ / ECMAScript นอกจากนี้ยังมักใช้สำหรับข้อความธรรมดาและไฟล์ข้อมูลการประมวลผลคำใน Microsoft Windows มันเป็นเรื่องที่ไม่ค่อยได้ใช้สำหรับไฟล์บนUnix เหมือนระบบ ในเดือนพฤษภาคม 2019 Microsoft ได้กลับรายการโดยเน้นเฉพาะ UTF-16 สำหรับ Unicode เท่านั้น สำหรับแอปพลิเคชัน Windows Microsoft แนะนำและสนับสนุนUTF-8 (เช่น สำหรับแอปUniversal Windows Platform (UWP) [2] )

UTF-16 เป็นเว็บการเข้ารหัสเข้ากันไม่ได้มีเพียงASCII , [3]และไม่เคยได้รับความนิยมบนเว็บที่มันจะถูกใช้โดยภายใต้ 0.002% (น้อยกว่า 1000 ร้อยละ 1) ของหน้าเว็บ [4] UTF-8โดยการเปรียบเทียบ ถูกใช้โดย 97% ของหน้าเว็บทั้งหมด [5]เว็บ Hypertext การประยุกต์ใช้เทคโนโลยีการทำงานกลุ่ม (WHATWG)พิจารณา UTF-8 "การเข้ารหัสที่จำเป็นสำหรับ [ข้อความ] ทั้งหมด" และว่าสำหรับเหตุผลด้านความปลอดภัยการใช้งานเบราว์เซอร์ไม่ควรใช้ UTF-16 [6]

ประวัติ

ในช่วงปลายทศวรรษ 1980 งานเริ่มพัฒนาการเข้ารหัสแบบสม่ำเสมอสำหรับ "ชุดอักขระสากล" ( UCS ) ที่จะแทนที่การเข้ารหัสเฉพาะภาษารุ่นก่อนหน้าด้วยระบบที่ประสานกันเพียงระบบเดียว เป้าหมายคือการรวมอักขระที่จำเป็นทั้งหมดจากภาษาส่วนใหญ่ของโลก รวมทั้งสัญลักษณ์จากโดเมนทางเทคนิค เช่น วิทยาศาสตร์ คณิตศาสตร์ และดนตรี แนวคิดดั้งเดิมคือการแทนที่การเข้ารหัสอักขระทั่วไป 256 ตัว ซึ่งต้องใช้ 1 ไบต์ต่ออักขระ ด้วยการเข้ารหัสโดยใช้ค่า 65,536 (2 16 ) ซึ่งต้องใช้ 2 ไบต์ (16 บิต) ต่ออักขระ

สองกลุ่มทำงานพร้อมกันคือISO/IEC JTC 1/SC 2และUnicode Consortiumซึ่งส่วนใหญ่เป็นตัวแทนของผู้ผลิตอุปกรณ์คอมพิวเตอร์ ทั้งสองกลุ่มพยายามซิงโครไนซ์การกำหนดอักขระเพื่อให้การเข้ารหัสที่กำลังพัฒนาสามารถทำงานร่วมกันได้ การเข้ารหัสแบบ 2 ไบต์แรกเริ่มเดิมเรียกว่า "Unicode" แต่ปัจจุบันเรียกว่า "UCS-2" [7]

เมื่อเห็นได้ชัดว่า 2 16อักขระไม่เพียงพอ[1] IEEEได้เพิ่มพื้นที่ 31 บิตที่ใหญ่กว่าและการเข้ารหัส ( UCS-4 ) ที่ต้องใช้ 4 ไบต์ต่ออักขระ สิ่งนี้ถูกต่อต้านโดยUnicode Consortiumเนื่องจาก 4 ไบต์ต่ออักขระทำให้เสียหน่วยความจำและพื้นที่ดิสก์เป็นจำนวนมาก และเนื่องจากผู้ผลิตบางรายลงทุนอย่างมากในเทคโนโลยี 2 ไบต์ต่ออักขระแล้ว โครงการการเข้ารหัส UTF-16 ได้รับการพัฒนาเป็นประนีประนอมและนำมาใช้กับรุ่น 2.0 ของมาตรฐาน Unicode ในเดือนกรกฎาคมปี 1996 [8]มันมีการระบุอย่างเต็มที่ใน RFC 2781 ตีพิมพ์ในปี 2000 โดยIETF [9] [10]

ในการเข้ารหัส UTF-16 จุดโค้ดที่น้อยกว่า 2 16จะถูกเข้ารหัสด้วยหน่วยรหัส 16 บิตเดียวซึ่งเท่ากับค่าตัวเลขของจุดโค้ด เช่นเดียวกับใน UCS-2 ที่เก่ากว่า จุดรหัสที่ใหม่กว่าหรือเท่ากับ 2 16ถูกเข้ารหัสโดยค่าผสมโดยใช้หน่วยรหัส 16 บิตสองหน่วย หน่วยรหัส 16 บิตสองหน่วยนี้ได้รับเลือกจากช่วงตัวแทน UTF-16 0xD800–0xDFFFซึ่งไม่เคยกำหนดให้กับอักขระมาก่อน ค่าในช่วงนี้ไม่ได้ใช้เป็นอักขระ และ UTF-16 ไม่ได้ให้วิธีการที่ถูกต้องตามกฎหมายในการเขียนโค้ดเป็นจุดโค้ดแต่ละรายการ ดังนั้นสตรีม UTF-16 จึงประกอบด้วยจุดโค้ด 16 บิตเดียวที่อยู่นอกช่วงตัวแทนเสมือนสำหรับจุดโค้ดในBasic Multilingual Plane(BMP) และคู่ของค่า 16 บิตภายในช่วงตัวแทนสำหรับจุดโค้ดเหนือ BMP

UTF-16 ระบุไว้ในเวอร์ชันล่าสุดของทั้งมาตรฐานสากล ISO/IEC 10646และ Unicode Standard "ตอนนี้ควรถือว่า UCS-2 ล้าสมัย ไม่ได้หมายถึงรูปแบบการเข้ารหัสใน 10646 หรือ Unicode Standard อีกต่อไป" [11]ไม่มีแผนในปี 2564 ที่จะขยาย UTF-16 เพื่อรองรับจุดรหัสจำนวนมากขึ้นหรือจุดรหัสแทนที่โดยตัวแทนเสมือน เนื่องจากจะเป็นการละเมิดนโยบายความเสถียรของ Unicode ในส่วนที่เกี่ยวกับหมวดหมู่ทั่วไปหรือจุดรหัสตัวแทน [12] (รูปแบบใด ๆ ที่ยังคงเป็นรหัสการซิงโครไนซ์ตัวเองจะต้องจัดสรรจุดรหัส BMP อย่างน้อยหนึ่งจุดเพื่อเริ่มลำดับ ไม่อนุญาตให้เปลี่ยนวัตถุประสงค์ของจุดรหัส)

คำอธิบาย

แต่ละจุดรหัส Unicode จะถูกเข้ารหัสไม่ว่าจะเป็นหนึ่งหรือสอง 16 บิตหน่วยรหัส วิธีการเหล่านี้รหัส 16 บิตจะถูกเก็บเป็นไบต์แล้วขึ้นอยู่กับ ' endiannessของไฟล์ข้อความหรือโปรโตคอลการสื่อสาร

"อักขระ" อาจต้องการตั้งแต่สองไบต์ถึงสิบสี่[13]หรือมากกว่านั้นในการบันทึก ตัวอย่างเช่นอักขระธงอีโมจิใช้เวลา 8 ไบต์ เนื่องจากเป็น "สร้างจากค่าสเกลาร์ Unicode" [14] (และค่าเหล่านั้นอยู่นอก BMP และแต่ละค่าต้องมี 4 ไบต์)

U+0000 เป็น U+D7FF และ U+E000 เป็น U+FFFF

ทั้ง UTF-16 และ UCS-2 เข้ารหัสจุดโค้ดในช่วงนี้เป็นหน่วยโค้ด 16 บิตเดี่ยวที่มีตัวเลขเท่ากับจุดโค้ดที่เกี่ยวข้อง จุดรหัสเหล่านี้ในBasic Multilingual Plane (BMP) เป็นจุดรหัสเดียวที่สามารถแสดงใน UCS-2 [ อ้างอิงจำเป็น ]สำหรับ Unicode 9.0 สคริปต์สมัยใหม่ที่ไม่ใช่ภาษาละตินเอเชีย ตะวันออกกลาง และแอฟริกาบางส่วนอยู่นอกช่วงนี้ เช่นเดียวกับอักขระ อีโมจิส่วนใหญ่

รหัสชี้จาก U+010000 ถึง U+10FFFF

จุดรหัสจากระนาบอื่น (เรียกว่าระนาบเสริม ) ถูกเข้ารหัสเป็นหน่วยรหัส 16 บิตสองหน่วยที่เรียกว่าคู่ตัวแทนโดยรูปแบบต่อไปนี้:

ตัวถอดรหัส UTF-16
ต่ำ
สูง
DC00 DC01    ...    DFFF
D800 010000 010001 ... 0103FF
D801 010400 010401 ... 0107FF
  เ
DBFF 10FC00 10FC01 ... 10FFFF
  • 0x10000 ถูกลบออกจากจุดโค้ด(U)โดยปล่อยให้ตัวเลข 20 บิต(U')อยู่ในช่วงเลขฐานสิบหก 0x00000–0xFFFFF หมายเหตุสำหรับวัตถุประสงค์เหล่านี้Uถูกกำหนดให้ไม่เกิน 0x10FFFF
  • บิตสิบสูง (ในช่วง 0x000-0x3FF) จะมีการเพิ่ม 0xD800 จะให้ครั้งแรก 16 บิตหน่วยรหัสหรือตัวแทนสูง (W1)ซึ่งจะอยู่ในช่วง0xD800-0xDBFF
  • บิตต่ำสิบ (ยังอยู่ในช่วง 0x000-0x3FF) จะมีการเพิ่ม 0xDC00 ที่จะให้ที่สอง 16 บิตหน่วยรหัสหรือตัวแทนต่ำ (W2)ซึ่งจะอยู่ในช่วง0xDC00-0xDFFF

จากภาพประกอบ การกระจายของU'ระหว่างW1และW2มีลักษณะดังนี้: [15]

U' = ปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปปป // U - 0x10000
W1 = 110110yyyyyyyyyy // 0xD800 + ปปปปปปปปปปปปปปปปปปป
W2 = 110111xxxxxxxxxx // 0xDC00 + xxxxxxxxxx

ตัวแทนสูงและตัวแทนต่ำนอกจากนี้ยังเป็นที่รู้จักกันในนาม "นำ" และ "ต่อท้าย" อุ้มท้องตามลำดับคล้ายคลึงกับไบต์ชั้นนำและต่อท้ายของ UTF-8 [16]

เนื่องจากช่วงสำหรับตัวแทนเสมือนสูง ( 0xD800–0xDBFF ) ตัวแทนเสมือนต่ำ ( 0xDC00–0xDFFF ) และอักขระ BMP ที่ถูกต้อง (0x0000–0xD7FF, 0xE000–0xFFFF) จะไม่ปะติดปะต่อจึงเป็นไปไม่ได้ที่ตัวแทนเสมือนจะจับคู่อักขระ BMP หรือสองติดหน่วยรหัสให้มีลักษณะเหมือนทางกฎหมายคู่ตัวแทนสิ่งนี้ทำให้การค้นหาง่ายขึ้นอย่างมาก นอกจากนี้ยังหมายความว่า UTF-16 กำลังซิงโครไนซ์ตัวเองกับคำ 16 บิต: ไม่ว่าหน่วยโค้ดจะเริ่มต้นอักขระหรือไม่ก็สามารถกำหนดได้โดยไม่ต้องตรวจสอบหน่วยโค้ดก่อนหน้า (เช่น ประเภทของหน่วยโค้ดสามารถกำหนดได้โดยช่วงของค่าที่ตก) UTF-8 แบ่งปันข้อดีเหล่านี้ แต่รูปแบบการเข้ารหัสแบบหลายไบต์ก่อนหน้าจำนวนมาก (เช่นShift JISและการเข้ารหัสแบบหลายไบต์ในเอเชียอื่นๆ) ไม่อนุญาตให้มีการค้นหาที่ชัดเจนและสามารถซิงโครไนซ์ได้โดยการแยกวิเคราะห์ใหม่ตั้งแต่เริ่มต้นสตริงเท่านั้น (UTF) -16 จะไม่ซิงโครไนซ์ตัวเองหากหนึ่งไบต์หายไปหรือหากการข้ามผ่านเริ่มต้นที่ไบต์สุ่ม)

เนื่องจากอักขระที่ใช้บ่อยที่สุดทั้งหมดอยู่ใน BMP การจัดการคู่ตัวแทนจึงมักไม่ได้รับการทดสอบอย่างละเอียด สิ่งนี้นำไปสู่จุดบกพร่องถาวรและช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้น แม้กระทั่งในซอฟต์แวร์แอปพลิเคชันที่ได้รับความนิยมและได้รับการตรวจสอบอย่างดี (เช่นCVE - 2008-2938 , CVE- 2012-2135 )

เครื่องบินเสริมประกอบด้วยอีโมจิสคริปต์ประวัติศาสตร์สัญลักษณ์ที่ใช้น้อยใช้น้อยจีน ideographs ฯลฯ ตั้งแต่การเข้ารหัสของเครื่องบินเสริมมี 20 บิตอย่างมีนัยสำคัญ (10 of 16 บิตในแต่ละสูงและอุ้มท้องต่ำ ) 2 20จุดรหัสสามารถ ถูกเข้ารหัสแบ่งเป็น 16 ระนาบ อันละ 2 16โค้ดพอยต์ รวมทั้งเครื่องบินแบบหลายภาษาพื้นฐานที่แยกจัดการเองแล้ว มีทั้งหมด 17 ลำ

U+D800 ถึง U+DFFF

มาตรฐาน Unicode จะสงวนค่าจุดโค้ดเหล่านี้ไว้อย่างถาวรสำหรับการเข้ารหัส UTF-16 ของตัวแทนเสมือนสูงและต่ำ และจะไม่มีวันกำหนดอักขระ ดังนั้นจึงไม่ควรมีเหตุผลในการเข้ารหัส มาตรฐาน Unicode อย่างเป็นทางการระบุว่าไม่มีรูปแบบ UTF รวมถึง UTF-16 ที่สามารถเข้ารหัสจุดรหัสเหล่านี้ได้ [ ต้องการการอ้างอิง ]

อย่างไรก็ตาม UCS-2, UTF-8 และUTF-32สามารถเข้ารหัสจุดรหัสเหล่านี้ด้วยวิธีที่ไม่สำคัญและชัดเจน และซอฟต์แวร์จำนวนมากทำเช่นนั้น[ ต้องการการอ้างอิง ]แม้ว่ามาตรฐานจะระบุว่าการจัดเตรียมดังกล่าวควรได้รับการปฏิบัติเป็น ข้อผิดพลาดในการเข้ารหัส [ ต้องการการอ้างอิง ]

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

ตัวอย่าง

ในการเข้ารหัส U+10437 (𐐷) เป็น UTF-16:

  • ลบ 0x10000 จากจุดโค้ด เหลือ 0x0437
  • สำหรับตัวแทนระดับสูง ให้เลื่อนไปทางขวาด้วย 10 (หารด้วย 0x400) แล้วบวก 0xD800 ส่งผลให้ 0x0001 + 0xD800 = 0xD801
  • สำหรับตัวแทนที่ต่ำ ใช้ 10 บิตต่ำ (เศษที่เหลือหารด้วย 0x400) แล้วเพิ่ม 0xDC00 ส่งผลให้ 0x0037 + 0xDC00 = 0xDC37

ในการถอดรหัส U+10437 (𐐷) จาก UTF-16:

  • ใช้ตัวแทนสูง (0xD801) และลบ 0xD800 จากนั้นคูณด้วย 0x400 ส่งผลให้ 0x0001 × 0x400 = 0x0400
  • ใช้ตัวแทนเสมือนต่ำ (0xDC37) และลบ 0xDC00 ส่งผลให้เป็น 0x37
  • เพิ่มผลลัพธ์ทั้งสองนี้เข้าด้วยกัน (0x0437) และสุดท้ายเพิ่ม 0x10000 เพื่อรับจุดรหัส UTF-32 ที่ถอดรหัสสุดท้าย 0x10437

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

อักขระ จุดรหัสไบนารี ไบนารี UTF-16
หน่วยรหัส ฐานสิบหก UTF-16
UTF-16BE
ฐานสิบหกไบต์
UTF-16LE
ฐานสิบหกไบต์
$ U+0024 0000 0000 0010 0100 0000 0000 0010 0100 0024 00 24 24 00
U+20AC 0010 0000 1010 1100 0010 0000 1010 1100 20AC 20 AC AC 20
U+10437 0001 0000 0100 0011 0111 1101 1000 0000 0001 1101 1100 0011 0111 D801 DC37 D8 01 DC 37 01 D8 37 DC
U+24B62 0010 0100 1011 0110 0010 1101 1000 0101 0010 1101 1111 0110 0010 D852 DF62 D8 52 DF 62 52 D8 62 DF

รูปแบบการเข้ารหัสลำดับไบต์

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

เพื่อช่วยในการระบุลำดับไบต์ของหน่วยโค้ดUTF-16อนุญาตให้Byte Order Mark (BOM) ซึ่งเป็นจุดโค้ดที่มีค่า U+FEFF นำหน้าค่าโค้ดจริงตัวแรก[nb 1] (U+FEFF เป็นช่องว่างที่ไม่มีความกว้างเป็นศูนย์ที่มองไม่เห็น/อักขระ ZWNBSP) [nb 2]หากสถาปัตยกรรม endian ของตัวถอดรหัสตรงกับตัวเข้ารหัส ตัวถอดรหัสจะตรวจจับค่า 0xFEFF แต่ตรงกันข้าม -endian decoder ตีความ BOM เป็นค่าที่ไม่ใช่อักขระ U+FFFE ที่สงวนไว้สำหรับจุดประสงค์นี้ ผลลัพธ์ที่ไม่ถูกต้องนี้เป็นคำแนะนำให้ทำการสลับไบต์สำหรับค่าที่เหลือ

หากไม่มี BOM RFC 2781 แนะนำ[nb 3]ให้ถือว่าการเข้ารหัส big-endian ในทางปฏิบัติ เนื่องจาก Windows ใช้ลำดับ little-endian โดยค่าเริ่มต้น แอปพลิเคชันจำนวนมากจึงใช้การเข้ารหัส little-endian นอกจากนี้ยังสามารถตรวจจับ endianness ได้โดยการค้นหา null bytes โดยสันนิษฐานว่าอักขระที่น้อยกว่า U+0100 นั้นเป็นเรื่องธรรมดามาก หากจำนวนไบต์ที่เท่ากัน (เริ่มต้นที่ 0) เป็นโมฆะแสดงว่าเป็น big-endian

มาตรฐานยังอนุญาตให้ระบุลำดับไบต์อย่างชัดเจนโดยระบุUTF-16BEหรือUTF-16LEเป็นประเภทการเข้ารหัส เมื่อมีการระบุลำดับไบต์อย่างชัดเจนในลักษณะนี้ BOM ไม่ควรนำหน้าข้อความโดยเฉพาะ และควรจัดการ U+FEFF ที่จุดเริ่มต้นเป็นอักขระ ZWNBSP แอปพลิเคชันส่วนใหญ่ละเว้น BOM ในทุกกรณี แม้จะมีกฎนี้

สำหรับโปรโตคอลอินเทอร์เน็ตIANAได้อนุมัติ "UTF-16", "UTF-16BE" และ "UTF-16LE" เป็นชื่อสำหรับการเข้ารหัสเหล่านี้ (ชื่อไม่คำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่) นามแฝงUTF_16หรือUTF16อาจมีความหมายในภาษาการเขียนโปรแกรมหรือซอฟต์แวร์แอปพลิเคชันบางอย่าง แต่ไม่ใช่ชื่อมาตรฐานในอินเทอร์เน็ตโปรโตคอล

การกำหนดที่คล้ายกันUCS-2BEและUCS-2LEจะใช้ในการแสดงรุ่นUCS 2

การใช้งาน

UTF-16 ใช้สำหรับข้อความใน OS API รุ่นปัจจุบันสนับสนุนทั้งหมดของMicrosoft Windows (และรวมอย่างน้อยตั้งแต่Windows CE / 2000 / XP / 2003 / Vista / 7 [17] ) รวมทั้งวินโดวส์ 10 ใน Windows XP ไม่มีจุดโค้ดเหนือ U+FFFF รวมอยู่ในแบบอักษรที่จัดส่งมาพร้อมกับ Windows สำหรับภาษายุโรป[18] [19]ระบบ Windows NTรุ่นเก่า(ก่อน Windows 2000) รองรับเฉพาะ UCS-2 เท่านั้น[20]ไฟล์และข้อมูลเครือข่ายมักเป็นการผสมผสานระหว่างการเข้ารหัสแบบ UTF-16, UTF-8 และไบต์ดั้งเดิม

แม้ว่าจะมีการรองรับ UTF-8 บางอย่างสำหรับแม้แต่ Windows XP [21]ก็ยังได้รับการปรับปรุง (โดยเฉพาะความสามารถในการตั้งชื่อไฟล์โดยใช้ UTF-8) ใน Windows 10 Insider build 17035 และการอัปเดตในเดือนเมษายน 2018 และในเดือนพฤษภาคม 2019 Microsoft แนะนำให้ใช้ซอฟต์แวร์แทน UTF-16 [2]

IBM iระบบปฏิบัติการกำหนดCCSID ( หน้ารหัส ) 13488 สำหรับ UCS 2 เข้ารหัสและ CCSID 1200 สำหรับการเข้ารหัส UTF-16 แต่ถือว่าระบบพวกเขาทั้งสองเป็น UTF-16 [22]

UTF-16 ถูกใช้โดยระบบปฏิบัติการQualcomm BREW ; .NETสภาพแวดล้อม; และQtข้ามแพลตฟอร์มกราฟิกเครื่องมือชุดเครื่องมือ

ระบบปฏิบัติการ Symbian ที่ใช้ในโทรศัพท์มือถือ Nokia S60 และโทรศัพท์มือถือ Sony Ericsson UIQใช้ UCS-2 โทรศัพท์มือถือiPhoneใช้ UTF-16 สำหรับบริการข้อความสั้นแทน UCS-2 ที่อธิบายไว้ในมาตรฐาน 3GPP TS 23.038 ( GSM ) และ IS-637 ( CDMA ) [23]

ระบบไฟล์โจเลียตที่ใช้ในแผ่น CD-ROMสื่อถอดรหัสชื่อไฟล์โดยใช้ UCS-2BE (ไม่เกินหกสิบสี่ตัวอักษร Unicode ต่อชื่อไฟล์)

หลามสภาพแวดล้อมภาษาอย่างเป็นทางการจะใช้ UCS 2 ภายในตั้งแต่รุ่น 2.0 แต่ UTF 8 ถอดรหัสที่ "Unicode" ผลิตถูกต้อง UTF-16 ตั้งแต่ Python 2.2 รองรับ Unicode บิลด์ "กว้าง" ซึ่งใช้ UTF-32 แทน [24]สิ่งเหล่านี้ใช้เป็นหลักบน Linux Python 3.3 จะไม่ใช้ UTF-16 อีกต่อไป แต่การเข้ารหัสที่ให้การแสดงข้อมูลที่กระชับที่สุดสำหรับสตริงที่กำหนดนั้นถูกเลือกจาก ASCII/Latin-1, UCS-2 และ UTF-32 [25]

Javaแต่เดิมใช้ UCS 2 และเพิ่ม UTF-16 สนับสนุนตัวอักษรเสริมในJ2SE 5.0

JavaScriptอาจใช้ UCS-2 หรือ UTF-16 [26]ของ ES2015 ได้มีการเพิ่มเมธอดสตริงและแฟล็กนิพจน์ทั่วไปลงในภาษาที่อนุญาตให้จัดการสตริงจากมุมมองที่เข้ารหัสแบบไม่เชื่อเรื่องพระเจ้า

ในหลายภาษา สตริงที่ยกมาจำเป็นต้องมีไวยากรณ์ใหม่สำหรับการอ้างอิงอักขระที่ไม่ใช่ BMP เนื่องจาก"\uXXXX"ไวยากรณ์สไตล์ C จำกัดตัวเองไว้ที่เลขฐานสิบหก 4 หลักอย่างชัดเจน ตัวอย่างต่อไปนี้แสดงไวยากรณ์สำหรับอักขระที่ไม่ใช่ BMP "𝄞" (U+1D11E, MUSICAL SYMBOL G CLEF) ที่พบบ่อยที่สุด (ใช้โดยC++ , C# , Dและภาษาอื่นๆ อีกหลายภาษา) คือการใช้ 'U' ตัวพิมพ์ใหญ่ที่มีเลขฐานสิบหก 8 หลัก เช่น"\U0001D11E". [27]ในนิพจน์ทั่วไป Java 7, ICUและ Perl "\x{1D11E}"ต้องใช้ไวยากรณ์ในทำนองเดียวกัน ในECMAScript 2015 (JavaScript) รูปแบบ Escape คือ"\u{1D11E}". ในหลายกรณี (เช่น Java นอกนิพจน์ทั่วไป) [28]วิธีเดียวที่จะได้อักขระที่ไม่ใช่ BMP คือการป้อนครึ่งตัวแทนทีละคน เช่น"\uD834\uDD1E"สำหรับ U+1D11E

การใช้งานสตริงตาม UTF-16 โดยทั่วไปจะกำหนดความยาวของสตริงและอนุญาตให้สร้างดัชนีในแง่ของหน่วยโค้ด 16 บิตเหล่านี้ไม่ใช่ในแง่ของจุดโค้ด จุดรหัสหรือหน่วยรหัสไม่สอดคล้องกับสิ่งที่ผู้ใช้อาจรู้จักว่าเป็น "ตัวละคร"; สิ่งที่ผู้ใช้ระบุว่าเป็นอักขระโดยทั่วไปอาจประกอบด้วยจุดโค้ดฐานและลำดับของการรวมอักขระ (หรืออาจเป็นลำดับของจุดโค้ดประเภทอื่น เช่น ฮันกึลที่เชื่อมติดกัน) – Unicode หมายถึงโครงสร้างนี้เป็นกราฟ คลัสเตอร์[29]  – และด้วยเหตุนี้ แอปพลิเคชันที่เกี่ยวข้องกับสตริง Unicode ไม่ว่าจะเข้ารหัสแบบใดก็ตาม จะต้องรับมือกับข้อเท็จจริงที่ว่ามันจำกัดความสามารถในการแยกและรวมสตริงตามอำเภอใจ

UCS-2 ยังรองรับโดยภาษาPHP [30]และ MySQL [7]

Swiftเวอร์ชัน 5 ซึ่งเป็นภาษาแอปพลิเคชันที่ Apple ต้องการ เปลี่ยนจาก UTF-16 เป็น UTF-8 เป็นการเข้ารหัสที่ต้องการ [31]

ดูเพิ่มเติม

หมายเหตุ

  1. ^ การ เข้ารหัส UTF-8 สร้างค่าไบต์ที่น้อยกว่า 0xFE อย่างเคร่งครัด ดังนั้นไบต์ใดในลำดับ BOM จะระบุการเข้ารหัสเป็น UTF-16 ด้วย (สมมติว่าไม่คาดหวัง UTF-32)
  2. ^ การ ใช้ U+FEFF เป็นอักขระ ZWNBSP แทนที่จะเป็น BOM ถูกเลิกใช้เพื่อสนับสนุน U+2060 (WORD JOINER); ดูคำถามที่พบบ่อยเกี่ยวกับ Byte Order Mark (BOM)ที่ unicode.org แต่ถ้าแอปพลิเคชันตีความ BOM เริ่มต้นเป็นอักขระ อักขระ ZWNBSP จะไม่ปรากฏ ดังนั้นผลกระทบจะน้อยที่สุด
  3. ^ RFC 2781ส่วนที่ 4.3 กล่าวว่าหากไม่มี BOM "ข้อความควรถูกตีความว่าเป็น big-endian" ตามมาตรา 1.2 ความหมายของคำว่า "ควรจะ" ถูกควบคุมโดย RFC 2119 ในเอกสารนั้น ส่วนที่ 3 กล่าวว่า "... อาจมีเหตุผลที่ถูกต้องในสถานการณ์เฉพาะที่จะเพิกเฉยต่อรายการใดรายการหนึ่ง แต่จะต้องเข้าใจความหมายทั้งหมดและชั่งน้ำหนักอย่างรอบคอบก่อนที่จะเลือกหลักสูตรอื่น"  

อ้างอิง

  1. ^ a b "UTF-16 คืออะไร" . ยูนิโค้ด Consortium Unicode, Inc สืบค้นเมื่อ29 มีนาคม 2018 .
  2. ^ "ใช้ของ Windows UTF-8 รหัสหน้า - การใช้งาน UWP" docs.microsoft.com . สืบค้นเมื่อ2020-06-06 . ตั้งแต่ Windows เวอร์ชัน 1903 (อัปเดตพฤษภาคม 2019) คุณสามารถใช้คุณสมบัติ ActiveCodePage ใน appxmanifest สำหรับแอปที่ทำแพ็กเกจ หรือรายการฟิวชั่นสำหรับแอปที่ไม่ได้แพ็กเกจ เพื่อบังคับให้กระบวนการใช้ UTF-8 เป็นเพจโค้ดของกระบวนการ [..] เท่ากับเฉพาะเมื่อทำงานบน Windows เวอร์ชัน 1903 (อัปเดตพฤษภาคม 2019) หรือสูงกว่า และคุณสมบัติ ActiveCodePage ที่อธิบายข้างต้นถูกตั้งค่าเป็น UTF-8 มิฉะนั้น จะใช้หน้ารหัสระบบเดิม เราแนะนำให้ใช้อย่างชัดเจนCP_ACPCP_UTF8CP_UTF8
  3. ^ " HTML มาตรฐานการใช้ชีวิต" . w3.org . 2020-06-10 . สืบค้นเมื่อ2020-06-15 . การเข้ารหัส UTF-16 เป็นการเข้ารหัสเพียงอย่างเดียวที่ข้อกำหนดนี้จำเป็นต้องถือว่าไม่ใช่การเข้ารหัสที่เข้ากันได้กับ ASCII
  4. ^ "สถิติการใช้งาน UTF-16 สำหรับเว็บไซต์ มิถุนายน 2021" . w3techs.com . สืบค้นเมื่อ2021-06-17 .
  5. ^ "สถิติการใช้งาน UTF-8 สำหรับเว็บไซต์ กุมภาพันธ์ 2021" . w3techs.com . สืบค้นเมื่อ2021-02-25 .
  6. ^ "มาตรฐานการเข้ารหัส" . encoding.spec.whatwg.org สืบค้นเมื่อ2018-10-22 . การเข้ารหัส UTF-8 เป็นการเข้ารหัสที่เหมาะสมที่สุดสำหรับการแลกเปลี่ยน Unicode ซึ่งเป็นชุดอักขระรหัสสากล ดังนั้นสำหรับโปรโตคอลและรูปแบบใหม่ เช่นเดียวกับรูปแบบที่มีอยู่ซึ่งปรับใช้ในบริบทใหม่ ข้อกำหนดนี้จึงต้องการ (และกำหนด) การเข้ารหัส UTF-8 [..] ปัญหาที่อธิบายไว้ที่นี่จะหายไปเมื่อใช้เฉพาะ UTF-8 ซึ่งเป็นหนึ่งในหลายสาเหตุที่ทำให้ UTF-8 เป็นการเข้ารหัสที่จำเป็นสำหรับข้อความทั้งหมดบนเว็บ
  7. ^ a b "MySQL :: MySQL 5.7 Reference Manual :: 10.1.9.4 The ucs2 Character Set (UCS-2 Unicode Encoding)" . dev.mysql.comครับ
  8. ^ "คำถามเกี่ยวกับรูปแบบการเข้ารหัส" . สืบค้นเมื่อ2010-11-12 .
  9. ^ ISO/IEC 10646:2014 "เทคโนโลยีสารสนเทศ – ชุดอักขระสากล (UCS)" ส่วนที่ 9 และ 10
  10. ^ มาตรฐาน Unicodeเวอร์ชัน 7.0 (2014)ส่วน 2.5
  11. ^ "การUnicode®รุ่นมาตรฐาน 10.0 -. ข้อกำหนดหลักของภาคผนวก C ความสัมพันธ์กับมาตรฐาน ISO / IEC 10646" (PDF) สมาคม Unicode ส่วน C.2 หน้า 913 (pdf หน้า 10)
  12. ^ "นโยบายการเข้ารหัสอักขระ Unicode เสถียรภาพ" unicode.org .
  13. ^ "ไม่ผิดหรอกที่ "🤦🏼‍♂️".length == 7" . hsivonen.fi สืบค้นเมื่อ2021-03-15 .
  14. ^ "เอกสารนักพัฒนาของ Apple" . developer.apple.com ครับ สืบค้นเมื่อ2021-03-15 .
  15. ^ Yergeau ฟ; ฮอฟแมน, พอล. "UTF-16 การเข้ารหัส ISO 10646" . tools.ietf.org . สืบค้นเมื่อ2019-06-18 .
  16. ^ อัลเลน จูลี่ ดี.; แอนเดอร์สัน เดโบราห์; เบกเกอร์, โจ ; คุก, ริชาร์ด, สหพันธ์. (2014). "3.8 ตัวแทน" (PDF) . มาตรฐาน Unicode เวอร์ชั่น 7.0-Core ข้อมูลจำเพาะ Mountain View: ยูนิโค้ด Consortium NS. 118 . สืบค้นเมื่อ3 พฤศจิกายน 2557 .
  17. ^ ยูนิโค้ด (วินโดวส์) . ดึงข้อมูลเมื่อ 2011-03-08 "ฟังก์ชันเหล่านี้ใช้การเข้ารหัส UTF-16 (อักขระแบบกว้าง) (...) ที่ใช้สำหรับการเข้ารหัส Unicode ดั้งเดิมบนระบบปฏิบัติการ Windows"
  18. ^ "ยูนิโค้ด" . microsoft.com . สืบค้นเมื่อ2009-07-20 .
  19. ^ "ตัวแทนและตัวละครเสริม" . microsoft.com . สืบค้นเมื่อ2009-07-20 .
  20. ^ "คำอธิบายของการจัดเก็บข้อมูล UTF-8 ใน SQL Server" microsoft.com 7 ธันวาคม 2548 . ที่ดึง 2008-02-01
  21. ^ "[Updated] Patch สำหรับ cmd.exe สำหรับ Windows XP สำหรับซีพี 65001 - หน้า 2 - DosTips.com" www.dostips.com . สืบค้นเมื่อ2021-06-17 .
  22. ^ "UCS 2 และความสัมพันธ์กับ Unicode (UTF-16)" ไอบีเอ็ม. สืบค้นเมื่อ2019-04-26 .
  23. ^ เซลฟ์ ชาด (2012-11-08). "การผจญภัยใน Unicode SMS" . ทวิลิโอ เก็บถาวรจากต้นฉบับเมื่อ 2012-11-09 . สืบค้นเมื่อ2015-08-28 .
  24. ^ "PEP 261 - การสนับสนุนสำหรับ "กว้าง" อักขระ Unicode" ไพธอน. org สืบค้นเมื่อ2015-05-29 .
  25. ^ "PEP 0393 – การแสดงสตริงแบบยืดหยุ่น" . ไพธอน. org สืบค้นเมื่อ2015-05-29 .
  26. ^ "การเข้ารหัสอักขระภายใน JavaScript ของ: UCS 2 หรือ UTF-16 · Bynens งัด"
  27. ^ "ECMA-334: 9.4.1 Unicode ลำดับหนี" th.csharp-online.net . เก็บถาวรจากต้นฉบับเมื่อ 2013-05-01
  28. ^ โครงสร้างคำศัพท์: Unicode Escapesใน "ความจำเพาะ Java ภาษา, พิมพ์ครั้งที่สาม" Sun Microsystems, Inc 2548 . สืบค้นเมื่อ2019-10-11 .
  29. ^ "อภิธานศัพท์ของข้อกำหนด Unicode" . สืบค้นเมื่อ2016-06-21 .
  30. ^ "PHP: สนับสนุนการเข้ารหัสตัวอักษร - คู่มือการใช้งาน" php.net .
  31. ^ "สาย UTF-8" . Swift.org . 2019-03-20 . สืบค้นเมื่อ2020-08-20 .

ลิงค์ภายนอก