Синтаксис Юникода

Elixir поддерживает Юникод в языке.

Строки ("olá") и списки символов ('olá') поддерживают Юникод начиная с Elixir v1.0. Строки закодированы в UTF-8. Списки символов представляют собой списки кодовых точек Юникода. В таких случаях содержимое сохраняется в том виде, как его ввели разработчики, без каких-либо преобразований.

Elixir также поддерживает Юникод в переменных, атомах и вызовах начиная с Elixir v1.5. Цель этого документа — предоставить общее введение в то, как Elixir позволяет использовать Юникод в синтаксисе. Мы также предоставляем техническую документацию, описывающую, как Elixir соответствует спецификации Юникода.

Чтобы проверить версию Юникода вашей текущей установки Elixir, выполните String.Unicode.version().

Введение

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

Допустимые символы в идентификаторах — это те, которые определены Юникодом. В общем случае это символы, обычно используемые в активных письменных системах человеческих языков. В частности, это исключает символы, такие как эмодзи, альтернативные числовые представления, ноты и тому подобное.

Elixir накладывает много ограничений на идентификаторы в целях безопасности. Например, слово «josé» может быть записано двумя способами в Юникоде: как комбинация символов j o s é и как комбинация символов j o s e ́, где ударение — это отдельный символ. Первый вариант называется формой NFC, а второй — формой NFD. Elixir нормализует все символы до формы NFC.

Elixir также не допускает смешанных сценариев в большинстве случаев. Например, нельзя назвать переменную аdmin, где а на кириллице, а остальные символы — на латинице. В таком случае будет показано следующее сообщение об ошибке:

** (SyntaxError) invalid mixed-script identifier found: аdmin

Mixed-script identifiers are not supported for security reasons. 'аdmin' is made of the following scripts:

  \u0430 а {Cyrillic}
  \u0064 d {Latin}
  \u006D m {Latin}
  \u0069 i {Latin}
  \u006E n {Latin}

Make sure all characters in the identifier resolve to a single script or a highly
restrictive script. See https://hexdocs.pm/elixir/unicode-syntax.html for more information.

Символ должен быть либо полностью кириллическим, либо полностью латинским. Единственные смешанные сценарии, которые разрешает Elixir согласно рекомендациям высокострогого Юникода, это:

• Латиница и Хан с Бопомофо
• Латиница и японский
• Латиница и корейский

Наконец, Elixir также будет выводить предупреждение о проблемных идентификаторах в одном файле. Например, Elixir выведет предупреждение, если вы используете в коде обе переменные а (кириллица) и а (латиница).

Это общее введение в использование Юникода в идентификаторах Elixir. Вкратце, его цель — поддерживать различные используемые сегодня письменные системы, сохраняя при этом сам язык Elixir понятным и безопасным.

Технические подробности см. в следующих разделах, посвященных техническим требованиям к Юникоду.

Приложение Юникода #31

Elixir реализует требования, изложенные в Приложении Юникода #31.

R1. Идентификаторы по умолчанию

Общее правило Elixir для идентификаторов задается как:

<Identifier> := <Start> <Continue>* <Ending>?

где <Start> использует те же категории, что и в спецификации, но ограничивает их формой NFC (см. R6):

символы, полученные из общей категории Юникода для заглавных букв, строчных букв, прописных букв, модификаторов букв, других букв, буквенных чисел, плюс Other_ID_Start, минус Pattern_Syntax и Pattern_White_Space кодовые точки

В нотации множества: [\p{L}\p{Nl}\p{Other_ID_Start}-\p{Pattern_Syntax}-\p{Pattern_White_Space}].

и <Continue> использует те же категории, что и в спецификации, но ограничивает их формой NFC (см. R6):

символы ID_Start, плюс символы с общей категорией Юникода для неразрывных знаков, соединительных знаков, десятичных чисел, соединительной пунктуации, плюс Other_ID_Continue, минус Pattern_Syntax и Pattern_White_Space кодовые точки.

В нотации множества: [\p{ID_Start}\p{Mn}\p{Mc}\p{Nd}\p{Pc}\p{Other_ID_Continue}-\p{Pattern_Syntax}-\p{Pattern_White_Space}].

<Ending> — это добавление, специфичное для Elixir, которое включает только кодовые точки ? (003F) и ! (0021).

В спецификации также есть множество <Medial>, но Elixir не включает в него никаких символов. Поэтому правило для идентификаторов было упрощено.

Elixir не допускает использование ZWJ или ZWNJ в идентификаторах и поэтому не реализует R1a. R1b гарантируется в целях обратной совместимости.

Атомы

Атомы Юникода в Elixir следуют правилу идентификатора выше с такими изменениями:

• <Start> дополнительно включает кодовую точку _ (005F)
• <Continue> дополнительно включает кодовую точку @ (0040)

Обратите внимание, что атомы также могут быть приведены в кавычки, что позволяет использовать любые символы, например :"hello elixir". Все операторы Elixir также являются допустимыми атомами, например :+, :@, :|>, и другие. Полное описание допустимых атомов доступно в "Раздел «Атомы» в справочнике по синтаксису".

Переменные

Переменные в Elixir следуют правилу идентификатора выше с такими изменениями:

• <Start> дополнительно включает кодовую точку _ (005F)
• <Start> дополнительно исключает символы Lu (заглавные буквы) и Lt (прописные буквы)

В нотации множества: [\u{005F}\p{Ll}\p{Lm}\p{Lo}\p{Nl}\p{Other_ID_Start}-\p{Pattern_Syntax}-\p{Pattern_White_Space}].

R3. Pattern_White_Space и Pattern_Syntax символы

Elixir поддерживает только кодовые точки \t (0009), \n (000A), \r (000D) и \s (0020) в качестве пробелов и поэтому не соответствует требованию R3. R3 требует поддержки более широкого набора пробелов и символов синтаксиса.

R6. Отфильтрованные нормализованные идентификаторы

Идентификаторы в Elixir регистрозависимы.

Elixir требует, чтобы все атомы и переменные были в форме NFC. Если указана другая форма, форма NFC автоматически применяется. Однако атомы и строки в кавычках могут быть в любой форме и не проверяются анализатором.

Иными словами, атом :josé может быть записан только с кодовыми точками 006A 006F 0073 00E9 или 006A 006F 0073 0065 0301, но Elixir перепишет его на первый вариант (начиная с Elixir 1.14). С другой стороны, :"josé" может быть записан как 006A 006F 0073 00E9 или 006A 006F 0073 0065 0301, и его форма будет сохранена, поскольку он записан в кавычках.

Выбор требования R6 автоматически исключает требования R4, R5 и R7.

Технический стандарт Юникода #39

Elixir соответствует пунктам, описанным в Техническом стандарте Юникода #39 по безопасности.

C1. Общий профиль безопасности для идентификаторов

Elixir не позволит токенизацию идентификаторов с кодовыми точками в \p{Identifier_Status=Restricted}.

Реализация, следующая за общим профилем безопасности, не допускает никаких символов в \p{Identifier_Status=Restricted}, ...

Например, символ «ЗАПОЛНИТЕЛЬ ХАНГУЛЬ» (ㅤ), который часто невидим, — это редкая кодовая точка, которая вызовет это предупреждение.

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

C2. Обнаружение проблемных символов

Elixir выведет предупреждение для идентификаторов, которые выглядят одинаково, но на самом деле отличаются. Например, в а = a = 1, два символа «a» — кириллический и латинский, и их можно перепутать; в 力 = カ = 1, оба — японские, но разные кодовые точки, в разных системах письма. Проблемные идентификаторы могут привести к трудноуловимым ошибкам (например, из-за скопированного и вставленного кода) и могут быть небезопасны, поэтому мы будем выводить предупреждение о идентификаторах в одном файле, которые могут быть перепутаны друг с другом.

Мы используем методы, описанные в разделе 4, «Обнаружение проблемных символов», с одним замечанием.

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

Elixir не будет выводить предупреждение об идентификаторах, состоящих исключительно из символов a-z, A-Z, 0-9 и подчеркивания, поскольку идентификаторы ASCII существуют уже давно, и сообщество программистов разработало свои способы обработки проблемных символов между идентификаторами, такими как l,1 или O,0 (например, шрифты, предназначенные для программирования, обычно делают эти символы легко различимыми).

C3. Обнаружение смешанных сценариев

Elixir не позволит токенизацию смешанных сценариев, если смешение не является одним из исключений, определенных в UTS 39 5.2, «Высокострого». Мы используем методы, описанные в разделе 5.1, «Обнаружение смешанных сценариев», для определения того, происходит ли смешение сценариев, с модификацией, описанной в разделе «Дополнительные нормализации» ниже.

Примеры: Elixir позволяет использовать идентификаторы, такие как 幻ㄒㄧㄤ, даже если они включают символы из нескольких «сценариев», потому что эти сценарии «сводятся» к японскому, когда применяются правила разрешения из UTS 39 5.1. Он также позволяет атому, такому как :Tシャツ, японскому слову для «футболки», которое включает в себя заглавную латинскую букву Т, потому что {Latn, Jpan} — это одно из разрешенных смещений сценариев в определении «Высокострого» в UTS 39 5.2, и оно «покрывает» строку.

Однако Elixir предотвратит токенизацию кода, такого как if аdmin, do: :ok, else: :err, где множество символов для символа «a» равно {Кириллица}, но все другие символы имеют множества символов {Латиница}. Множества сценариев не сводятся, и множества сценариев из определения «Высокострого» в UTS 39 5.2 тоже не охватывают строку, поэтому отображается описательная ошибка.

C4, C5 (неприменимо)

Соответствие требованиям «C4 — Обнаружение уровня ограничений» не утверждается и не применяется к идентификаторам в коде; вместо этого оно применяется для классификации уровня безопасности заданной произвольной строки в один из 5 уровней ограничений.

Соответствие требованиям «C5 — Обнаружение смешанных чисел» неприменимо, поскольку Elixir не поддерживает числовые значения Юникода.

Дополнительные нормализации и задокументированные модификации UTS 39

Начиная с Elixir 1.14, некоторые кодовые точки в \p{Identifier_Status=Restricted} нормализуются до других, не ограниченных кодовых точек.

Изначально это делается только для перевода знака МИКРО µ в греческую строчную му μ.

Это не является модификацией пунктов UTS39 C1 (Общий профиль безопасности) или C2 (Обнаружение проблемных символов); однако это задокументированная модификация C3, «Обнаружение смешанных сценариев».

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

• Например, в примере MICRO => MU символ Micro был символом сценария 'Common' — тот же сценарий, что и у символа '_' подчеркивания — и поэтому набором сценариев нормализованного символа будет {Greek, Common}. 'Common' пересекается со всеми ненулевыми наборами сценариев, и поэтому нормализованный символ может использоваться в токенах, написанных на любом языке, без возникновения смешения сценариев.

• Кодовые точки, нормализованные таким образом, — это те, которые используются в сообществе, и, как считается, вряд ли приведут к проблемам со смешением сценариев, представляющим опасность. Например, кодовое значение MICRO или MU может использоваться в атоме или переменной, связанной с микросекундами.