¿Qué factores hacen que PHP Unicode sea incompatible?

Creo que es en gran medida una dificultad cultural, no técnica.

En cuanto a los problemas técnicos---y no es francamente trivial implementar unicode en un ecosistema construido sobre las suposiciones de que 'un carácter es igual a un byte'---los desarrolladores podrían haber copiado gran parte de los esfuerzos de java o python (este último con una compatibilidad decente y en gran medida de trabajo unicode desde alrededor de 2001), pero nunca lo hicieron.

Cuando leo el hilo de discusión adjunto a la documentación oficial, actual para la función utf8_encode() de php, tengo una sensación de vértigo.

En primer lugar, esa función se llama utf8_encode(); sin embargo, la documentación indica que se espera que la cadena que espera esté en ISO-8859-1 (también conocido como latín-1). eso es tan php, tan 80.

La mayoría de los comentaristas parecen percibir unicode como una carga. hay muchas propuestas de cómo convertir cadenas 'de contenido desconocido', cómo tratar con s'strings con codificaciones mixtas '(wtf?), o tratar con puntos de código que normalmente causan rotura porque están más allá del límite de cuatro bytes por punto de código de esa función.

La discusión se centra en las correcciones para deshacerse de garabatos o para evitar las partes problemáticas del comportamiento de esa función. y eso, para mí, es tan php: todo el mundo está haciendo correcciones, pocas cosas se implementan de una manera fundamentalmente correcta. si usted cree que esto es una calumnia de mi parte, aquí hay algunas cositas:

Aunque esto parece romper el alemán Umlaute [äöü] si el documento ya es UTF-8.

(falta de comprensión de que utf-8 no está diseñado para funcionar cuando se aplica dos veces)

Mira la función iconv (), que ofrece una forma de convertir de 8859 y dreaded 1252 a UTF8

(buen punto: negligencia del estado de la técnica por parte de los desarrolladores de php; en su lugar, implementación propia con errores)

Uso de preg_match para detectar si se necesita utf8_encode [...] excluidas las madres sustitutas [...] excluir overlongs

(sugiriendo borrar silenciosamente todo el contenido problemático de las cadenas, dejando solo aquellas cosas que no se rompen utf8_encode(); esto puede hacer que los textos sean ilegibles (o desaparezcan por completo), pero bueno, no más mensajes de error)

Codificar una cadena solo si todavía no es UTF-8 [...] mb_detect_encoding($s, "UTF-8")

(como señaló otro comentarista , esto no va a funcionar:

$str = 'áéóú'; // ISO-8859-1
mb_detect_encoding($str, 'UTF-8'); // 'UTF-8'
mb_detect_encoding($str, 'UTF-8', true); // false

Así que aquí estamos viendo un error siendo reemplazado por otro. feliz caza. además, lo que parecen proponer aquí es resolver un problema utilizando medios heurísticos (lentos, inciertos) que podrían y deberían resolverse con medios mecánicos (rápidos, ciertos)

Utf8_ [encode / decode] también traducirá caracteres de windows-1252, no solo de / a ISO-8859-1 como dice la documentación

(nunca puede confiar en la documentación oficial de php para ser clara o exhaustiva - - - siempre debe leer a través de años de experiencia de los usuarios que nadie responderá a los documentos)

He estado trabajando en una función is_utf8 y quería publicarla aquí, además de otras también tomé en consideración el error de 5000 char

(una solución para un problema que en gran parte solo existe porque unicode no está implementado correctamente. también aprendemos que la función utf8_encode() no solo renunciará a más de 4 bytes por punto de código, sino que también se romperá si el resultado (o la salida?) el texto excede un límite de 5000 caracteres)

I podría seguir así. ya tienes la idea: a juzgar por este hilo, la comunidad php simplemente no suena como si estuvieran en cualquier lugar listos para comprender de qué se tratan las codificaciones y los conjuntos de caracteres, lo que se necesita para construir una infraestructura de sonido en general o, específicamente, para implementar unicode de una manera adecuada. en su lugar, están usando sus andamios, sus cartones, sus clavos y martillos y siguen construyendo este gran edificio llamado php, lanzando su cinta adhesiva a cada problema eso no se puede deshacer con otro clavo. por supuesto, ese edificio sufrirá de cada viento que venga soplando, como el carácter legal pero inesperado ocasional.

Ver este hilo en particular activo durante ocho años no infunde exactamente confianza en que la situación va a ser mejor en ocho años a partir de ahora.

El concepto de un "carácter multibyte" está en el centro del problema.

1. Filtra un detalle de implementación: debería ser capaz de trabajar con la abstracción de un carácter sin saber cómo los implementadores eligen representar los datos - tal vez dependiendo de la plataforma les convenga representar todo como UTF16 o UTF32, en cuyo caso todo es multibyte, no es que a los usuarios de la abstracción de caracteres les importe.
2. Es un kludge: Encima de un anticuado hábito de pensamiento donde todos "realmente sabemos" que las cadenas son secuencias de bytes, ahora tenemos que saber que a veces los bytes se agrupan en cosas conocidas como caracteres Unicode, y tienen casos especiales por todas partes para lidiar con ello.
3. Es como un ratón tratando de comer un elefante. Al enmarcar Unicode como una extensión de ASCII (tenemos cadenas normales y tenemos mb_strings), hace las cosas mal, y se cuelga en qué casos especiales se requieren para tratar con los caracteres con garabatos divertidos que necesitan más de un byte. Si considera que Unicode proporciona un espacio abstracto para cualquier carácter que necesite, ASCII se acomoda en eso sin necesidad de tratarlo como un caso especial.

Usted mismo lo dice: para tratar correctamente con cadenas que contienen caracteres multibyte, necesita usar una extensión. Olvídese de cualquier lugar para usar las funciones de extensión en lugar de las más familiares "normales", y sus datos se mutilan. Lo mismo sucede si utiliza una biblioteca de terceros que no se ha actualizado para usar la función de extensión en todas partes.

Además, un número de codificaciones extremadamente populares todavía están explícitamente no soportadas por PHP, probablemente porque es imposible hacerlo y permanecer hacia abajo compatible.

Muchas de las extensiones comunes no tienen soporte unicode o (peor aún) "necesita saber" que una cadena contiene secuencias unicode/utf-8, como por ejemplo XmlReader. Y puede hacer una gran diferencia si glob() de PHP llama a FindFirstFileA o FindFirstFileW en win32.
Otro problema (mucho más pequeño pero sorprendentemente a menudo es la fuente de molestia) son las BOM que PHP no reconoce.

Muchas de las funciones de cadena son solo envoltorios delgados alrededor de los equivalentes de la biblioteca de C, que también tratan todo como una secuencia de bytes. Otra razón es que PHP lleva consigo una gran cantidad de equipaje innecesario de compatibilidad con versiones anteriores y, por lo tanto, se queda atascado con malas decisiones de diseño de 3 y 4.

Tal vez con los espacios de nombres de la versión 5.3 finalmente tengan una forma de eliminar gradualmente las funciones antiguas.

Lo que se entiende por 'soporte' es 'soporte nativo'. Echa un vistazo a this para obtener información detallada.