Помня, что нужно делать все, что вам нужно сделать на PHP, чтобы заставить его работать правильно с Unicode, слишком сложно, утомительно и подвержено ошибкам, поэтому я ищу трюк, чтобы 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 ).
Все регулярные выражения и функции regexy прозрачно работают в Unicode (т. Е. Как и все preggers имеют /u неявно закреплены, и такие вещи, как \w и \b и \s работают в Unicode так, как это требует Unicode Standard , и т. Д.). ,
Для дополнительного кредита :), я бы хотел, чтобы был способ «обновить» это объявление до полного режима графемы. Таким образом, функции байта или символа становятся функциями графемы (например, grapheme_strlen , grapheme_strstr , grapheme_strpos и grapheme_substr ), а материал регулярных выражений работает на правильных графемах (т . Е. – или даже [^abc] – соответствует кластеру Unicode grapheme независимо от того, сколько кодовых точек оно содержит и т. д.).
Эта полноформатная юникодная вещь была именно идеей PHP 6, которая была отменена более года назад.
Итак, нет, нет никакого способа получить все это – кроме как с помощью правильных функций, и помня, что символы не совпадают с байтами.
Однако одна вещь, которая может помочь вам в четвертом пункте, это функция перегрузки функции mbstring (цитирование) :
mbstring поддерживает функцию «перегрузки функций», которая позволяет добавлять многобайтовые сообщения в такое приложение без изменения кода путем перегрузки многобайтовых копий стандартных стандартных функций.
Например,mb_substr()вызывается вместоsubstr()если включена функция перегрузки.
Все байт-функции (например, 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, если повезет)