LINUX.ORG.RU

Вышла новая версия стандарта Unicode: 6.3.0

 ,


3

1

Unicode Consortium объявил о выпуске Unicode Standard 6.3.0 — универсального стандарта для кодирования текстов на любых языках мира.

Главные изменения нового выпуска касаются двунаправленного письма (bi-directional writing, сокр. BiDi), то есть чередования в тексте письма слева направо и справа налево. В языках, где пишут справа налево (арабский, иврит и др.), такое смешение проиходит очень часто, например, при записи чисел арабскими цифрами, вставке иностранных (в т.ч. английских) слов и так далее.

В версии 6.3.0 введено понятие фраз, изолированных по направлению письма (bi-directional isolates). Ранее они уже появились в HTML5 (тег <bdi>). Изолированные фразы должны отображаться в своём направлении, вне зависимости от окружающего текста. Существующие уже символы U+202A LRE и U+202B RLE имеют похожее действие, но являются «сильными» с точки зрения алгоритма отображения, то есть могут повлиять на отображение окружающих символов. Иногда это нежелательно, но обходится только нетривиальным анализом текста для правильной вставки кодов направления письма. Изоляты таких проблем вызывать не должны, потому что на окружающий текст не влияют. Для них определены следующие новые коды:

  • U+2066 LEFT-TO-RIGHT ISOLATE
  • U+2067 RIGHT-TO-LEFT ISOLATE
  • U+2068 FIRST STRONG ISOLATE (вводит изолят с автоматически определяемым направлением письма)
  • U+2069 POP DIRECTIONAL ISOLATE (обозначает конец изолята)

Помимо этих символов появился ещё один, тоже связанный с BiDi:

  • U+061C ARABIC LETTER MARK (как U+200F RLM, только для арабского языка, Bidi_Class = AL).

Внесены соответствующие изменения в Unicode Standard Annex #9: Unicode Bidirectional Algorithm.

Когда у вас ОС и браузер начнут поддерживать Unicode 6.3.0, три строчки ниже будут отображаться одинаково. Если только две верхние отображаются одинаково, у вас поддерживается Unicode от 1.1 до 6.2, но не 6.3:

Linux.org.ru Linux.org.ru ur.gro.xuniL
Linux.org.ru Linux.org.ru ‮Linux.org.ru‬
Linux.org.ru ‮Linux.org.ru ⁦Linux.org.ru⁩‬


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

Для подробной информации читайте UAX #9 или предложение о введении BiDi-изолятов в Unicode (Aharon Lanin et al.).

Ещё одно важное нововведение, не связанное с BiDi, — это наведение порядка с выбором вариантов иероглифов в блоке CJK Compatibility Ideographs (U+F900 — U+FAFF). Эти иероглифы имеют больше одной формы, и раньше при нормализации текста иероглиф мог нежелательным образом поменять форму, а теперь такого не будет.

Также есть ряд точечных изменений, касающихся отдельных символов и деталей алгоритмов.

Помимо указанных выше 5 контрольных кодов, в 6.3.0 никаких новых символов (в частности, отображаемых) нет. В Core Specification не будет внесено никаких изменений — сохраняет действие версия 6.2.0, за исключением обновленного определения case-ignorable (параграф 3.13, определение D136). Кроме того, ещё с января действует Corrigendum #9 о понятии noncharacter.


Unicode 6.3.0

>>> Объявление о выпуске

★★★★★

Проверено: Shaman007 ()

Прикольно, в akregator в этой статье после манипуляций с направлением письма весь текст до конца остался перевёрнутым.

Belomir ()

воротагерка роткетед дерт

dekar ()

Эх, еще бы фонетические значки для немецкого сделали. Дело в том, что немцы, при наличии в Юникоде всего международного фонетического алфавита, решили выпендриться и используют несколько уникальных символов для ряда звуков. Филологи мучаются, или раскапывая специальные шрифты, или вставляя уродливый растр.

Bagrov ★★★★ ()

Всегда особенно уважал разработчиков этого стандарта. Это ж сколько нюансов им приходится учитывать! Посмотришь на юникодные таблицы, и весь мир как на ладони. Вот бы они когда-нибудь добавили символы из т.н. «Рукописи Войнича».

CARS ★★★★ ()
Ответ на: комментарий от CARS

Синдарин лучше. Им хотя бы пользуются.

anonymous ()
Ответ на: комментарий от ZuBB

akregator?
Хотя, может быть и у других RSS читалок всё грустно.

dekar ()
Ответ на: комментарий от CARS

Все это конечно хорошо, но с шрифтами с более-менее приличным покрытием все довольно печально :(

X-Pilot ★★★★★ ()
Ответ на: комментарий от Belomir

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

anonymous ()

«Управляющих» кодов, а не «контрольных». Контрольными бывают суммы, например — по ним контролируют правильность, а обсуждаемые коды управляют выводом.

anonymous ()

У меня в Konqueror 4.8.4 два абзаца после трех примерных строк написаны справа налево. Так и должно быть?? Может взять эти строки в какой-нибудь дополнительный div или еще как-то, воизбежании?

shaplov ★★ ()
Последнее исправление: shaplov (всего исправлений: 1)

Символ pony не ввели ещё? А то U+1F40E как то недостаточно.

fornlr ★★★★★ ()
Ответ на: комментарий от anonymous

Синдарин это язык, его в юникоде не может быть просто по определению, записывают его чаще всего либо латиницей, либо тенгваром, какая-то движуха по включению последнего в юникод вроде как есть: http://en.wikipedia.org/wiki/Tengwar#Unicode

MrClon ★★★★★ ()
Ответ на: комментарий от CARS

Вот бы они когда-нибудь добавили символы из т.н. «Рукописи Войнича».

А также из т. н. «Велесовой книги».

NaN ()

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

fero ★★★★ ()

Как у BSD с поддержкой Unicode?

NaN ()
Ответ на: комментарий от CARS

Посмотришь на юникодные таблицы, и весь мир как на ладони.

Насколько я помню - не весь. Китайцев против их воли унифицировали с японцами.

hobbit ★★★★★ ()
Ответ на: комментарий от fero

Как хорошо, что эти убогие времена закончились.

Deleted ()

Новости о новых стандартах меня пугают.

frugurt ()
Ответ на: комментарий от CARS

Всегда особенно уважал разработчиков этого стандарта.

За упорство в бессмысленном причинении вреда?

Кодировки были неизбежным злом в диком XX веке. При нынешних объемах памяти и быстродействии процессоров они стали просто злом. Письменности-то со временем меняются.

ST ()
Ответ на: комментарий от ST

При нынешних объемах памяти и быстродействии процессоров они стали просто злом. Письменности-то со временем меняются.

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

proud_anon ★★★★★ ()
Ответ на: комментарий от fero

Там даже для спецсимволов места не хватит. Что уж говорить о других языках. Если ты языкам не обучен, не значит, что остальные тоже неграмотные.

Deleted ()
Ответ на: комментарий от NeProfessor

Тестовые версии стандартов - это как?

Почему тестовые? Бета-тест этой версии Юникода закончился, это уже релиз.

proud_anon ★★★★★ ()
Ответ на: комментарий от Deleted

Есть русский и ингриш, остальные не нужны

fero ★★★★ ()
Ответ на: комментарий от fero

И как там, в вашей параллельной вселенной?

Deleted ()
Ответ на: комментарий от proud_anon

Я бы начал думать примерно так. В любой письменности существуют базовые графические элементы (скажем, 11, вроде бы, основных черт в китайской). Дальше они по специфическим для данной письменности правилам собираются в графемы (например, буквы). Дальше графемы компонуются в слоги (корейский алфавит), слова (большинство алфавитных письменностей) или иероглифы. Дальше это все упихивается в строки, абзацы и т. д.

Отдельно существует информация о стиле начертания графических примитивов и вариантах графем. Сейчас она неявно утоптана в шрифты, но если художник-полиграфист может, поглядев на десяток букв шрифта, довольно точно восстановить отсутствующие, ее вполне можно извлечь, формализовать и хранить отдельно.

Получаем несколько баз данных о собственно письменности и набор баз данных о способах начертания графем, заменяющий шрифты. Они позволяют не только генерировать битмапы текстов, но и сравнительно легко и быстро пополнять набор доступных символов силами квалифицированных пользователей. То есть вышеупомянутые немецкие филологи (а также математики, физики и изобретатели языков) могли бы не дожидаться, пока юникодовские власти снимутся с ручника, а самостоятельно изготовить нужные закорючки и подгрузить их в общедоступную базу. Или хотя бы упаковать прямо в документы.

ST ()

Кто с юникодом работает, поделитесь, на сколько это важно на практике, иметь классический индексный доступ к символам в строке?

aist1 ★★ ()
Ответ на: комментарий от fornlr

Символ pony не ввели ещё? А то U+1F40E как то недостаточно.

И ещё символы всех известных науке cutiemarks.

rtvd ★★★★★ ()
Ответ на: комментарий от CARS

Всегда особенно уважал разработчиков этого стандарта. Это ж сколько нюансов им приходится учитывать! Посмотришь на юникодные таблицы, и весь мир как на ладони. Вот бы они когда-нибудь добавили символы из т.н. «Рукописи Войнича».

Ну для начала, нет однозначного мнения, какими должны быть эти символы и будут ли они иметь значение. По одной из версий, информацию несут не сами символы этой рукописи, а «дефекты» в их отрисовке.

rtvd ★★★★★ ()
Ответ на: комментарий от ST

Кодировки были неизбежным злом в диком XX веке. При нынешних объемах памяти и быстродействии процессоров они стали просто злом. Письменности-то со временем меняются.

Предложи вменяемую альтернативу.

rtvd ★★★★★ ()
Ответ на: комментарий от lucky_guy

Ну и кому, кроме вас нужна будет эта хр*нь?

Мне

rtvd ★★★★★ ()
Ответ на: комментарий от ST

В любой письменности существуют базовые графические элементы (скажем, 11, вроде бы, основных черт в китайской). Дальше они по специфическим для данной письменности правилам собираются в графемы (например, буквы).

Во-первых, не 11, а более 20. Во-вторых, я не видел ещё «правил конструирования произвольного иероглифа из базовых черт». Даже такую вещь, как порядок черт в уже готовом иероглифе, описывают так: «Ну... обычно слева направо сверху вниз, но далеко не всегда, единственно гарантированный способ — запомнить для каждого знака». А уж тем более я не видел «правил выведения значения иероглифа из базовых черт». Да что уж там, нет даже верного способа вывести значение слова из составляющих его иероглифов!

Поэтому как свести весь набор иероглифов к базовым элементам и общему порядку композиции, я ума не приложу. Думаю, если бы кто в мире знал такой способ, он бы уже давно был известен.

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

Почему это такой метод обязательно можно формализовать? Художник-полиграфист вполне способен решать такие задачи, которые компьютер пока решить не может. Но в любом случае, Юникод не регламентирует точный внешний вид символов.

Получаем несколько баз данных о собственно письменности

Я так и не понял, какая хоть примерно информация в них должна быть.

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

То есть универсальный код обмена информацией превращается в Википедию? И даже редактировать тексты без доступа к этому серверу с БД более не будет возможности? И все компьютеры в мире становятся зависимы от одного сервера или группы серверов?

Или хотя бы упаковать прямо в документы.

Так это они и сейчас могут. Просто присвоить этим символам коды из категории private use и договориться с коллегами, чтобы у них были установлены соответствующие шрифты. Или встроить эти шрифты в документы, когда это возможно.

Другое дело, что я в этой теме в первый раз вообще слышу про какие-то особые немецкие фонетические значки и что немецким фонетистам не хватает IPA.

proud_anon ★★★★★ ()
Ответ на: комментарий от proud_anon

я не видел ещё «правил конструирования произвольного иероглифа из базовых черт»

Но для каждого конкретного они вполне себе существуют. Вот для каждого и хранить. И совсем не обязательно все-все-все собирать из голых черт; ссылки на ранее описанные графемы и даже целые иероглифы («чтобы написать иероглиф „младшая_сестра“, в левой половине нарисуй „женщину“, а потом...») ускорят дело и сократят объем базы.

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

Почему это такой метод обязательно можно формализовать?

Потому, что нужно :)

Там никакой черной магии нет. Из каких черточек состоит буква, мы знаем. Смотрим на изображение буквы в конкретном шрифте и соображаем, чем и как именно нужно было рисовать каждую черточку, чтобы получилось то, что мы видим. Тупо переносим то, что заметили, на те же черточки в других буквах.

Может быть, потребуются математические модели орудий письма. Их опять-таки конечное количество, а действительно сложное поведение разве что у кисточки. Ну, и со всякими мелкими деталями, дорисованными уголком пера, придется малость подумать и повозиться. Но это, в принципе, и всё.

Получаем несколько баз данных о собственно письменности

Я так и не понял, какая хоть примерно информация в них должна быть.

Основные черты. Построение из них графем. Компоновка графем в знакоместа. Компоновка знакомест в строки. Компоновка строк на листе. Ну, все то, что некоторым из присутствующих в школе зарядили в мозги, начиная с палочек и кружочков.

То есть универсальный код обмена информацией превращается в Википедию?

Приблизительно. Только не код превращается, а база знаний вытесняет код за вредность. Пять тысяч лет письменности бодро развивались без единого центра стандартизации и отлично себя чувствовали. Думаю, им и дальше без всемирного буквенфюрера будет гораздо лучше, чем с ним.

И даже редактировать тексты без доступа к этому серверу с БД более не будет возможности?

Локальной копии, пусть и малость устаревшей (либо, напротив, чуток дополненной владельцем), в большинстве случаев должно хватить.

И все компьютеры в мире становятся зависимы от одного сервера или группы серверов?

Примерно в той же степени, в которой сейчас зависят от серверов, хранящих фонты.

Так это они и сейчас могут. Просто присвоить этим символам коды из категории private use и договориться с коллегами, чтобы у них были установлены соответствующие шрифты. Или встроить эти шрифты в документы, когда это возможно.

Куча тупой ручной работы. К тому же, художник-шрифтовик и фонтодел все-таки отдельные профессии, так что на выходе мы с изрядной вероятностью получим очень кривой и вырвиглазный глиф для единственного шрифта (и задолбавшегося по самое не балуйся филолога-физика-математика). А то, о чем я говорю, позволит мышкой собрать графему из стандартных черточек-кружочков или даже просто добавить крючок-другой к уже существующей букве — и автомагически получить на выходе глифы профессионального качества для всех шрифтов.

ST ()
Ответ на: комментарий от aist1

к Какое же говнище этот ваш С++ (комментарий)

А высокоуровневая VM с JIT-ом и сборкой мусора — это так себе работенка, любой её налабает на коленках.

а что тут такого? да, налабают

кстати, на D приятнее код выглядит, чем на C++ (см. тот же daovm.net + LLVM JIT)

anonymous ()
Ответ на: комментарий от anonymous

Если хочешь потрындеть со мной по этому предмету, создай отдельную тему :)

aist1 ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.