Насколько хорошо ваш язык поддерживает юникод на практике? - PullRequest
7 голосов
/ 09 июня 2011

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

Я склоненЯ считаю, что Java слишком многословна и грязна, и мое нежелание трогать Windows 6-футовым шестом имеет тенденцию исключать .Net.Это оставляет практически все остальное - кроме PHP, C и C ++ (последние два из которых, как я знаю, запутываются в юникоде, независимо от библиотеки ICU).

Я коротко перечислил несколько языков на сегодняшний день,а именно Ruby (любил миксины), Python, Lisp и Javascript (node.js).Тем не менее, я иду с очень противоречивой информации на Unicode поддержка и я боюсь (отсутствиевремени ...) чтобы выучить каждого из них до такой степени, что я смогу безопасно сломать его, чтобы исключить его.

Насколько я понял, Python 3 кажется иметь это.Как и Ruby 1.9.Лисп не обязательно .Javascript предположительно.

Возможно, что-то большее, чем поддержка юникода для языка, но по моему опыту, это имеет тенденцию становиться основным недостатком при работе с локалью.

Я также понимаю, что вопрос несколько субъективен.(Пожалуйста, не закрывайте это на том основании: я фактически ссылаюсь на несколько SO-потоков, которые я нахожу неудовлетворительными.) Но ... как пользователь любого из этих языков, насколько хорошо они поддерживают Unicode на практике?

Ответы [ 6 ]

7 голосов
/ 09 июня 2011

Поддержка Unicode в Python не изменилась в 3.x. Поддержка Unicode в Python была почти такой же, как и в Python 2.x, который представил отдельный тип unicode и обработку кодирования. Изменения Python 3.x заключаются в том, что юникод становится единственным типом строки (и переименовывается в str), тогда как 2.x имеет строки байтов (str, "...") и строки юникода (unicode, u"..." ) это часто, но не всегда не совсем смешивается. (Разрешение их микширования было попыткой сделать переход от байтовых строк к юникоду проще, но это оказалось ошибкой.) В целом, поддержка юникода в Python довольно хорошая, несмотря на ошибки в Python 2.x. Имеются литералы Unicode с числовыми и именными escape-символами, объявления кодировки источника для символов, не входящих в ASCII, в литералах Unicode, автоматическое кодирование / декодирование с помощью модуля codecs, поддержка Unicode во многих библиотеках (например, в модулях регулярных выражений и DB-API) и встроенная база данных Unicode.

Тем не менее, все же необходимо знать о кодировках, чтобы правильно обрабатывать текст. Ваша программа будет получать байты в некоторой кодировке (будь то из файлов, из переменных среды или через другие входные данные), и их необходимо будет интерпретировать в этой кодировке. Если вы не знаете кодировку (и не можете определить ее по данным, как в HTML или XML), вы действительно можете обрабатывать данные только как байты. Если вы знаете кодировку, Python позволяет вам работать с ней в основном прозрачно.

6 голосов
/ 09 июня 2011

Perl имеет отличную поддержку юникода. Вам нужно знать, как правильно использовать, но я никогда не нахожу язык, который бы лучше поддерживал юникод, чем perl, особенно сейчас с perl5.14.

3 голосов
/ 09 июня 2011

Ракетка (в лагере Лисп / Схема) имеет хорошую поддержку Юникода.Ракетка отличает символьные строки (записано "abc") от байтовых строк (записано #"abc").Символьные строки состоят из символов Unicode и содержат все строковые операции с поддержкой Unicode, которые можно ожидать (сравнение, сворачивание регистра и т. Д.).По умолчанию Racket использует UTF-8 для ввода / вывода символьных строк (включая кодирование исходных файлов), но также поддерживает преобразование в и из других кодировок.Инструментарий GUI работает с Unicode.Как и регулярные выражения.

2 голосов
/ 09 июня 2011

Лиспы имеют сильную поддержку юникода. Все современные популярные списки (SBCL, Clozure CL, clisp) используют UTF-32 / UCS-4 для строк и поддерживают UTF-8 в качестве внешнего формата.

2 голосов
/ 09 июня 2011

Исходя из моего личного опыта, Ruby 1.9.2 хорошо обрабатывает внутренне юникод, за исключением некоторых странных областей, таких как методы upcase / downcase / capitalize для класса String. Я должен переопределить их для всех моих приложений Rails.

1 голос
/ 09 июня 2011

Примеры Ruby:

# encoding: UTF-8
puts RUBY_VERSION  # => 1.9.2

def Σ(arr)
  arr.inject(:+)
end

Π = Math::PI
str = "abc日本def"

puts Σ [4,6,8,3]  # => 21
puts Π            # => 3.141592653589793
puts str.scan(/\p{Han}+/)  # => 日本
p Encoding.name_list # not just utf8
#["ASCII-8BIT", "UTF-8", "US-ASCII", "Big5", "Big5-HKSCS", "Big5-UAO", "CP949", "Emacs-Mule", "EUC-JP", "EUC-KR", "EUC-TW", "GB18030", "GBK", "ISO-8859-1", "ISO-8859-2", "ISO-8859-3", "ISO-8859-4", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8", "ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "ISO-8859-13", "ISO-8859-14", "ISO-8859-15", "ISO-8859-16", "KOI8-R", "KOI8-U", "Shift_JIS", "UTF-16BE", "UTF-16LE", "UTF-32BE", "UTF-32LE", "Windows-1251", "BINARY", "IBM437", "CP437", "IBM737", "CP737", "IBM775", "CP775", "CP850", "IBM850", "IBM852", "CP852", "IBM855", "CP855", "IBM857", "CP857", "IBM860", "CP860", "IBM861", "CP861", "IBM862", "CP862", "IBM863", "CP863", "IBM864", "CP864", "IBM865", "CP865", "IBM866", "CP866", "IBM869", "CP869", "Windows-1258", "CP1258", "GB1988", "macCentEuro", "macCroatian", "macCyrillic", "macGreek", "macIceland", "macRoman", "macRomania", "macThai", "macTurkish", "macUkraine", "CP950", "CP951", "stateless-ISO-2022-JP", "eucJP", "eucJP-ms", "euc-jp-ms", "CP51932", "eucKR", "eucTW", "GB2312", "EUC-CN", "eucCN", "GB12345", "CP936", "ISO-2022-JP", "ISO2022-JP", "ISO-2022-JP-2", "ISO2022-JP2", "CP50220", "CP50221", "ISO8859-1", "Windows-1252", "CP1252", "ISO8859-2", "Windows-1250", "CP1250", "ISO8859-3", "ISO8859-4", "ISO8859-5", "ISO8859-6", "Windows-1256", "CP1256", "ISO8859-7", "Windows-1253", "CP1253", "ISO8859-8", "Windows-1255", "CP1255", "ISO8859-9", "Windows-1254", "CP1254", "ISO8859-10", "ISO8859-11", "TIS-620", "Windows-874", "CP874", "ISO8859-13", "Windows-1257", "CP1257", "ISO8859-14", "ISO8859-15", "ISO8859-16", "CP878", "SJIS", "Windows-31J", "CP932", "csWindows31J", "MacJapanese", "MacJapan", "ASCII", "ANSI_X3.4-1968", "646", "UTF-7", "CP65000", "CP65001", "UTF8-MAC", "UTF-8-MAC", "UTF-8-HFS", "UCS-2BE", "UCS-4BE", "UCS-4LE", "CP1251", "UTF8-DoCoMo", "SJIS-DoCoMo", "UTF8-KDDI", "SJIS-KDDI", "ISO-2022-JP-KDDI", "stateless-ISO-2022-JP-KDDI", "UTF8-SoftBank", "SJIS-SoftBank", "locale", "external", "filesystem", "internal"]

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

...