Java neden dahili dize gösterimi için UTF-16 kullanıyor?

Sebebinin hızlı olduğunu hayal ediyorum, dizindeki karaktere erişim gibi bir dizi, ancak bazı karakterler 16 bit sığmıyor, bu yüzden işe yaramaz ...

Öyleyse yine de özel durumlarla ilgilenmeniz gerekiyorsa, neden sadece UTF-8'i kullanmıyorsunuz?

java strings unicode

— mrpyo
kaynak

Java tasarımcılarına, topluluğa değil, soracak bir şey. Yapıcı olmadığı için kapanma oyu.

— 07:12

@Oded: DeadMG'nin cevabının gösterdiği gibi kesinlikle haksız yere.

— Michael Borgwardt

Kafam karıştı: Bu sorunun çoktan cevaplandığından çok emindim (hem burada hem de SO'da), ancak kopyaları bulamıyorum.

— Joachim Sauer

Histerik kuru üzümler için. Utf8everywhere.org

— Pavel Radzivilovsky

Yanıtlar:

Çünkü eski sabit uzunlukta bir 16-bit olan UCS-2 idi. Tabii ki, 16bit yeterli olmadığı ortaya çıktı. Üstte UTF-16'yı güçlendirdiler.

— DeadMG
kaynak

İşte Unicode SSS'den bir alıntı :

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 sürümünde UTF-16 henüz ortaya çıkmadı ve UTF-8 Unicode standardının bir parçası değildi.

— Malcolm

UCS-2 teknik bir terimdir, terim değildir.

— DeadMG

Ana bölüm için, sade ve basit bir gelecek geçirmezlik uğruna. Yanlış yönlendirilmiş bir sebep olup olmadığı ve bunun yanlış gitmesi farklı bir soru.

Sen 2004 de bazı eksiklikleri açıklar Java 5 ve UTF-16 geçiş, yaklaşık olarak bu belgede tasarım kararlarının bazıları arkasında bazı nedenleri görebilirsiniz: Java Platformu Tamamlayıcı Karakterler ve bkz Java ekosistem kullanımı yapar Neden yığını boyunca farklı kodlamalar? .

UTF-16'yı kullanmanın tuzakları ve neden UTF-8'in genel olarak daha iyi bir seçenek olabileceği konusunda daha fazla bilgi için, bkz. UTF-16'nın zararlı kabul edilmesi gerekir mi? ve UTF-8 Her Yerde manifestosu.

— haylem
kaynak

"UTF-16 zararlı olarak kabul edilmeli mi?" soru. Geçenlerde UTF-8 Everywhere manifestosunu keşfettim ve şimdi oldukça iyice ikna olduğuma inanıyorum. Buna değer, Java yanlış yapmış olmasına rağmen, Windows'un çok daha kötü bir şey yaptığına ikna oldum.

— Daniel Pryden

Eh, Windows daha yanlış anladım bir sürpriz değil : Daha önce Unicode için geçiş yaptılar, bu yüzden daha az doğru seçimler ve daha az deneyim vardı. Java daha sonra anladım, daha doğru anladım , ama yine de biraz yanlış. Şimdi her ikisi de , desteklemeye devam etmeleri gereken eski, genel anlamda yanlış olan API'lerle yaşamak zorunda.

— Joachim Sauer

Yazılım dünyasında hayat bu, tüm verilere sahip olmadan seçim yapmak zorundasınız ve yanlış olduğunuzda sonuçlarla uzun süre yaşayabiliyorsunuz. :-)

— Brian Knoblauch

Asıl karakterleri içeren bir "sıradan" diziye referansı olan "sıradan" bir sınıf olmak yerine , performans etkilerinin stringJava'da "özel" bir tür yapmaktan (bunun gibi Array) ne olacağını merak ediyorum String. Bir dizginin nasıl üretildiğine bağlı olarak, UTF-8, UTF-16, hatta UTF-32 saklamanın en etkili yolu olabilir. "Sıradan" bir sınıfın Stringçoklu formatları işlemesi için özellikle etkili bir yol olduğunu sanmıyorum , ancak JVM destekli "özel" bir tip olabilir.

— supercat

@supercat: Bunun için kesin bir cevabım yok, ancak bunun için ilgili bir SO cevabım var. :) Özel tip yaklaşımını gerçekten ele almıyor, ancak düzleştirilmiş dizgelere sahip olma potansiyel kazancını tartışıyor.

— haylem