PHP完全にUnicodeをサポートできないのはなぜですか？
PHPはUnicodeに問題があります。Unicodeの実装が困難なため、バージョン6は事実上破棄されています。しかしexactの理由を誰かが知っているのではないでしょうか？アーキテクチャ/設計の問題、パフォーマンスの問題、コミュニティの問題（そうではない）、他に何かありますか？
言語としてのPHPは間違いなくそれを持つことができますが、問題は既存のプログラムとの互換性にあると思います。 Unicodeサポートはそれらを微妙な方法で壊す可能性があり、これは最も厄介な種類のバグです。
現在、PHPのほとんどの文字列処理関数は「バイナリセーフ」です。つまり、それらを使用して、任意のエンコーディングのファイルや、画像データなどのバイナリ形式を処理できます。
Unicode文字列を追加すると、Unicode文字列とバイナリ文字列を混在させないように非常に注意する必要があります（文字列がさまざまなソースからのものであり、以前に心配する必要がなかった場合はかなり困難です）。そして、あなたはもうエンコーディングについて無知であるはずがありません（そして多くのスクリプトはこれについて無知です！）
別の難しいが解決可能な問題は、Unicode文字列でのランダムアクセスです。 $string[$offset]の実装は、些細なものから非常に遅いまたは少し遅い、非常に複雑なものに変更されます。
また、PHPの内部エンコーディングとしてUTF-16を選択するのは間違いだったと思います。 UTF-8（サロゲートペアによる可変幅）と同じ問題と、UCS-2の非効率性があります。多分彼らはそれを廃棄してUTF-8でやり直すべきですか？
</speculation>
TLDR：多くのPHPライブラリは、Unicodeをサポートしていない、または相互に互換性のない方法でサポートしているネイティブCライブラリの単なる薄層です。この状況を修正すると、後方に導入される可能性があります。互換性のない変更。
免責事項：私が数年前にPHP= Python（振り返ることはありません））に切り替えたので、私の意見は明らかに偏っています。
PHPはナイスで賢いハックです。ハッキングとして、それは気取らずに、まばらなライブラリの束からいくらか無秩序に成長しました。視点）。
マキャヴェリが言ったように、「最初に基礎を築かなかった人は、後で基礎を築く優れた能力を備えているかもしれませんが、建築家にとっては困難であり、建物にとって危険です。」.
プログラミング言語の場合、人気が高いほど、変更が難しくなります。そのため、Cなどの言語は10年に1回変更されます。たとえば、Python 3は、多くの下位互換性のない変更を行い、それはきれいではありませんでした。以前のPythonインカネーションでのUnicodeサポートは、現在の状態よりも優れていると見なされていました。 PHPの問題の数、しかし何を推測する：Python 3の最も論争の多い変更は、Unicodeの処理に関連しています。 This rant from Armin Ronacher Pythonコミュニティの巨大なシェアからの欲求不満を要約します。
PHPは「ユビキタス」なWebプラットフォームであるため、PHPは自身の成功の犠牲になっています。 PHPでユニコードのサポートを統一することは避けられませんが、大量の血、汗、涙を必要とします。
古いPHP 6の作業が中止された主な理由の1つは、それがもたらした内部の複雑さと実行する作業の量によるものでしたが、ほとんど誰も完全に理解していませんでした。
少し歴史：PHP 6のUnicode実装は、より大きなPHPユーザーの必要性によって設計され、Unicodeを「正しく」実行しようとしました。いくつかの評価の後、 PHPのユニコードサポートの主な設計者は、内部的にUtf-16である新しい文字列型を追加し、異なる場所で異なるエンコーディングを使用できるようにしました。そのため、コードは1つのエンコーディングで記述され、出力は別のエンコーディングと「runtmeオペレーション」を使用して他のエンコーディングを作成します。UTF-16を選択した理由は、UTF-16を使用するICU livraryに基づいて作業を行う必要があるためであり、このエンコーディングは、utf-とutf-16の間の会話が比較的安価である一方で、一般的な文字列操作を高速に行います。
これを実行した結果、何よりも新しい文字列型が導入されました。それまでのPHPの内部型システムにはいくつかの型（NULL、ブール、整数/長整数、浮動小数点/倍精度、文字列、配列、リソース、オブジェクト）があり、多くのコードはこれが当てはまることを前提としていました。そのような仮定に加えて、文字列で動作するすべての関数、およびそれらの多くは個別に評価する必要があり、エンコーディングの処理方法を決定する必要があります。彼らはバイナリ文字列またはユニコード文字列で動作する必要がありますか？どのエンコーディングを使用する必要があるかなどの変換が必要な場合、これは多くの作業であり、場合によっては正しく行うのが非常に複雑です。さらに、内部APIはかなり複雑になりました。PHPのほとんどの主要なAPIがバイナリ文字列（古いもの）のバージョンを取得し、多くの場合、「ランタイムエンコード」文字列のバージョン、およびutf- 16の文字列、そこにはかなりの混乱が生じます...
その過程で、多くの開発者は複雑さに出くわし、utf-16に悩まされ、メモリ使用量が2倍以上になり、既存のほとんどのアプリケーションを壊しながら文字列の変換に多くの時間を費やすという事実を嫌いました。したがって、PHPボランティアによって推進されているため、それに取り組んでいる開発者が少なくなり、他のものが山積みになり、貢献者が不満になり、結局それを放棄する必要がありました。
今、未来は何をもたらすでしょうか？ -PHP aeはutf-8を中心に構築されています。カスタムタイプでは強力ではなく、すべてを強制しますが、現在開発者はやる気がありません。この熱いアイアンに触れてください。誰かがそれをうまく機能させるための良い提案を持っていることを期待できますが、現在「みんな」は言葉だけを聞いたら逃げるでしょう。
実際の理由は、PHP開発チームがPHP開発の明確なロードマップを欠いていることです（php-internals PHP 5.4ブランチは、5.4にどの機能が含まれるべきかについて事前に同意することなく分岐することを決定しました。）私はこの言語がとても好きですが、その開発方法が少し心配になります。