Todo el mundo sabe que PHP tiene problemas con Unicode. La versión 6 se abandona efectivamente debido a las dificultades de implementación de Unicode. Pero me pregunto si alguien sabe cuáles son las razones exactas . ¿Problemas de arquitectura / diseño, problemas de rendimiento, problemas de la comunidad (apuesto a que no), algo más?
Respuestas:
PHP como lenguaje definitivamente puede tenerlo, pero creo que el problema es con la compatibilidad con los programas existentes. El soporte Unicode puede romperlos de manera sutil, que es el tipo de error más molesto que puede tener.
Actualmente, la mayoría de las funciones de procesamiento de cadenas en PHP son "seguras para binarios", lo que significa que puede usarlas para procesar cualquier archivo en cualquier codificación, así como en formatos binarios como datos de imágenes, etc.
Con la adición de cadenas Unicode, debe tener mucho cuidado de no mezclar cadenas Unicode con cadenas binarias (bastante difícil cuando sus cadenas provienen de diferentes fuentes y nunca tuvo que preocuparse por eso antes). Y ya no podría ignorar las codificaciones (¡y muchos scripts ignoran esto!)
Otro problema difícil pero solucionable es el acceso aleatorio en cadenas Unicode. Implementación de $string[$offset]cambios de triviales a muy lentos o poco lentos y muy complejos.
También creo que fue un error elegir UTF-16 como codificación interna para PHP. Tiene los mismos problemas que UTF-8 (ancho variable debido a pares sustitutos) e ineficiencia de UCS-2. ¿Quizás deberían desechar eso y comenzar de nuevo con UTF-8?
</speculation>
TLDR: muchas bibliotecas PHP son solo una capa delgada sobre las bibliotecas nativas de C que no son compatibles con Unicode, o lo son de manera incompatible entre sí. Es probable que rectificar esta situación introduzca cambios incompatibles con versiones anteriores.
DESCARGO DE RESPONSABILIDAD: hace unos años, cuando cambié de PHP a Python (para nunca mirar atrás), mi opinión está claramente sesgada.
Creo que PHP es un truco agradable e inteligente. Como truco, comenzó sin pretensiones y creció de manera caótica de un montón de bibliotecas dispersas, que carecían de un diseño bien pensado y unificado (desde la perspectiva de la teoría del lenguaje informático).
Como dijo Maquiavelo, "el que no ha sentado sus cimientos primero puede ser capaz de sentarlos después, pero será un problema para el arquitecto y un peligro para el edificio".
Para un lenguaje de programación, cuanto más popular, más difícil de cambiar. Es por eso que los lenguajes como C cambian una vez cada 10 años. Por ejemplo, Python 3 realizó muchos cambios incompatibles con versiones anteriores, y no fue bonito. El soporte de Unicode en encarnaciones anteriores de Python ya se consideraba superior al estado actual de las cosas en PHP, pero adivina qué: los cambios más polémicos en Python 3 están relacionados con el manejo de Unicode. Este discurso de Armin Ronacher resume la frustración de una gran parte de la comunidad de Python.
Siendo PHP "la" plataforma web ubicua, es víctima de su propio éxito. Brindar soporte unificado para Unicode en PHP es inevitable, pero requerirá mucha sangre, sudor y lágrimas.
Una de las razones principales por las que se detuvo el antiguo trabajo de PHP 6 se debió a la complejidad interna que traía y la cantidad de trabajo que hacer, que casi nadie entendió por completo.
Un poco de historia: la implementación de Unicode de PHP 6 fue diseñada por la necesidad de un usuario PHP más grande y trató de hacer Unicode "correctamente". Después de alguna evaluación, el diseñador principal del soporte to-be-Unicode-PHP ha elegido agregar un nuevo tipo de cadena que internamente es Utf-16 y permitir que se usen diferentes codificaciones en diferentes lugares. Entonces, el código podría escribirse en una codificación, la salida podría usar una codificación diferente y "operaciones de ejecución" alguna otra codificación. La razón para elegir UTF-16 fue que el trabajo debería basarse en la biblioteca de la UCI que usa UTF-16 y se descubrió que esta codificación hace que las operaciones de cadena comunes sean rápidas mientras que la conversación entre utf- y utf-16 es relativamente barata . Hasta aquí todo bien.
Ahora la consecuencia de hacer esto es ante todo la introducción de un nuevo tipo de cadena. El sistema de tipos interno de PHP hasta entonces tenía algunos tipos (NULL, bool, int / long, float / double, string, array, resource, object) y muchos códigos tenían algunas suposiciones sobre este caso. Además de tales supuestos, todas las funciones que operan en cadenas, y hay muchas de ellas, deben evaluarse individualmente y debe decidirse cómo manejar las codificaciones. ¿Deberían funcionar en cadenas binarias o cadenas unicode? Si se requiere una conversión, qué codificación se debe usar, etc., y esto es mucho trabajo y, en algunos casos, bastante complicado de hacer bien. Además, las API internas se volvieron bastante complicadas, ya que la mayoría de las API clave en PHP obtuvieron versiones para cadenas binarias (la antigua) y luego a menudo una versión para cadenas "codificadas en tiempo de ejecución",
Durante el proceso, muchos desarrolladores tropezaron con la complejidad, se molestaron con utf-16 y no les gustó el hecho de que esto duplicaría el uso de la memoria y pasaría mucho tiempo convirtiendo cadenas y rompiendo la mayoría de las aplicaciones existentes. Entonces, al ser PHP impulsado por voluntarios, cada vez menos desarrolladores trabajaban en él y otras cosas se acumulaban y los contribuyentes se volvieron infelices y al final tuvo que ser abandonado.
¿Qué nos depara el futuro? - Está ocurriendo una evolución lenta que cada vez más cosas en PHP se construyen alrededor de utf-8. No de una manera fuerte con un tipo personalizado y forzando todo y actualmente los desarrolladores no están motivados para tocar este hierro caliente. Uno puede esperar que alguien tenga una buena propuesta para que funcione bien, pero actualmente "todos" huirán si solo escuchan la palabra. :)
Supongo que la razón real es que el equipo de desarrollo de PHP carece de una hoja de ruta clara para el desarrollo de PHP (solo mencionemos una discusión bastante acalorada cuando alguien en php-internals decidió iniciar la rama PHP 5.4 sin acordar previamente qué características 5.4 debería contener). Me gusta mucho este lenguaje, pero la forma en que se está desarrollando me preocupa un poco.