Jeder weiß, dass PHP Probleme mit Unicode hat. Version 6 wird aufgrund von Unicode-Implementierungsschwierigkeiten effektiv aufgegeben. Aber ich frage mich, ob jemand die genauen Gründe kennt ? Architektur- / Designprobleme, Leistungsprobleme, Community-Probleme (ich wette nicht), etwas anderes?
Antworten:
PHP als Sprache kann es definitiv haben, aber ich denke, das Problem liegt in der Kompatibilität mit bestehenden Programmen. Die Unicode-Unterstützung kann sie auf subtile Weise zerstören, was die nervigste Art von Fehler ist.
Gegenwärtig sind die meisten Zeichenkettenverarbeitungsfunktionen in PHP "binärsicher", was bedeutet, dass Sie sie verwenden können, um jede Datei in einer beliebigen Codierung sowie Binärformate wie Bilddaten usw. zu verarbeiten.
Wenn Sie Unicode-Zeichenfolgen hinzufügen, müssen Sie sehr vorsichtig sein, um Unicode-Zeichenfolgen nicht mit Binärzeichenfolgen zu mischen (ziemlich schwierig, wenn Ihre Zeichenfolgen aus verschiedenen Quellen stammen und Sie sich vorher keine Sorgen machen mussten). Und Sie könnten Kodierungen nicht mehr ignorieren (und viele Skripte wissen das nicht!)
Ein weiteres hartes, aber lösbares Problem ist der wahlfreie Zugriff auf Unicode-Zeichenfolgen. Implementierung von $string[$offset]Änderungen von trivial zu sehr langsam oder wenig langsam und sehr komplex.
Ich denke auch, dass es ein Fehler war, UTF-16 als interne Kodierung für PHP zu wählen. Es hat die gleichen Probleme wie UTF-8 (variable Breite aufgrund von Ersatzpaaren) und die Ineffizienz von UCS-2. Vielleicht sollten sie das ausrangieren und wieder mit UTF-8 anfangen?
</speculation>
TLDR: Viele PHP-Bibliotheken sind nur eine dünne Schicht über nativen C-Bibliotheken, die Unicode nicht oder in nicht miteinander kompatibler Weise unterstützen. Die Behebung dieser Situation führt wahrscheinlich zu inkompatiblen Änderungen.
HAFTUNGSAUSSCHLUSS: Da ich vor ein paar Jahren von PHP auf Python umgestiegen bin (um nicht zurückzublicken), ist meine Meinung eindeutig voreingenommen.
Ich denke, PHP ist ein netter und kluger Hack. Als Hack begann es unprätentiös und wuchs etwas chaotisch aus einer Reihe von spärlichen Bibliotheken - ohne ein durchdachtes und einheitliches Design (aus der Perspektive der Computersprachtheorie).
Wie von Machiavelli gesagt, "wer seine Fundamente nicht zuerst gelegt hat, kann sie möglicherweise nachträglich sehr gut verlegen, aber sie werden für den Architekten mit Mühe und Gefahr für das Gebäude verlegt werden".
Je beliebter eine Programmiersprache ist, desto schwieriger ist es, sie zu ändern. Deshalb wechseln Sprachen wie C alle 10 Jahre. Zum Beispiel hat Python 3 viele inkompatible Änderungen vorgenommen, und es war nicht schön. Die Unicode-Unterstützung in früheren Python-Inkarnationen galt bereits als überlegen gegenüber dem aktuellen Stand der Dinge in PHP. Dieser Schimpanse von Armin Ronacher fasst die Frustration eines großen Teils der Python-Community zusammen.
PHP ist "die" allgegenwärtige Webplattform und wird Opfer ihres eigenen Erfolgs. Die einheitliche Unterstützung von Unicode in PHP ist unvermeidlich, erfordert aber viel Blut, Schweiß und Tränen.
Einer der Hauptgründe, warum die alte PHP 6-Arbeit gestoppt wurde, war die interne Komplexität und der Arbeitsaufwand, die kaum jemand vollständig verstanden hat.
Ein bisschen Geschichte: Die Unicode-Imlementierung von PHP 6 wurde von einem größeren PHP-Benutzer entwickelt und versuchte, Unicode "richtig" zu machen. Nach einiger Prüfung hat sich der Hauptentwickler der zu-sein-Unicode-Unterstützung von PHP entschieden, einen neuen Zeichenfolgentyp hinzuzufügen, der intern Utf-16 ist, und die Verwendung verschiedener Codierungen an verschiedenen Stellen zuzulassen. Der Code könnte also in einer Codierung geschrieben sein, die Ausgabe könnte eine andere Codierung verwenden und "runtme operations" eine andere Codierung. Der Grund für die Wahl von UTF-16 war, dass die Arbeit auf dem ICU-Archiv basieren sollte, das UTF-16 verwendet, und es wurde festgestellt, dass diese Codierung allgemeine Zeichenfolgenoperationen auf schnelle Weise ausführt, während die Konvertierung zwischen utf- und utf-16 relativ billig ist . So weit, ist es gut.
Die Konsequenz daraus ist nun vor allem die Einführung eines neuen String-Typs. Das interne Typsystem von PHP hatte bis dahin einige Typen (NULL, bool, int / long, float / double, Zeichenkette, Array, Ressource, Objekt) und viele Codes hatten einige Annahmen, dass dies der Fall ist. Abgesehen von solchen Annahmen müssen alle Funktionen, die mit Strings arbeiten, und es gibt viele davon, einzeln ausgewertet werden, und es muss entschieden werden, wie mit Codierungen umgegangen werden soll. Sollten sie mit binären Zeichenfolgen oder Unicode-Zeichenfolgen arbeiten? Wenn eine Konvertierung erforderlich ist, welche Codierung usw. verwendet werden soll, ist dies eine Menge Arbeit und in einigen Fällen ziemlich kompliziert, richtig zu machen. Zusätzlich wurden die internen APIs ziemlich kompliziert, da die meisten Schlüssel-APIs in PHP Versionen für binäre Zeichenfolgen (die alte) und dann oft eine Version für "Laufzeit-codierte" Zeichenfolgen erhielten.
Währenddessen stolperten viele Entwickler über die Komplexität, ärgerten sich über utf-16 und mochten nicht die Tatsache, dass dies die Speichernutzung mehr als verdoppeln und viel Zeit damit verbringen würde, Zeichenfolgen zu konvertieren, während die meisten vorhandenen Anwendungen beschädigt wurden. Da PHP von Freiwilligen betrieben wurde, arbeiteten immer weniger Entwickler daran und andere Dinge häuften sich, und die Mitwirkenden wurden unglücklich und mussten am Ende aufgegeben werden.
Was könnte nun die Zukunft bringen? - Es gibt eine langsame Entwicklung, in der immer mehr Dinge in PHP um utf-8 gebaut werden. Nicht in einer starken Weise mit einem kundenspezifischen Typ, der alles erzwingt, und derzeit sind die Entwickler nicht motiviert, dieses heiße Eisen anzufassen. Man kann hoffen, dass jemand einen guten Vorschlag hat, damit es gut funktioniert, aber derzeit wird "jeder" davonlaufen, wenn er nur das Wort hört. :)
Ich vermute, der eigentliche Grund ist, dass dem PHP-Entwicklerteam eine klare Roadmap für die PHP-Entwicklung fehlt. Ich mag diese Sprache sehr, aber die Art und Weise, wie sie entwickelt wird, macht mir ein bisschen Sorgen.