Декларация, чтобы сделать PHP скрипт полностью Unicode-friendly

Question

Помнить, что все, что вам нужно сделать в PHP, чтобы заставить его работать должным образом с Юникодом, слишком сложно, утомительно и подвержено ошибкам, поэтому я ищу способ заставить PHP магически обновиться абсолютно все, что возможно, от затхлого старого байтового режима ASCII до современного символьного режима Unicode, все сразу и с помощью одного простого объявления.

Идея состоит в том, чтобы модернизировать PHP-скрипты для работы с Unicode без необходимости загромождать исходный код кучей запутанных альтернативных вызовов функций и специальных регулярных выражений. Все должно просто «Делать правильные вещи» с Unicode, без вопросов.

Учитывая, что целью является максимальная уникальность с минимальной суетой, эта декларация должна как минимум делать эти вещи (плюс все, что я забыл, что способствует достижению общей цели):

• Источник сценария PHP сам по себе считается в UTF ‑ 8 (например, строки и регулярные выражения).

• Все входные и выходные данные автоматически преобразуются в / из UTF ‑ 8 по мере необходимости и с возможностью нормализации (например, все входные данные нормализуются к NFD и все выходные данные нормализуются к NFC).

• Все функции с версиями Unicode используют их вместо (например, Collator::sort для sort).

• Все байтовые функции (например, strlen, strstr, strpos и substr) работают как соответствующие символьные функции (например, mb_strlen, mb_strstr, mb_strpos, и mb_substr).

• Все регулярные выражения и функции регулярных выражений прозрачно работают на Unicode (то есть, как и все преггеры, неявно привязаны к /u, а такие вещи, как \w и \b и \s все работают на Unicode способ Unicode Standard требует их для работы , и т. Д.)

Для дополнительного кредита :), я хотел бы, чтобы был способ "обновить" это объявление до режима полной графемы. Таким образом, байтовые или символьные функции становятся функциями графемы (например, * 1061). *, grapheme_strstr, grapheme_strpos и grapheme_substr), а регулярные выражения работают на правильных графемах (т. Е. . - или даже [^abc] - соответствует кластеру графических символов Unicode независимо от того, сколько кодовых точек оно содержит и т. д.).

Answer 1

То, что full-unicode было именно идеей PHP 6 - которая была отменена больше, чем год назад.

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

Одна вещь, которая может помочь вам четвертымТем не менее, точкой является Функция перегрузки функции расширения mbstring (цитирование) :

mbstring поддерживает a 'функция «перегрузка функции», которая позволяет вам добавить многобайтовую осведомленность в такое приложение без модификации кода, перегружая многобайтовые аналоги в стандартных строковых функциях.
Например, mb_substr() вызывается вместо substr(), если включена перегрузка функции.

Answer 2

Все байтовые функции (например, strlen, strstr, strpos и substr) работают как соответствующие символьные функции (например, mb_strlen, mb_strstr, mb_strpos и mb_substr).

Этоне очень хорошая идея.

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

Например, выложите заголовок 'Content-Length: '.strlen($imageblob), и вы получите сбой, если он вдруг использует семантику кодовой точки.

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

Вот почему в IMO подход с использованием единственного строкового типа данных, который можно обрабатывать семантикой байтов или кодовых точек, обычно является ошибкой.Языки, которые предоставляют отдельные типы данных для байтовых строк (с байтовой семантикой) и символьных строк (с семантикой кодовой точки Unicode (*)), как правило, более согласованы.

(*: или семантика кодовой единицы UTF-16, если не повезло)