Почему именно PHP не может иметь полную поддержку юникода?

18

Всем известно, что у PHP проблемы с Unicode. Версия 6 фактически заброшена из-за трудностей реализации Unicode. Но мне интересно, кто-нибудь знает, каковы точные причины? Проблемы архитектуры / дизайна, проблемы производительности, проблемы сообщества (я держу пари, что нет), что-то другое?

TS01
источник

Ответы:

16

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

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

С добавлением строк Unicode вам нужно быть очень осторожным, чтобы не смешивать строки Unicode с двоичными строками (довольно сложно, когда ваши строки поступают из разных источников, и вам никогда не приходилось беспокоиться об этом раньше). И вы не можете больше не знать о кодировках (и многие сценарии не знают об этом!)

Еще одна сложная, но решаемая проблема - произвольный доступ в строках Unicode. Реализация $string[$offset]изменений от тривиального до очень медленного или немного медленного и очень сложного.

Также я думаю, что было ошибкой выбирать UTF-16 в качестве внутренней кодировки для PHP. У него те же проблемы, что и у UTF-8 (переменная ширина из-за суррогатных пар) и неэффективность UCS-2. Может быть, они должны отказаться от этого и начать снова с UTF-8?

</speculation>

Корнель
источник
2
полностью согласен с переходом на utf8.
GrandmasterB
Вы думаете, что UTF-16, кроме размера фрагмента данных, хуже, чем UTF-8?
ts01
3
@ Дин Хардинг: Я не говорю, что вообще невозможно работать с UTF-16, только то, что произвольный доступO (1) ) невозможен. UTF-16 не гарантирует, что 100-я кодовая точка будет начинаться с 200-го байта, поэтому для доступа к 100-й кодовой точке вы должны линейно сканировать все предыдущие (и хорошая реализация, конечно, кеширует результат). В этом отношении он похож на UTF-8 (то есть доступ к n-му символу / кодовой точке - это O (n) , а не O (1) ).
Корнел
1
@Dean: Такие вещи, как сопоставление или преобразования между UTF-16 и UTF-8, наверняка, не работают одинаково для суррогатов, как для объединения символов.
dan04
3
Отличное резюме о причинах выбора UTF-8 вместо UTF-16 (или любой другой кодировки) можно найти на utf8everywhere.org .
Йоахим Зауэр
11

TLDR: многие PHP-библиотеки - это просто тонкий слой над нативными библиотеками C, которые не поддерживают юникод или не поддерживают его способами, несовместимыми друг с другом. Исправление этой ситуации может привести к обратным несовместимым изменениям.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: поскольку я перешел с PHP на Python (чтобы никогда не оглядываться назад) несколько лет назад, мое мнение явно предвзято.

Я думаю, что PHP хороший и умный взломать. Как хакерство, оно началось незатейливо и несколько хаотично выросло из множества редких библиотек - без продуманного и унифицированного дизайна (с точки зрения теории компьютерного языка).

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

Для языка программирования, чем популярнее, тем сложнее измениться. Вот почему такие языки, как C, меняются раз в 10 лет. Например, Python 3 сделал много обратных несовместимых изменений, и это было не красиво. Поддержка юникода в предыдущих воплощениях Python уже считалась лучшей по сравнению с текущим состоянием дел в PHP, но угадайте, что: большинство полемических изменений в Python 3 связаны с обработкой юникода. Эта напыщенная речь от Armin Ronacher суммирует разочарование огромной части сообщества Python.

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

Пауло Скардин
источник
Ну, все согласны здесь, я полагаю. Но я спрашивал подробности;)
ts01
3
Проблема заключается в том, что многие базовые библиотеки плохо обрабатывают юникод, и очень трудно решить проблему, не начиная с нуля.
Пауло Скардин
(Кстати, «с тех пор несколько лет назад», PHP стал лучше, а Python хуже)
ZJR
1
@ZJE: Приятно знать, спасибо. Не могли бы вы указать мне некоторые справочные материалы об этом изменении?
Пауло Скардин
6

Одной из основных причин, по которой старая работа над 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. Не слишком хорошо с пользовательским типом и форсированием всего, и в настоящее время разработчики не заинтересованы в том, чтобы трогать это горячее железо. Можно надеяться, что у кого-то есть хорошее предложение, чтобы оно работало хорошо, но в настоящее время «все» убегут, если только услышат слово. :)

Johannes
источник
1

Я предполагаю, что настоящая причина в том, что команде разработчиков PHP не хватает четкой дорожной карты для разработки PHP (давайте просто упомянем довольно горячую дискуссию, когда кто-то из php-internals решил запустить ветку PHP 5.4 без предварительного согласования того, какие функции 5.4 должны содержать). Мне очень нравится этот язык, но то, как он развивается, меня немного беспокоит.

MCHL
источник
2
Я оставил PHP для Python в 2006 году, после того, как использовал его в течение 5 лет - у Python невероятный процесс разработки и хорошее лидерство - плюс язык намного более краткий, мощный и последовательный, чем PHP. Основная проблема заключается в том, чтобы найти правильную веб-среду. Мы прокатились самостоятельно - AppStruct.
gahooa
1
Ну, у нас была дорожная карта для PHP 6. Не помогло;) Одна из проблем дорожной карты заключается в том, что PHP движет добровольцами, которые появляются (и если у них есть «хорошие идеи», мы хотим сохранить их и добавить их функции в ближайшее время) и внезапно исчезают (выходят замуж, меняют работу, ...)
Иоганнес
К счастью, PHP 7 - это успех.
danger89
5 лет спустя и до сих пор без «полной поддержки юникода» :)
Mchl