เหตุใด Java จึงใช้ UTF-16 สำหรับการแทนค่าสตริงภายใน

ฉันคิดว่าเหตุผลนั้นเร็วอาเรย์ชอบเข้าถึงตัวละครที่ดัชนี แต่ตัวละครบางตัวไม่พอดีกับ 16 บิตดังนั้นมันจะไม่ทำงาน ...

ดังนั้นถ้าคุณต้องจัดการกับกรณีพิเศษอยู่แล้วทำไมไม่ใช้ UTF-8 ล่ะ?

java strings unicode

— mrpyo
แหล่งที่มา

สิ่งที่ถามนักออกแบบ Java ไม่ใช่ชุมชนโดยรวม โหวตให้ปิดเป็นไม่สร้างสรรค์

— Oded

@Oded: ไม่รับประกันอย่างแน่นอนเนื่องจากคำตอบของ DeadMG แสดงให้เห็น

— Michael Borgwardt

ฉันสับสน: ฉันค่อนข้างแน่ใจว่าคำถามนี้ได้รับคำตอบแล้ว (ทั้งที่นี่และที่ SO) แต่ฉันไม่พบสิ่งที่ซ้ำกัน

— Joachim Sauer

สำหรับลูกเกดตีโพยตีพาย ดู utf8everywhere.org

— Pavel Radzivilovsky

คำตอบ:

เพราะเคยเป็นUCS-2ซึ่งเป็นความยาวคงที่ที่ดี 16-bits แน่นอนว่า 16 บิตนั้นยังไม่เพียงพอ พวกเขาดัดแปลง UTF-16 ไว้ด้านบน

— DeadMG
แหล่งที่มา

นี่คือคำพูดจากคำถามที่พบบ่อยของ Unicode :

Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16.

ในขณะที่ Java รุ่น UTF-16 ยังไม่ปรากฏขึ้นและ UTF-8 ไม่ได้เป็นส่วนหนึ่งของมาตรฐาน Unicode

— Malcolm

UCS-2 เป็นศัพท์ทางเทคนิคไม่ใช่คำศัพท์

— DeadMG

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

คุณสามารถเห็นเหตุผลบางอย่างที่อยู่เบื้องหลังการตัดสินใจออกแบบของพวกเขาในเอกสารนี้เกี่ยวกับ 2004 สลับเป็น Java 5 และ UTF-16 ซึ่งอธิบายข้อบกพร่องบางอย่างเช่น: อักขระเสริมในแพลตฟอร์ม Javaและดูว่าทำไมระบบนิเวศ Java ใช้ การเข้ารหัสที่แตกต่างกันตลอดทั้งกอง? .

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

— haylem
แหล่งที่มา

+1 สำหรับการเชื่อมโยงไปยัง "ควร UTF-16 ถือว่าเป็นอันตรายหรือไม่" คำถาม. ฉันเพิ่งค้นพบUTF-8 ทุกที่และฉันเชื่อว่าตอนนี้ฉันค่อนข้างมั่นใจ สำหรับสิ่งที่มีค่าแม้ว่า Java จะผิดฉันก็ค่อนข้างมั่นใจว่า Windows นั้นแย่กว่ามาก

— Daniel Pryden

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

— โจอาคิมซาวเออร์

นั่นคือชีวิตในโลกของซอฟต์แวร์คุณต้องเลือกโดยไม่ต้องมีข้อมูลทั้งหมดและเมื่อคุณผิดคุณจะอยู่กับผลที่ตามมาเป็นเวลานาน :-)

— Brian Knoblauch

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

— supercat

@supercat: ฉันไม่ได้มีคำตอบที่ถูกต้องสำหรับสิ่งนั้น แต่ฉันมีคำตอบ SO ที่เกี่ยวข้องสำหรับสิ่งนั้น :) ไม่ได้กล่าวถึงวิธีการแบบพิเศษ แต่พูดถึงความเป็นไปได้ของการมีสายอักขระที่คล่องตัว

— haylem