Исходный код Синтаксис Юникода

Elixir поддерживает Юникод на протяжении всего языка. Этот документ — полная справка о том, как 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, версия 15.0.

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

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

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

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

символы, полученные из общей категории Юникода заглавных букв, строчных букв, прописных букв, модификаторных букв, других букв, буквенных чисел, плюс 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 (см. R4):

символы 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}].

Псевдонимы

Псевдонимы в Elixir допускают только символы ASCII, начиная с заглавной буквы, и без знаков препинания.

R3. Символы пробелов шаблонов и синтаксиса шаблонов

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

R4. Эквивалентные нормализованные идентификаторы

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

Elixir приводит все атомы и переменные к форме 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, и его форма будет сохранена, так как он записан в кавычки.

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

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

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

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

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

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

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

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

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シャツ, японское слово для «футболки», который включает заглавную латинскую букву 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, 'обнаружение смешанных сценариев'.

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

• Например, в примере МИКРО => МЮ, Микро был символом 'Общие' сценарии — тот же сценарий, что и у символа '_' — и, таким образом, набор сценариев нормализованного символа будет {Греческий, Общие}. 'Общие' пересекаются со всеми непустыми наборами сценариев, и, таким образом, нормализованный символ может использоваться в токенах, написанных на любом сценарии, без возникновения смешения сценариев.

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