เหตุใด PHP จึงไม่สามารถรองรับ Unicode ได้อย่างสมบูรณ์

ทุกคนรู้ว่า PHP มีปัญหากับ Unicode เวอร์ชัน 6 ถูกยกเลิกอย่างมีประสิทธิภาพเนื่องจากความยุ่งยากในการใช้ Unicode แต่ฉันสงสัยว่าใครรู้เหตุผลที่แน่นอนคืออะไร? ปัญหาด้านสถาปัตยกรรม / การออกแบบความกังวลเรื่องประสิทธิภาพปัญหาชุมชน (ฉันไม่เดิมพัน) มีอะไรอื่นอีกหรือ

PHP เป็นภาษาที่แน่นอนสามารถมีได้ แต่ฉันคิดว่าปัญหาคือความเข้ากันได้กับโปรแกรมที่มีอยู่ การสนับสนุน Unicode สามารถทำลายพวกมันในรูปแบบที่ลึกซึ้งซึ่งเป็นข้อบกพร่องที่น่ารำคาญที่สุด

ปัจจุบันฟังก์ชั่นการประมวลผลสตริงส่วนใหญ่ใน PHP นั้นเป็น "binary-safe" ซึ่งหมายความว่าคุณสามารถใช้มันเพื่อประมวลผลไฟล์ใด ๆ ในการเข้ารหัสใด ๆ เช่นเดียวกับรูปแบบไบนารีเช่นข้อมูลภาพ ฯลฯ

ด้วยการเพิ่มสายอักขระ Unicode คุณต้องระวังไม่ให้รวมสาย Unicode กับสายอักขระไบนารี (ค่อนข้างยากเมื่อสายของคุณมาจากแหล่งที่แตกต่างกันและคุณไม่ต้องกังวลเกี่ยวกับมันมาก่อน) และคุณไม่สามารถเพิกเฉยต่อการเข้ารหัสอีกต่อไป (และสคริปต์จำนวนมากไม่รู้เรื่องนี้!)

ปัญหาอื่นที่ยาก แต่แก้ไขได้คือการเข้าถึงแบบสุ่มในสายอักขระ Unicode การนำการ$string[$offset]เปลี่ยนแปลงมาใช้ตั้งแต่เล็กน้อยไปจนถึงช้าหรือช้าและซับซ้อนมาก

นอกจากนี้ฉันคิดว่ามันเป็นความผิดพลาดในการเลือก UTF-16 เป็นการเข้ารหัสภายในสำหรับ PHP มันมีปัญหาเช่นเดียวกับ UTF-8 (ความกว้างของตัวแปรเนื่องจากคู่ของตัวแทน) และความไม่มีประสิทธิภาพของ UCS-2 บางทีพวกเขาควรจะทิ้งเรื่องนั้นและเริ่มใหม่อีกครั้งกับ UTF-8

</speculation>

TLDR: ไลบรารี PHP จำนวนมากเป็นเพียงเลเยอร์บาง ๆ เหนือไลบรารี C ดั้งเดิมที่ไม่สนับสนุน unicode หรือสนับสนุนในวิธีที่เข้ากันไม่ได้ การแก้ไขสถานการณ์นี้มีแนวโน้มที่จะนำการเปลี่ยนแปลงที่เข้ากันไม่ได้ย้อนหลัง

การปฏิเสธความรับผิด: เนื่องจากฉันเปลี่ยนจาก PHP เป็น Python (ไม่เคยมองย้อนกลับไป) เมื่อไม่กี่ปีที่ผ่านมาความเห็นของฉันมีอคติอย่างชัดเจน

ฉันคิดว่า PHP เป็นแฮ็คที่ดีและฉลาด ในฐานะที่เป็นแฮ็คมันเริ่มไม่โอ้อวดและเติบโตขึ้นค่อนข้างวุ่นวายจากห้องสมุดที่กระจัดกระจาย - ขาดการออกแบบที่ดีและเป็นหนึ่งเดียว (จากมุมมองของทฤษฎีภาษาคอมพิวเตอร์)

ตามที่กล่าวโดย Machiavelli "ผู้ที่ไม่ได้วางรากฐานของเขาก่อนอาจมีความสามารถที่ดีในการวางพวกเขาในภายหลัง แต่พวกเขาจะถูกวางด้วยปัญหากับสถาปนิกและอันตรายต่ออาคาร"

สำหรับภาษาการเขียนโปรแกรมยิ่งได้รับความนิยมและยากที่จะเปลี่ยนแปลง นั่นคือเหตุผลที่ภาษาอย่าง C เปลี่ยนทุกๆ 10 ปี ตัวอย่างเช่น Python 3 ทำการเปลี่ยนแปลงด้านหลังกันไม่ได้หลายครั้งและมันก็ไม่ได้สวย การสนับสนุนยูนิโค้ดในสาขางูใหญ่ก่อนหน้านี้ได้รับการพิจารณาแล้วว่าเหนือกว่าสถานะปัจจุบันของกิจการใน PHP แต่คาดเดาสิ่งที่: การเปลี่ยนแปลงโต้เถียงมากที่สุดในงูหลาม 3 เกี่ยวข้องกับการจัดการยูนิโค้ด พูดจาโผงผางจากArmin Ronacherสรุปความคับข้องใจจากชุมชน Python

PHP เป็น "แพลตฟอร์มเว็บ" ที่แพร่หลายทำให้ตกเป็นเหยื่อของความสำเร็จของตนเอง นำการสนับสนุน unicode ใน PHP มาใช้เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่จะต้องใช้เลือดเหงื่อและน้ำตาเป็นจำนวนมาก

หนึ่งในสาเหตุหลักที่การทำงานของ PHP 6 เก่าหยุดลงเนื่องจากความซับซ้อนภายในที่นำมาและปริมาณงานที่ต้องทำซึ่งแทบไม่มีใครเข้าใจเลย

ประวัติเล็กน้อย: การเติม Unicode ของ PHP 6 ได้รับการออกแบบโดยความต้องการของผู้ใช้ PHP ที่มีขนาดใหญ่ขึ้นและพยายามทำ Unicode "ถูกต้อง" หลังจากการประเมินผลผู้ออกแบบหลักของการสนับสนุนของ to-be-Unicode ของ PHP ได้เลือกที่จะเพิ่มประเภทสตริงใหม่ซึ่งภายใน Utf-16 และอนุญาตให้ใช้การเข้ารหัสที่แตกต่างกันในที่ต่าง ๆ ดังนั้นรหัสอาจถูกเขียนในการเข้ารหัสหนึ่งเอาท์พุทอาจใช้การเข้ารหัสที่แตกต่างกันและ "การดำเนินการ runtme" การเข้ารหัสอื่น ๆ เหตุผลในการเลือก UTF-16 คือการทำงานควรอยู่บนพื้นฐานของ ICU อย่างอิสระซึ่งใช้ UTF-16 และพบว่าการเข้ารหัสนี้ทำให้การทำงานของสตริงทั่วไปในวิธีที่รวดเร็วในขณะที่การแปลงระหว่าง utf- และ utf-16 ค่อนข้างถูก . จนถึงตอนนี้ดีมาก

ตอนนี้ผลที่ตามมาของการทำเช่นนี้คือการแนะนำประเภทสตริงใหม่ ระบบประเภทภายในของ PHP นั้นมีหลายประเภท (NULL, bool, int / long, float / double, สตริง, อาร์เรย์, ทรัพยากร, วัตถุ) และโค้ดจำนวนมากมีข้อสันนิษฐานบางประการ นอกจากสมมติฐานดังกล่าวฟังก์ชั่นทั้งหมดที่ทำงานบนสตริงและมีจำนวนมากที่จะต้องมีการประเมินเป็นรายบุคคลและจะต้องมีการตัดสินใจวิธีการจัดการการเข้ารหัส พวกเขาควรทำงานกับสตริงไบนารีหรือสตริง Unicode? หากจำเป็นต้องมีการแปลงซึ่งควรใช้การเข้ารหัส ฯลฯ และนี่เป็นงานจำนวนมากและในบางกรณีค่อนข้างซับซ้อนที่จะทำถูกต้อง นอกจากนี้ API ภายในก็ค่อนข้างซับซ้อนเนื่องจาก API ที่สำคัญที่สุดใน PHP มีเวอร์ชั่นสำหรับสตริงไบนารี่ (อันเก่า) และมักจะเป็นเวอร์ชั่นสำหรับสตริง "เข้ารหัสไทรันไทม์"

ในกระบวนการของการทำสิ่งที่ผู้พัฒนาหลายคนสะดุดกับ coplexity ทำให้รำคาญด้วย utf-16 และไม่ชอบความจริงที่ว่านี่จะมากกว่าการใช้หน่วยความจำสองเท่าและใช้เวลามากในการแปลงสตริงในขณะที่ทำลายแอพพลิเคชันที่มีอยู่ส่วนใหญ่ ดังนั้น PHP ถูกขับเคลื่อนโดยอาสาสมัครนักพัฒนาน้อยลงและทำงานน้อยลงและสิ่งอื่น ๆ ที่ซ้อนกันและผู้ร่วมให้ข้อมูลก็ไม่มีความสุขและท้ายที่สุดก็ต้องถูกทอดทิ้ง

อนาคตจะนำอะไรมา - มีการวิวัฒนาการที่ช้าเกิดขึ้นที่สิ่งต่างๆใน PHP ae สร้างขึ้นด้วย utf-8 ไม่ใช่ในแบบที่แข็งแกร่งกับประเภทที่กำหนดเองและบังคับให้ทุกอย่างและในขณะนี้นักพัฒนาไม่ได้รับแรงจูงใจที่จะสัมผัสเหล็กร้อนนี้ ใคร ๆ ก็สามารถหวังว่าใครบางคนมีข้อเสนอที่ดีที่จะทำให้มันทำงานได้ดี แต่ปัจจุบัน "ทุกคน" จะหนีไปถ้าพวกเขาได้ยินเพียงคำพูด :)

ฉันคิดว่าเหตุผลที่แท้จริงคือทีมพัฒนา PHP ขาดแผนการทำงานที่ชัดเจนสำหรับการพัฒนา PHP (ขอพูดถึงการสนทนาที่ค่อนข้างร้อนแรงเมื่อคนใน php-internals ตัดสินใจที่จะเริ่ม PHP สาขา 5.4 โดยไม่เห็นด้วยกับสิ่งที่ฟีเจอร์ 5.4 ควรมี) ฉันชอบภาษานี้มาก แต่วิธีการพัฒนามันทำให้ฉันกังวลเล็กน้อย