Рубрика «Unicode» - 5

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

Последние версии iOS и Android имеют поддержку более 1200 символов эмодзи, но «десктопный» рынок не может похвастаться такими успехами. Мы же в Badoo хотим и делаем все, чтобы пользователям было комфортно общаться на всех платформах, не имея никаких ограничений в переписке.
Далее я расскажу, каким способом мы добились 100% поддержки эмодзи для веба.
Читать полностью »

Регулярные выражения в JavaScript понемногу догоняют PCRE.

Недавно упомянутая возможность lookbehind перешла на стадию флага --es_staging.

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

В продвижении lookbehind и character properties, на мой взгляд, есть две разницы: первая возможность вводит совсем немного нового синтаксиса по сравнению со второй, зато вторая меньше изменяет поведение всего процесса (сравните количество затрагиваемых изменениями файлов в исходниках V8 по двум упомянутым ссылкам). По сути, свойства Юникода — всего лишь удобные сокращения, синонимы для разных групп codepoint-ов, поэтому от них можно ожидать минимум подвохов при интеграции в систему.

Конечно, обе возможности не советуют применять в продукции (кроме Google Chrome, они нигде в браузерах не реализованы, а Node.js только-только переходит на соответствующую им версию V8, в которой они всё равно пока под флагами).

Но для личных нужд (утилиты по обработке текста и т.д.), мне кажется, они вполне применимы. Возможно, коду разработчиков V8, даже экспериментальному, можно порой доверять с ничуть не большим риском, чем разнообразным библиотекам на npmjs или GitHub.Читать полностью »

image

Инициативная группа товарищей Emojination ратует за включение в обширный список эмодзи-иконок, уже присутствующих в стандарте Unicode, схематического изображения пельмешка. Группа запустила краудфандинговую кампанию «The Dumpling Emoji Project» по сбору средств для этой благородной цели и уже набрала более $11000 при заявленной необходимости в $3750.

Аналоги пельменей есть практически во всех кухнях мира. Вареники (в Польше они называются "pierogi"), равиоли, хинкали, эмпанада, цзяоцзы… Но, как описано в «пельменной» кампании по сбору средств, эмодзи для пиццы, гамбургера и тако – есть, а для пельменей – нет. Исправлять эту несправедливость планируется, войдя в состав комитета, утверждающего расширение стандарта Unicode.

Эта привилегия стоит $2500 в год – для членов, не имеющих права голоса (за право голосовать необходимо отдавать $18000 в год, и этим пользуются всего 11 членов комитета).
Читать полностью »

Финляндия первой в мире выпустила «национальные» эмодзи - 1

Финляндия стала первой страной в мире, которая выпустила «национальный» набор эмодзи — несколько маленьких пиктограмм для общения в чате. Выбор пиктограмм сугубо специфичный для этой северной страны: голые мужчина и женщина в сауне (пиктограмма «Сауна»), поклонник музыки в стиле «металл» (пиктограмма «Металлист») и легендарный телефон Nokia 3310 (пиктограмма «Небьющийся»).
Читать полностью »

Mimic: вредоносный скрипт, который портит нервы программистам - 1Участники российских государственных тендеров раньше применяли маленькую хитрость: заказчик и поставщик заранее договариваются о сделке. Затем в условиях тендера на открытом сайте некоторые кириллические символы заменяют на латинские, чтобы конкурент не нашёл тендер с помощью поиска.

Такой же способ используют авторы вредоносного скрипта Mimic, но с другой целью: испоганить программный код таким способом, что он не будет компилироваться, вызовет сотни синтаксических ошибок, а программист не сможет понять, в чём дело.

Например, в коде C# обычный символ точки с запятой (;) заменяется на греческий вопросительный знак (;). Подло, зато эффективно.
Читать полностью »

Казалось бы, в Юникод включили уже все возможные и невозможные символы. В последней версии Unicode 7.0 добавлено 23 новых письменности, включая древнепермское письмо и почти полностью расшифрованное линейное письмо А минойской цивилизации 2000 г до н.э., сотни экзотических эмотиконов.

Общее количество символов в Unicode превысило 110 000 штук. Казалось бы, там уже есть все распространённые символы. Оказывается, это не так. До сих пор остались люди, которые не могут написать в Юникоде даже собственное имя. Им приходится прибегать к разным трюкам.

О своей проблеме рассказал индийский IT-специалист, имя которого мы не можем правильно напечатать, разве что в транслитерации: Адитья Мукереджи.
Читать полностью »

def maps():
	print "maps maps maps"

def spam():
	print "Erasing everything..."
	print "done."

Вы знаете, что если очень долго смотреть на следующую строку, то там останутся только три слова «spam»?

s = "spam‮" ,spam ,"‬spam"
s[1]()

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

Посмотреть на ideone. (Для тех кто не знает: там внизу есть вывод выполнившейся программы)
Читать полностью »

Сидел вечером дома, думал чем бы заняться. А: у Python есть отладчик, но в нём совершенно некрасивое приглашение ко вводу. Дай‐ка я впилю туда powerline. Дело казалось бы совершенно плёвое: нужно просто создать свой подкласс pdb.Pdb со своим свойством, да?

def use_powerline_prompt(cls):
    '''Decorator that installs powerline prompt to the class
    '''
    @property
    def prompt(self):
        try:
            powerline = self.powerline
        except AttributeError:
            powerline = PDBPowerline()
            powerline.setup(self)
            self.powerline = powerline
        return powerline.render(side='left')

    @prompt.setter
    def prompt(self, _):
        pass

    cls.prompt = prompt

    return cls

Читать полностью »

Когда идентификатор не идентификатор (Атака монгольского разделителя гласных) - 1

Примечания переводчика

В переводе я позволил себе использовать некоторые англицизмы, такие как «валидный», «нативный» и «бинарник». Надеюсь с ними вопросов не возникнет.

Идентификаторы (identifiers) – специальный термин спецификации C# отожествляющий собой всё к чему можно обратиться по имени, как например название класса, имя переменной и т.д.

Roslyn – компилятор C# кода, написанный на C#. Был создан взамен существующего csc.exe. Я обычно опускаю слово компилятор в данном тексте.

Для начала несколько вещей о которых вы могли не слышать:

  • Идентификаторы в C# могут включать в себя escape-последовательности Unicode символов (как например u1234).
  • Идентификаторы в C# могут включать в себя Unicode символы категории Cf (other, format), но при сравнении идентификаторов на идентичность эти символы игнорируются.
  • Символ «Монгольский разделитель гласных» (U+180E) в зависимости от версии Unicode принадлежит либо категории Cf (other, format), либо категории Zs (separator, space).
  • В .NET хранится свой собственный список Unicode категорий, независимый от оных в Win32.
  • Roslyn является .NET приложением, и поэтому использует Unicode категории, прописанные в файлах .NET. Нативный компилятор (csc.exe) использует либо системные (Win32) категории, либо хранит в себе копию таблиц Unicode.
  • Никакая из таблиц Unicode символов (ни .NET, ни Win32) точно следует какой-либо из версий стандарта Unicode.
  • Компиляторы могут иметь баги.

Из всего этого вытекают некоторые проблемы…

Во всём виноват Владимир

Все началось с обсуждения на собрании технической группы ECMA на прошлой неделе. Мы рассматривали «нормативные ссылки», и в частности какую версию стандарта Unicode мы будем использовать. На тот момент спецификация ECMA-335 (4-ое издание) использует Unicode 4.0, а спецификация C# 5 от Microsoft использует Unicode 3.0. Я точно не знаю, учитывают ли разработчики компиляторов такие особенности. На мой взгляд было бы лучше, если ECMA и Microsoft не указывали конкретную версию Unicode в своих спецификациях. Пусть разработчики компиляторов используют самую свежую версию Unicode, доступную на текущий момент. Однако тогда компиляторы должны будут поставляться со своей личной копией таблицы Unicode, что немного странно, на мой взгляд.
Читать полностью »

В рамках моей «работы» над стандартизацией C# 5 в технической группе ECMA-334 TC49-TG2 мне посчастливилось увидеть несколько интересных способов, которыми Владимир Решетников проверял C# на прочность. В данной статье описана одна из проблем, которые он поднял. Разумеется, она, скорее всего, никак не затронет 99.999% C#-разработчиков… но разобраться все равно любопытно.

Спецификации, используемые в статье:

Что такое строка?

Как бы вы объявили тип string (или System.String)? Я могу предположить несколько вариантов ответа на данный вопрос, от расплывчатых до довольно конкретных:

  • «Какой-нибудь текст в кавычках»
  • Последовательность символов
  • Последовательность символов Юникода
  • Последовательность 16-битных символов
  • Последовательность кодов UTF-16

Только последнее утверждение полностью верно. Спецификация C# 5 (раздел 1.3) гласит:

Обработка строк и символов в C# использует UTF-16. Тип char представляет код UTF-16, а тип string – последовательность кодов UTF-16.

Пока всё в порядке. Но это C#. А как насчет IL? Что используется там, и имеет ли это значение? Оказывается, что имеет… Строки должны быть объявлены в IL как константы, и природа этого способа представления важна – не только кодировка, но и интерпретация этих закодированных данных. В частности, последовательность кодов UTF-16 не всегда может быть представлена в виде последовательности кодов UTF-8.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js