Всем известно, что у PHP проблемы с Unicode. Версия 6 фактически заброшена из-за трудностей реализации Unicode. Но мне интересно, кто-нибудь знает, каковы точные причины? Проблемы архитектуры / дизайна, проблемы производительности, проблемы сообщества (я держу пари, что нет), что-то другое?
Ответы:
PHP как язык определенно может иметь его, но я думаю, что проблема заключается в совместимости с существующими программами. Поддержка Юникода может сломать их тонкими способами, что является самым раздражающим видом ошибки.
В настоящее время большинство функций обработки строк в PHP «бинарно-безопасны», что означает, что вы можете использовать их для обработки любого файла в любой кодировке, а также в двоичных форматах, таких как данные изображения и т. Д.
С добавлением строк Unicode вам нужно быть очень осторожным, чтобы не смешивать строки Unicode с двоичными строками (довольно сложно, когда ваши строки поступают из разных источников, и вам никогда не приходилось беспокоиться об этом раньше). И вы не можете больше не знать о кодировках (и многие сценарии не знают об этом!)
Еще одна сложная, но решаемая проблема - произвольный доступ в строках Unicode. Реализация $string[$offset]изменений от тривиального до очень медленного или немного медленного и очень сложного.
Также я думаю, что было ошибкой выбирать UTF-16 в качестве внутренней кодировки для PHP. У него те же проблемы, что и у UTF-8 (переменная ширина из-за суррогатных пар) и неэффективность UCS-2. Может быть, они должны отказаться от этого и начать снова с UTF-8?
</speculation>
TLDR: многие PHP-библиотеки - это просто тонкий слой над нативными библиотеками C, которые не поддерживают юникод или не поддерживают его способами, несовместимыми друг с другом. Исправление этой ситуации может привести к обратным несовместимым изменениям.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: поскольку я перешел с PHP на Python (чтобы никогда не оглядываться назад) несколько лет назад, мое мнение явно предвзято.
Я думаю, что PHP хороший и умный взломать. Как хакерство, оно началось незатейливо и несколько хаотично выросло из множества редких библиотек - без продуманного и унифицированного дизайна (с точки зрения теории компьютерного языка).
По словам Макиавелли, «тот, кто сначала не заложил свои фундаменты, может быть способен с огромной способностью закладывать их впоследствии, но они будут заложены с трудностями для архитектора и опасностью для здания».
Для языка программирования, чем популярнее, тем сложнее измениться. Вот почему такие языки, как C, меняются раз в 10 лет. Например, Python 3 сделал много обратных несовместимых изменений, и это было не красиво. Поддержка юникода в предыдущих воплощениях Python уже считалась лучшей по сравнению с текущим состоянием дел в PHP, но угадайте, что: большинство полемических изменений в Python 3 связаны с обработкой юникода. Эта напыщенная речь от Armin Ronacher суммирует разочарование огромной части сообщества Python.
PHP, являющийся «вездесущей веб-платформой», делает его жертвой собственного успеха. Внедрение унифицированной поддержки юникода в PHP неизбежно, но потребует много крови, пота и слез.
Одной из основных причин, по которой старая работа над PHP 6 была остановлена, была внутренняя сложность, которую она принесла, и объем работы, которую почти никто не понимал.
Немного истории: реализация Unicode в PHP 6 была разработана с учетом потребностей более крупного пользователя PHP и пыталась сделать Unicode «правильным». После некоторой оценки основной разработчик поддержки PHP для поддержки Unicode решил добавить новый тип строки, который внутренне является Utf-16, и разрешить использование различных кодировок в разных местах. Таким образом, код может быть написан в одной кодировке, выходные данные могут использовать другую кодировку и «операции runtme» в другой кодировке. Причиной выбора UTF-16 было то, что работа должна быть основана на ICU livrary, которая использует UTF-16, и было обнаружено, что это кодирование позволяет быстро выполнять обычные строковые операции, в то время как разговоры между utf- и utf-16 относительно дешевы. , Все идет нормально.
Теперь следствием этого является, прежде всего, введение нового типа строки. Внутренняя система типов PHP до того времени имела несколько типов (NULL, bool, int / long, float / double, string, array, resource, object), и у большого количества кода были некоторые предположения на этот счет. Помимо таких допущений, все функции, работающие со строками, и их много, должны оцениваться индивидуально, и должно быть решено, как обрабатывать кодировки. Должны ли они работать с двоичными или юникодными строками? Если требуется преобразование, какую кодировку следует использовать и т. Д., И это большая работа, а в некоторых случаях довольно сложно сделать правильно. Кроме того, внутренние API стали довольно сложными, так как большинство ключевых API в PHP получили версии для двоичных строк (старые), а затем часто версии для строк, закодированных во время выполнения,
Из-за этого многие разработчики споткнулись о простоте, стали раздражаться из-за utf-16, и им не нравился тот факт, что это увеличило бы использование памяти более чем вдвое и потратило много времени на преобразование строк, ломая большинство существующих приложений. Итак, PHP, движимый добровольцами, все меньше и меньше разработчиков работали над ним, и другие вещи накапливались, и участники становились несчастными, и в конце концов от этого пришлось отказаться.
Что может принести будущее? - Происходит медленная эволюция, когда все больше и больше вещей в PHP строятся вокруг utf-8. Не слишком хорошо с пользовательским типом и форсированием всего, и в настоящее время разработчики не заинтересованы в том, чтобы трогать это горячее железо. Можно надеяться, что у кого-то есть хорошее предложение, чтобы оно работало хорошо, но в настоящее время «все» убегут, если только услышат слово. :)
Я предполагаю, что настоящая причина в том, что команде разработчиков PHP не хватает четкой дорожной карты для разработки PHP (давайте просто упомянем довольно горячую дискуссию, когда кто-то из php-internals решил запустить ветку PHP 5.4 без предварительного согласования того, какие функции 5.4 должны содержать). Мне очень нравится этот язык, но то, как он развивается, меня немного беспокоит.