Существует ли язык программирования с полной и правильной поддержкой Юникода?

Question

Большинство языков программирования имеют некоторую поддержку Unicode, но у всех есть более или менее документированные угловые случаи, когда вещи не будут работать правильно.

---

Примеры

Java: reverse () в StringBuilder / StringBuffer работают правильно. Но length (), charAt () и т. Д. В String этого не делают, если для кодировки требуется более 16 бит.

C #: Не удалось найти правильный обратный метод. Длина и индексированный доступ возвращают неверные результаты.

Perl: Та же проблема.

PHP: Совершенно не знаком с Unicode, у mbstring есть несколько лучших рабочих замен.

---

Интересно, есть ли язык программирования, который имеет полную и правильную поддержку Unicode? Какие компромиссы нужно было достичь, чтобы достичь такой цели?

• Более сложные алгоритмы?
• Чем выше потребление памяти?
• Низкая производительность?

Как это было реализовано внутри?

• Массив Ints, связанных списков и т. Д.
• Дополнительная буферизация

Я видел, что в Python 3 произошли довольно большие изменения в этой области. Насколько близок Python 3 к правильной реализации?

Answer 1

Реализация Java верна в том смысле, что она не нарушает стандарт Unicode;не существует предписания, что индексирование строк работает с кодовыми точками, а не с единицами кода, и его поведение задокументировано.Стандарт Unicode предоставляет разработчикам большую свободу в отношении оптимизаций до тех пор, пока не будет пропущена недопустимая строка.Что касается «полной поддержки», это еще сложнее определить.Стандарт Unicode обычно не требует, чтобы определенные функции были реализованы для совместимости с Unicode;только то, что реализованные функции реализованы в соответствии со стандартом.Огромные части, касающиеся обработки сценариев, принадлежат шрифтам или операционной системе, которые не могут контролировать системы программирования.Если вы хотите судить о поддержке Unicode определенных технологий, вы можете начать с тестирования следующего (субъективного и неисчерпывающего) списка тем:

• Имеет ли система строковый тип данных, который используетКодировка Unicode?
• Поддерживаются ли все кодировки Unicode (UTF), описанные в стандарте?
• Нормализация
• Двунаправленный алгоритм
• Is UpperCase("ß") = "SS"?
• Чувствительна ли локаль верхнего регистра?(например, на турецком, UpperCase("i") = "İ")
• Существуют ли функции для работы с кодовыми точками вместо кодовых единиц?
• Регулярные выражения Unicode
• Вызывает ли система исключения, когда они недействительныпоследовательности кодовых единиц встречаются во время декодирования?
• Доступ к свойствам базы данных Unicode?

Я думаю, что Java и .NET ответят на эти вопросы в основном «да», в то время как Python 3.x ответ почти всегда «нет».

Answer 2

Go , новый язык, разработанный в Google, изобретенный Кеном Томпсоном и Робом Пайком и диалектом C в Plan9 из Bell Labs были созданы с учетом Unicode ( UTF-8 был изобретен там, в Bell Labs, Кеном Томпсоном).

Answer 3

В Python 3 строки всегда имеют Unicode (* ASCII или подобные кодировки bytes). Я не знаю ни о каких встроенных модулях, работающих с ними неправильно. Там могут быть некоторые, но, учитывая, что это уже давно, я полагаю, они получили все необходимое для ежедневной работы.

Конечно, Unicode имеет более высокое потребление памяти (UTF-8 не совсем, если вы находитесь в диапазоне ASCII, но еще ...), и я могу себе представить, что кодирование нескольких длин - это трудная внутренняя задача. Я ничего не знаю о реализации, хотя. За исключением того, что это не может быть связанный список, так как он имеет O (1) произвольный доступ.

Answer 4

Похоже, что Perl 6 получает хорошую поддержку Unicode:

perlgeek.de / ен / статьи / 5-к-6 # post_17

Например, он предоставляет вам три различных метода длины:

• байтов (количество байтов)
• коды (количество кодовых точек)
• графики (количество графем)

Это также интегрируется в регулярные выражения Perl.

Выглядит как шаг в правильном направлении для меня.

Answer 5

.NET Framework хранит данные char и string с использованием кодировки UTF-16.Если вы предполагаете , что весь ваш текст находится в базовой многоязычной плоскости, тогда все будет работать без какого-либо специального кода.

Если вы считаете введенные пользователем строки как большие двоичные объекты и не пытаетесьчтобы манипулировать ими (например, большинство текстовых полей в приложениях CRUD), тогда ваш код будет отображаться для правильной обработки символов вне BMP, потому что UTF-16 хранит их как суррогатные пары.Пока вы не возитесь с суррогатными парами, все будет хорошо.

Однако, если вы хотите анализировать и манипулировать строками, а также корректно обрабатывать символы вне BMP, вам придется явно кодироватьза такую ​​возможность.Обратитесь к классу StringInfo , чтобы узнать о методах, помогающих вам обрабатывать суррогатные пары.

Я думаю, что Microsoft разработала его таким образом, чтобы достичь баланса между производительностью и корректностью.Альтернативы могут быть:

• Хранить строки как UTF-32 - низкая производительность с точки зрения использования памяти
• Заставить все строковые функции обрабатывать суррогатные пары - очень плохопроизводительность для манипулирования

.NET также содержит полную поддержку преобразования, сравнения и сортировки с учетом культурных особенностей.

Answer 6

DigitalMars D имеет тип данных dstring, который использует кодовые точки UTF32, должно быть достаточно для большинства случаев.

Answer 7

Я считаю, что любой язык, поддерживаемый в .NET Framework , имеет правильную поддержку Unicode (UTF-16).

Также, аналогичный вопрос здесь