C/C++

C

C before C99 has no built in unicode support. It uses zero terminated character arrays (char* or char[]) as strings. A char is specified to by a byte (8 bits).

C99 specifies wcs-functions in additions to the old str-functions (e.g. strlen -> wcslen). These functions take wchar_t* instead of char*. wchar_t stands for wide character type. The size of wchar_t is compiler-specific and can be as small as 8 bits. While different compilers indeed use different sizes, it's usually 16-bit (UTF-16) or 32-bit (UTF-32).

Most C library functions are transparent to UTF-8. E.g. if your operating system supports UTF-8 (and UTF-8 is configured as your systems charset), then creating a file using fopen passing an UTF-8 encoded string will create a properly named file.

C++

The situation in C++ is very similar (std::string -> std::wstring), but there are at least efforts to get some sort of unicode support in the standard library.

Perl

Perl в основном имеет встроенную поддержку Unicode. Вроде, как бы, что-то вроде. Из perldoc:

• perlunitut - Учебник по использованию Unicode в Perl. В основном учит в абсолютном выражении о том, что вы должны и не должны делать в Unicode. Охватывает основы.
• perlunifaq - Часто задаваемые вопросы о Unicode в Perl.
• perluniintro - Введение в Unicode в Perl. Меньше «проповедей», чем perlunitut .
• perlunicode - Ибо, когда вам абсолютно необходимо знать все, что нужно знать о Unicode и Perl.

Common Lisp (SBCL и CLisp)

Согласно , , SBCL и CLisp поддерживают Unicode.

Java

Как и в случае с .NET, Java внутренне использует UTF-16: java.lang.String

A String представляет строку в формат UTF-16, в котором дополнительные символы представлены суррогатными парами (см. раздел Представления символов Юникода в классе символов для больше информации). Значения индекса относятся к единицам кода char , поэтому дополнительный символ использует две позиции в String .

Python

Python 2 имеет классы str и юникод . Объекты str хранят байты, объекты unicode хранят символы UTF-16. Большинство библиотечных функций поддерживают обе функции (например, os.listdir ('.') возвращает список из str , os.listdir (u '.') возвращает список объектов unicode ). Оба имеют методы encode и decode .

Python 3 в основном переименовал unicode в str . Python 3, эквивалентный str , будет иметь тип байтов . байт имеет метод decode и str метод кодирования . Начиная с Python 3.3 объекты str внутренне используют одну из нескольких кодировок для экономии памяти. Для программиста Python это по-прежнему выглядит как абстрактная последовательность Unicode.

Python поддерживает:

• кодирование / декодирование
• нормализацию
• простое преобразование регистра и разделение на пробелы
• поиск символов по их имени

] Python не поддерживает / имеет ограниченную поддержку для:

• сопоставления (ограничено)
• преобразований в особых случаях, когда нет отображения 1: 1 между символами нижнего и верхнего регистра;
• регулярных выражений ( над )
• сегментация текста
• двунаправленная обработка текста

См. Также: Правда о Unicode в Python

Arc

Arc doesn't have any unicode support. Yet.

Ruby

Единственное, что я могу найти для Ruby, довольно старое и не слишком рубистовое, я не уверен, насколько он точен.

Для справки, Ruby поддерживает utf8, но не многобайтовый. Внутренне он обычно предполагает, что строки являются байтовыми векторами, хотя существуют библиотеки и уловки, которые вы обычно можете использовать для работы.

Обнаружено, что здесь .

Ruby 1.9

Ruby 1.9 присоединяет кодировки к струнам. Для двоичных строк используется кодировка «ASCII-8BIT». Хотя кодировка по умолчанию обычно UTF-8 в любой современной системе, вы не можете предполагать, что все сторонние библиотечные функции всегда возвращают строки в этой кодировке. Он может возвращать любую другую кодировку (например, некоторые парсеры yaml делают это в некоторых ситуациях).

PHP

На SO!

JavaScript

Похоже, что до JS 1.3 не было поддержки Unicode. Начиная с версии 1.5, поддерживаются UTF-8, UTF-16 и UCS-2. Вы можете использовать escape-последовательности Unicode в строках, регулярных выражениях и идентификаторах. Источник

.NET (C #, VB.NET, ...)

.NET хранит строк внутри как последовательность System.Char объекты. Один System.Char представляет кодовую единицу UTF-16 .

Из документации MSDN на System.Char :

.NET Framework использует Char структура для представления Unicode персонаж. Стандарт Юникода идентифицирует каждый символ Unicode с помощью уникальное 21-битное скалярное число, называемое кодовая точка и определяет UTF-16 форма кодирования, определяющая, как кодовая точка закодирована в последовательность одного или нескольких 16-битных значений. Каждый 16-битное значение варьируется от шестнадцатеричного От 0x0000 до 0xFFFF и хранится в структура Char .

Дополнительные ресурсы:

• Строки в .NET и C # (от Джона Скита).

Delphi

Delphi 2009 полностью поддерживает Unicode. Они изменили реализацию строки на 16-битную кодировку Unicode по умолчанию, и большинство библиотек, включая сторонние, поддерживают Unicode. См. Delphi и Unicode Марко Канто.

До Delphi 2009 поддержка Unicode была ограничена, но были WideChar и WideString для хранения 16 -битовая кодированная строка. См. Unicode в Delphi для получения дополнительной информации.

Обратите внимание, что вы все еще можете разрабатывать двуязычное приложение CJKV без использования Unicode. Например, закодированная строка Shift JIS для японского языка может быть сохранена с использованием простого AnsiString .

Python 3k

Python 3k (или 3.0 или 3000) имеет новый подход к обработке текста (unicode) и данных:
Text Vs. Данные вместо Unicode Vs. 8-битный . См. Также Unicode HOWTO .

Схема R6RS

Требует реализации Unicode 5.1. Все строки находятся в "формате юникода".

Tcl

Строки Tcl были последовательностями символов Unicode начиная с Tcl 8.1 (1999). Внутри они динамически изменяются между UTF-8 (строго такой же модифицированный UTF-8, как и в Java из-за обработки U+00000 символов) и UCS-2 (конечно, с учетом эндианальности и BOM). Все внешние строки (за одним исключением), включая те, которые используются для связи с ОС, имеют внутренний Юникод перед преобразованием в любую кодировку, требуемую для хоста (или настроенную вручную на канале связи). Исключение составляют случаи, когда данные копируются между двумя каналами связи с общей кодировкой (и некоторые другие ограничения, не относящиеся к данному случаю), где используется прямая двоичная передача без копирования.

Символы за пределами BMP в настоящее время не обрабатываются ни внутренне, ни внешне. Это известная проблема.

Objective-C

Нет встроенных, кроме тех, что доступны как часть библиотеки строк C.

Однако, как только вы добавите фреймворки…

Foundation (Cocoa и Cocoa Touch) и Core Foundation

NSString и CFString реализуют строковый класс, полностью основанный на Unicode (фактически несколько классов, как деталь реализации). Оба являются «бесплатными мостами», так что API для одного можно использовать с экземплярами другого, и наоборот.

Для данных, которые не обязательно представляют текст, есть NSData и CFData. NSString предоставляет методы, а CFString предоставляет функции для кодирования текста в данные и декодирования текста из данных. Core Foundation поддерживает более сотни различных кодировок, включая все формы UTF. Кодировки делятся на две группы: встроенные кодировки, которые поддерживаются везде, и внешние кодировки, которые по крайней мере поддерживаются в Mac OS X.

NSString предоставляет методы для нормализации к формам D, KD, C или KC. Каждый возвращает новую строку.

Как NSString, так и CFString предоставляют множество вариантов сравнения/сопоставления.Вот флаги параметров сравнения Foundation и флаги параметров сравнения Core Foundation. Не все они синонимы; например, Core Foundation делает буквальное (строгое на основе кодовой точки) сравнение по умолчанию, тогда как Foundation делает небуквенное сравнение (позволяющее символам с диакритическими знаками сравниваться равными) по умолчанию.

Обратите внимание, что Core Foundation не требует Objective-C; действительно, он был создан в значительной степени для того, чтобы предоставить большинство функций Foundation программистам Carbon, которые использовали чистый C или C++. Тем не менее, я подозреваю, что наиболее современное его использование - в программах Cocoa или Cocoa Touch, которые все написаны на Objective-C или Objective-C++.