“ คู่ตัวแทน” ใน Java คืออะไร?

ผมอ่านเอกสารประกอบการStringBufferโดยเฉพาะอย่างยิ่งย้อนกลับ ()วิธีการ เอกสารที่กล่าวถึงสิ่งที่เกี่ยวกับคู่ตัวแทน คู่ตัวแทนในบริบทนี้คืออะไร? และตัวแทนสำรองต่ำและสูงคืออะไร?

คำว่า "คู่ตัวแทน" หมายถึงวิธีการเข้ารหัสอักขระ Unicode ที่มีรหัสจุดสูงในรูปแบบการเข้ารหัส UTF-16

ในการเข้ารหัสอักขระ Unicode อักขระจะถูกแมปกับค่าระหว่าง 0x0 และ 0x10FFFF

ภายใน Java ใช้รูปแบบการเข้ารหัส UTF-16 เพื่อเก็บสตริงของข้อความ Unicode ใน UTF-16 จะใช้หน่วยรหัส 16 บิต (สองไบต์) เนื่องจาก 16 บิตสามารถมีช่วงของอักขระจาก 0x0 ถึง 0xFFFF เท่านั้นจึงมีความซับซ้อนเพิ่มเติมบางอย่างที่ใช้ในการจัดเก็บค่าเหนือช่วงนี้ (0x10000 ถึง 0x10FFFF) สิ่งนี้ทำได้โดยใช้คู่ของรหัสหน่วยที่เรียกว่าตัวแทน

หน่วยรหัสตัวแทนตั้งอยู่ในสองช่วงที่เรียกว่า "ตัวแทนตัวแทนสูง" และ "ตัวแทนตัวแทนต่ำ" ขึ้นอยู่กับว่าได้รับอนุญาตในตอนเริ่มต้นหรือสิ้นสุดของลำดับรหัสสองหน่วย

Java เวอร์ชันก่อนหน้าแสดงอักขระ Unicode โดยใช้ชนิดข้อมูลถ่าน 16 บิต การออกแบบนี้มีเหตุผลในเวลานั้นเนื่องจากอักขระ Unicode ทั้งหมดมีค่าน้อยกว่า 65,535 (0xFFFF) และสามารถแสดงใน 16 บิต อย่างไรก็ตามในภายหลัง Unicode เพิ่มค่าสูงสุดเป็น 1,114,111 (0x10FFFF) เนื่องจากค่า 16 บิตมีขนาดเล็กเกินไปที่จะแสดงถึงอักขระ Unicode ทั้งหมดใน Unicode รุ่น 3.1 ค่า 32- บิต - เรียกว่าจุดรหัส - ถูกนำมาใช้สำหรับรูปแบบการเข้ารหัส UTF-32 แต่ค่า 16 บิตนั้นต้องการมากกว่า 32 บิตสำหรับการใช้หน่วยความจำที่มีประสิทธิภาพดังนั้น Unicode จึงนำเสนอการออกแบบใหม่เพื่อให้สามารถใช้งานค่า 16 บิตได้อย่างต่อเนื่อง การออกแบบนี้มีการนำมาใช้ในรูปแบบการเข้ารหัส UTF-16 กำหนดค่า 1,024 ให้กับตัวแทนเสมือนสูง 16 บิต (ในช่วง U + D800 ถึง U + DBFF) และอีก 1,024 ค่าเป็นตัวแทนต่ำ 16 บิต (ในช่วง U + DC00 ถึง U + DFFF)

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

เพิ่มข้อมูลเพิ่มเติมบางคำตอบข้างต้นจากนี้โพสต์

ทดสอบใน Java-12 ควรทำงานกับ Java เวอร์ชันทั้งหมดที่สูงกว่า 5

เป็นที่กล่าวถึงที่นี่: https://stackoverflow.com/a/47505451/2987755 ,
แล้วแต่จำนวนใดตัวอักษร (Unicode ซึ่งอยู่เหนือ U + FFFF) จะแสดงเป็นคู่ตัวแทนซึ่งร้านค้า Java เป็นคู่ของค่าถ่านคือ Unicode เดียว อักขระถูกแสดงเป็นอักขระ Java สองตัวที่อยู่ติดกัน
อย่างที่เราเห็นในตัวอย่างต่อไปนี้
1. ความยาว:

"🌉".length()  //2, Expectations was it should return 1

"🌉".codePointCount(0,"🌉".length())  //1, To get the number of Unicode characters in a Java String  

2. Equality:
แสดง "🌉" เป็น String โดยใช้ Unicode \ud83c\udf09ดังนี้และตรวจสอบความเท่าเทียมกัน

"🌉".equals("\ud83c\udf09") // true

Java ไม่รองรับ UTF-32

"🌉".equals("\u1F309") // false  

3. คุณสามารถแปลงอักขระ Unicode เป็น Java String

"🌉".equals(new String(Character.toChars(0x0001F309))) //true

4. String.substring () ไม่พิจารณาอักขระเสริม

"🌉🌐".substring(0,1) //"?"
"🌉🌐".substring(0,2) //"🌉"
"🌉🌐".substring(0,4) //"🌉🌐"

เพื่อแก้ปัญหานี้เราสามารถใช้ String.offsetByCodePoints(int index, int codePointOffset)

"🌉🌐".substring(0,"🌉🌐".offsetByCodePoints(0,1) // "🌉"
"🌉🌐".substring(2,"🌉🌐".offsetByCodePoints(1,2)) // "🌐"

สตริง 5. ทำซ้ำ Unicode กับBreakIterator
6. คัดแยกสายกับ Unicode java.text.Collator
7. ตัวละครtoUpperCase(), toLowerCase()วิธีไม่ควรนำมาใช้แทนการใช้ตัวพิมพ์ใหญ่และตัวพิมพ์เล็กสตริงของสถานที่โดยเฉพาะอย่างยิ่ง
8. Character.isLetter(char ch)ไม่รองรับใช้งานได้ดีกว่าCharacter.isLetter(int codePoint)สำหรับแต่ละmethodName(char ch)วิธีในคลาสอักขระจะมีประเภทmethodName(int codePoint)ที่สามารถจัดการอักขระเสริมได้
9. ระบุชุดอักขระในString.getBytes()แปลงจากไบต์เป็นสตริงInputStreamReader ,OutputStreamWriter

Ref:
https://coolsymbol.com/emojis/emoji-for-copy-and-paste.html#objects
https://www.online-toolz.com/tools/text-unicode-entities-convertor.php
https: //www.ibm.com/developerworks/library/j-unicode/index.html
https://www.oracle.com/technetwork/articles/javaee/supplementary-142654.html

ข้อมูลเพิ่มเติมเกี่ยวกับตัวอย่างimage1 image2
คำอื่น ๆ ที่ควรค่าแก่การสำรวจ: การทำให้เป็นมาตรฐาน , BiDi

คู่ตัวแทนแทนหมายถึงวิธีการเข้ารหัสอักขระบางตัวของ UTF-16 ดูที่http://en.wikipedia.org/wiki/UTF-16/UCS-2#Code_points_U.2B10000..U.2B10FFFF

คำนำขนาดเล็ก

• Unicode แสดงถึงจุดรหัส รหัสจุดแต่ละจุดสามารถเข้ารหัสในบล็อก 8-, 16, - หรือ 32- บิตตามมาตรฐาน Unicode

• ก่อนหน้า Version 3.1 การใช้งานส่วนใหญ่คือการเข้ารหัส 8 บิตรู้จักกันในชื่อ UTF-8 และการเข้ารหัส 16 บิตหรือที่รู้จักกันในชื่อ UCS-2 หรือ "ชุดอักขระสากลที่เข้ารหัสใน 2 octets" UTF-8 เข้ารหัสจุด Unicode เป็นลำดับของบล็อกขนาด 1 ไบต์ในขณะที่ UCS-2 ใช้เวลา 2 ไบต์เสมอ:

  A = 41 - หนึ่งบล็อก 8 บิตพร้อม UTF-8
  A = 0041 - หนึ่งบล็อก 16 บิตด้วย UCS-2
  Ω = CE A9 - สองบล็อก 8 บิตพร้อม UTF-8
  Ω = 03A9 - หนึ่งบล็อกของ 16 บิตด้วย UCS-2

ปัญหา

สมาคมคิดว่า 16 บิตจะเพียงพอที่จะครอบคลุมภาษาที่มนุษย์อ่านได้ซึ่งให้2 ^ 16 = 65536ค่ารหัสที่เป็นไปได้สิ่งนี้เป็นจริงสำหรับเครื่องบิน 0 หรือที่รู้จักกันในชื่อ BPM หรือเครื่องบินหลายภาษาขั้นพื้นฐานซึ่งประกอบด้วย 55,445 จาก 65536 รหัสคะแนนในวันนี้ BPM ครอบคลุมภาษามนุษย์เกือบทุกภาษาในโลกรวมถึงสัญลักษณ์จีน - ญี่ปุ่น - เกาหลี (CJK)

เวลาผ่านไปและชุดตัวละครเอเชียใหม่ถูกเพิ่มเข้ามาสัญลักษณ์จีนได้รับมากกว่า 70,000 คะแนนเพียงอย่างเดียว ตอนนี้มีแม้แต่คะแนน Emojiเป็นส่วนหนึ่งของมาตรฐาน😺 มีการเพิ่มเครื่องบิน 16 "เพิ่มเติม" ใหม่ ห้อง UCS-2 ไม่เพียงพอที่จะครอบคลุมทุกสิ่งที่ใหญ่กว่า Plane-0

การตัดสินใจ Unicode

1. จำกัด Unicode ให้กับ 17 เครื่องบิน× 65 536 ตัวอักษรต่อเครื่องบิน = 1 114 112 คะแนนสูงสุด
2. แสดง UTF-32 เดิมชื่อ UCS-4 เพื่อเก็บ 32- บิตสำหรับแต่ละจุดรหัสและครอบคลุมเครื่องบินทั้งหมด
3. ใช้ UTF-8 ต่อไปเป็นการเข้ารหัสแบบไดนามิก จำกัด UTF-8 ถึง 4 ไบต์สูงสุดสำหรับแต่ละจุดรหัสเช่นจาก 1 ถึง 4 ไบต์ต่อจุด
4. เลิกใช้ UCS-2

5. สร้าง UTF-16 ตาม UCS-2 สร้าง UTF-16 แบบไดนามิกดังนั้นใช้ 2 ไบต์หรือ 4 ไบต์ต่อจุด กำหนด 1024 คะแนน U + D800 – U + DBFF เรียก High Surrogates เป็น UTF-16 กำหนด 1024 สัญลักษณ์ U + DC00 – U + DFFF เรียกว่า Low Surrogates ถึง UTF-16

   ด้วยการเปลี่ยนแปลงเหล่านั้น BPM ถูกปกคลุมด้วย 1 บล็อก 16 บิตใน UTF-16 ในขณะที่ "อักขระเสริม" ทั้งหมดจะถูกปกคลุมด้วยคู่ตัวแทนตัวแทนนำเสนอ 2 บล็อก 16 บิตแต่ละ 1024x1024 = 1 048 576 คะแนน

   ตัวแทนสูงแจ๋วตัวแทนต่ำ การเบี่ยงเบนจากกฎนี้ถือว่าเป็นการเข้ารหัสที่ไม่ดี ตัวอย่างเช่นตัวแทนที่ไม่มีคู่ไม่ถูกต้องสถานะตัวแทนที่ต่ำก่อนที่ตัวแทนที่สูงจะไม่ถูกต้อง

   𝄞 'สัญลักษณ์ทางดนตรี G CLEF' ถูกเข้ารหัสใน UTF-16 เป็นคู่ของตัวแทน 0xD834 0xDD1E (2 คูณ 2 ไบต์)
   ใน UTF-8 เป็น 0xF0 0x9D 0x84 0x9E (4 คูณ 1 ไบต์)
   ในรูปของ UTF-16 0x0001D11E (1 by 4 bytes)

สถานการณ์ปัจจุบัน

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

รายละเอียดทางประวัติศาสตร์หลายคนถูกระงับการติดตามหัวข้อ⚖
สามารถดู Unicode Standard ล่าสุดได้ที่http://www.unicode.org/versions/latest

คู่ตัวแทนคือ 'หน่วยรหัส' สองชุดใน UTF-16 ที่รวมเป็นหนึ่ง 'รหัสจุด' เอกสาร Java ระบุว่า 'คะแนนรหัส' เหล่านี้จะยังคงถูกต้องโดยสั่ง 'หน่วยรหัส' อย่างถูกต้องหลังจากย้อนกลับ กล่าวเพิ่มเติมอีกว่าหน่วยรหัสตัวแทนเสมือนที่ไม่มีการจับคู่สองคู่นั้นอาจถูกสลับกลับและสร้างคู่ตัวแทนตัวแทนที่ถูกต้อง ซึ่งหมายความว่าหากมีหน่วยรหัส unpaired แล้วมีโอกาสที่การย้อนกลับของการย้อนกลับอาจไม่เหมือนกัน!

แม้ว่าการสังเกตเห็นว่าเอกสารนั้นไม่ได้เกี่ยวกับ Graphemes - ซึ่งเป็น codepoints หลายตัวรวมกัน ซึ่งหมายถึง e และสำเนียงที่ไปพร้อมกับมันยังคงสามารถเปลี่ยนได้ดังนั้นให้วางสำเนียงก่อน e ซึ่งหมายความว่าหากมีเสียงสระอีกตัวหนึ่งอยู่ข้างหน้า e อาจจะได้สำเนียงที่อยู่บน e

อ๊ะ!