Чому Java використовує UTF-16 для внутрішнього представлення рядків?

Я б міг уявити, що причина була швидкою, масив, як доступ до символу в індексі, але деякі символи не впишуться в 16 біт, тому це не буде працювати ...

Тож якщо вам доведеться в будь-якому разі обробляти особливі справи, чому б просто не використовувати UTF-8?

java strings unicode

— мрпьо
джерело

Щось запитати дизайнерів Java, а не спільноти взагалі. Голосування про закриття не є конструктивним.

— Одід

@Oded: абсолютно необґрунтовано, як свідчить відповідь DeadMG.

— Майкл Боргвардт

Я розгублений: я був майже впевнений, що на це питання вже відповіли (і тут, і в ТАК), але не можу знайти дублікат (и).

— Йоахім Зауер

Для істеричних родзинок. Дивіться utf8everywhere.org

— Павло Радзівіловський

Відповіді:

Тому що це був UCS-2 , який був непоганим 16-бітним фіксованою довжиною. Звичайно, 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.

— Малькольм

UCS-2 - це технічний термін, а не казкове слово.

— DeadMG

Здебільшого, заради простого та простого майбутнього підтвердження. Чи це була помилкова причина та неправильний шлях для цього - це інше питання.

Ви можете побачити деякі причини, що стоять за деякими їх дизайнерськими рішеннями в цьому документі про перехід 2004 року на Java 5 та UTF-16, де пояснюються також деякі недоліки: Додаткові символи на платформі Java , а також див. Чому використовується екосистема Java різні кодування у всій їх стеці? .

Для отримання більш детальної інформації про підводні камені використання UTF-16 та чому UTF-8, ймовірно, є кращим варіантом, див. Чи слід UTF-16 вважати шкідливим? та маніфест UTF-8 Everywhere .

— хайлем
джерело

+1 за посилання на "Чи слід вважати UTF-16 шкідливим?" питання. Нещодавно я відкрив маніфест UTF-8 Everywhere, і я вважаю, що зараз переконаний. Що варто, хоча Java помилилася, я впевнений, що Windows зробила набагато гірше.

— Даніель Приден

Що ж, не дивно, що Windows зрозуміла більше помилок : вони перейшли на Unicode раніше, тому вони мали менше правильного вибору та менше досвіду. Java отримала пізніше, зрозуміла правильніше , але все-таки дещо неправильно. Тепер обом доводиться жити зі старими, неправильними в загальному розумінні API, які вони повинні підтримувати.

— Йоахім Зауер

Це життя в світі програмного забезпечення, ви повинні робити вибір, не маючи всіх даних, і, коли ви помиляєтесь, вам доведеться довго жити з наслідками. :-)

— Брайан Ноблеуч

Мені цікаво, які наслідки для продуктивності мали б зробити string"особливий" тип у Java (начебто Arrayце є), а не мати String"звичайний" клас, який містить посилання на "звичайний" масив, що містить фактичні символи. Залежно від способу створення рядка, UTF-8, UTF-16 або навіть UTF-32 може бути найбільш ефективним способом його зберігання. Я не думаю, що для "звичайного" класу немає особливо ефективного способу Stringобробки декількох форматів, але "спеціальний" тип із підтримкою JVM міг би.

— supercat

@supercat: Я точно не маю точної відповіді на це, але у мене є відповідна відповідь на це. :) Дійсно не стосується підходу спеціального типу, але обговорює потенційну вигоду від обтічних рядків.

— хайлем