Mọi người đều biết rằng PHP có vấn đề với Unicode. Phiên bản 6 bị bỏ rơi một cách hiệu quả, vì những khó khăn khi triển khai Unicode. Nhưng tôi tự hỏi nếu có ai biết lý do chính xác là gì? Vấn đề kiến trúc / thiết kế, mối quan tâm về hiệu suất, vấn đề cộng đồng (tôi cá là không), cái gì khác?
Câu trả lời:
PHP là một ngôn ngữ chắc chắn có thể có nó, nhưng tôi nghĩ vấn đề là do khả năng tương thích với các chương trình hiện có. Hỗ trợ Unicode có thể phá vỡ chúng theo những cách tinh tế, đây là loại lỗi khó chịu nhất.
Hiện tại hầu hết các hàm xử lý chuỗi trong PHP là "an toàn nhị phân", có nghĩa là bạn có thể sử dụng chúng để xử lý bất kỳ tệp nào trong bất kỳ mã hóa cũng như các định dạng nhị phân như dữ liệu hình ảnh, v.v.
Ngoài việc thêm các chuỗi Unicode, bạn phải hết sức cẩn thận để không trộn các chuỗi Unicode với các chuỗi nhị phân (khá khó khăn khi các chuỗi của bạn đến từ các nguồn khác nhau và bạn không bao giờ phải lo lắng về điều đó trước đây). Và bạn không thể không biết gì về mã hóa nữa (và rất nhiều kịch bản không biết gì về điều này!)
Một vấn đề khó, nhưng có thể giải quyết khác là truy cập ngẫu nhiên trong các chuỗi Unicode. Thực hiện các $string[$offset]thay đổi từ tầm thường sang rất chậm hoặc hơi chậm và rất phức tạp.
Ngoài ra tôi nghĩ thật sai lầm khi chọn UTF-16 làm mã hóa nội bộ cho PHP. Nó có cùng các vấn đề như UTF-8 (chiều rộng thay đổi do các cặp thay thế) và không hiệu quả của UCS-2. Có lẽ họ nên loại bỏ điều đó và bắt đầu lại với UTF-8?
</speculation>
TLDR: nhiều thư viện PHP chỉ là một lớp mỏng so với các thư viện C gốc không hỗ trợ unicode hoặc hỗ trợ nó theo những cách không tương thích với nhau. Khắc phục tình trạng này có khả năng đưa ra những thay đổi không tương thích ngược.
TUYÊN BỐ TỪ CHỐI: khi tôi đã chuyển từ PHP sang Python (để không bao giờ nhìn lại) vài năm trước, ý kiến của tôi rõ ràng là sai lệch.
Tôi nghĩ rằng PHP là một hack tốt đẹp và thông minh. Là một hack, nó bắt đầu không khoa học và phát triển một cách hỗn loạn từ một loạt các thư viện thưa thớt - thiếu một thiết kế hợp lý và suy nghĩ tốt (từ quan điểm lý thuyết ngôn ngữ máy tính).
Như Machiavelli đã nói, "người đầu tiên không đặt nền móng có thể có khả năng lớn để đặt chúng sau đó, nhưng chúng sẽ gây rắc rối cho kiến trúc sư và nguy hiểm cho tòa nhà".
Đối với một ngôn ngữ lập trình, càng phổ biến, càng khó thay đổi. Đó là lý do tại sao các ngôn ngữ như C thay đổi cứ sau 10 năm. Ví dụ, Python 3 thực hiện nhiều thay đổi không tương thích ngược và nó không đẹp. Hỗ trợ unicode trong các phiên bản Python trước đây đã được coi là vượt trội so với trạng thái hiện tại trong PHP, nhưng hãy đoán xem: những thay đổi chính xác nhất trong Python 3 có liên quan đến việc xử lý unicode. Câu nói hay này của Armin Ronacher tóm tắt sự thất vọng từ một phần lớn cộng đồng Python.
PHP là "nền tảng web phổ biến khiến nó trở thành nạn nhân của sự thành công của chính nó. Mang lại sự hỗ trợ thống nhất cho unicode trong PHP là không thể tránh khỏi, nhưng sẽ đòi hỏi rất nhiều máu, mồ hôi và nước mắt.
Một trong những lý do chính khiến công việc PHP 6 cũ bị dừng lại là do sự phức tạp bên trong mà nó mang lại và khối lượng công việc phải làm, điều mà hầu như không ai hiểu rõ.
Một chút về lịch sử: Việc cải tiến Unicode của PHP 6 được thiết kế bởi nhu cầu của người dùng PHP lớn hơn và đã cố gắng thực hiện Unicode "đúng". Sau một số đánh giá, người thiết kế chính cho hỗ trợ Unicode của PHP đã chọn để thêm một loại chuỗi mới mà bên trong là Utf-16 và để cho phép các mã hóa khác nhau được sử dụng ở những nơi khác nhau. Vì vậy, mã có thể được viết bằng một mã hóa, đầu ra có thể sử dụng một mã hóa khác và "hoạt động runtme" một số mã hóa khác. Lý do chọn UTF-16 là vì công việc nên dựa trên bản phát hành ICU sử dụng UTF-16 và người ta thấy rằng mã hóa này thực hiện các hoạt động chuỗi phổ biến một cách nhanh chóng trong khi chuyển đổi giữa utf- và utf-16 tương đối rẻ . Càng xa càng tốt.
Bây giờ, hậu quả của việc này là trước hết là sự ra đời của một loại chuỗi mới. Hệ thống kiểu nội bộ của PHP cho đến lúc đó có một vài loại (NULL, bool, int / long, float / double, chuỗi, mảng, resource, object) và rất nhiều mã có một số giả định về trường hợp này. Bên cạnh các giả định như vậy, tất cả các hàm hoạt động trên chuỗi, và có rất nhiều hàm đó, phải được đánh giá riêng lẻ và nó phải được quyết định cách xử lý mã hóa. Họ nên làm việc trên chuỗi nhị phân hoặc chuỗi unicode? Nếu một chuyển đổi là bắt buộc thì nên sử dụng mã hóa, v.v. và đây là công việc rất nhiều và trong một số trường hợp khá phức tạp để thực hiện đúng. Ngoài ra, các API nội bộ trở nên khá phức tạp, vì hầu hết các API chính trong PHP đều có phiên bản cho chuỗi nhị phân (cũ) và sau đó thường là phiên bản cho chuỗi "được mã hóa thời gian chạy",
Trong quá trình thực hiện, nhiều nhà phát triển đã vấp phải sự đồng bộ, trở nên khó chịu bởi utf-16 và không thích thực tế rằng điều này sẽ tăng gấp đôi mức sử dụng bộ nhớ và mất nhiều thời gian để chuyển đổi chuỗi trong khi phá vỡ hầu hết các ứng dụng hiện có. Vì vậy, PHP được điều khiển bởi các tình nguyện viên, ngày càng ít nhà phát triển đang làm việc với nó và những thứ khác chồng chất và những người đóng góp trở nên không vui và cuối cùng nó đã phải từ bỏ.
Bây giờ những gì tương lai có thể mang lại? - Có một sự tiến hóa chậm xảy ra rằng ngày càng có nhiều thứ trong PHP ae được xây dựng xung quanh utf-8. Không phải là một cách mạnh mẽ với một loại tùy chỉnh và buộc tất cả mọi thứ và hiện tại các nhà phát triển không có động lực để chạm vào bàn ủi nóng này. Người ta có thể hy vọng rằng ai đó có một đề xuất tốt để làm cho nó hoạt động tốt, nhưng hiện tại "mọi người" sẽ bỏ chạy nếu họ chỉ nghe thấy từ đó. :)
Tôi đoán lý do thực tế là nhóm phát triển PHP thiếu một lộ trình rõ ràng để phát triển PHP (chúng ta chỉ đề cập đến một cuộc thảo luận khá sôi nổi khi ai đó trên chương trình php quyết định bắt đầu chi nhánh PHP 5.4 mà không đồng ý trước về những tính năng 5.4 nên có). Tôi rất thích ngôn ngữ này, nhưng cách nó được phát triển khiến tôi hơi lo lắng.