हर कोई जानता है, कि PHP को यूनिकोड की समस्या है। संस्करण 6 को यूनिकोड कार्यान्वयन कठिनाइयों के कारण प्रभावी रूप से छोड़ दिया गया है। लेकिन मुझे आश्चर्य है कि अगर किसी को पता है कि सही कारण क्या हैं ? वास्तुकला / डिजाइन की समस्याएं, प्रदर्शन की चिंता, सामुदायिक समस्याएं (मैं शर्त नहीं), कुछ और?
जवाबों:
एक भाषा के रूप में PHP निश्चित रूप से हो सकती है, लेकिन मुझे लगता है कि समस्या मौजूदा कार्यक्रमों के साथ संगतता के साथ है। यूनिकोड समर्थन उन्हें सूक्ष्म तरीके से तोड़ सकता है, जो बग के लिए सबसे कष्टप्रद प्रकार है।
वर्तमान में PHP में अधिकांश स्ट्रिंग-प्रोसेसिंग फ़ंक्शन "बाइनरी-सेफ" हैं, जिसका अर्थ है कि आप उन्हें किसी भी एन्कोडिंग में किसी भी फ़ाइल को संसाधित करने के लिए उपयोग कर सकते हैं और साथ ही बाइनरी प्रारूप जैसे छवि डेटा, आदि।
यूनिकोड स्ट्रिंग्स के अलावा आपको बाइनरी स्ट्रिंग्स के साथ यूनिकोड स्ट्रिंग्स को मिक्स न करने के लिए बहुत सावधान रहना होगा (जब आपके स्ट्रिंग्स अलग-अलग स्रोतों से आते हैं और आपको इसके बारे में पहले कभी चिंता नहीं करनी थी)। और आप किसी भी अधिक एन्कोडिंग के बारे में अनभिज्ञ नहीं हो सकते हैं (और बहुत सारी स्क्रिप्ट इस बारे में अनभिज्ञ हैं!)
एक और कठिन, लेकिन सॉल्व करने योग्य समस्या यूनिकोड स्ट्रिंग्स में यादृच्छिक अभिगम है। $string[$offset]तुच्छ से परिवर्तनों का कार्यान्वयन या तो बहुत धीमा या थोड़ा धीमा और बहुत जटिल है।
इसके अलावा मुझे लगता है कि PHP के लिए UTF-16 को आंतरिक एन्कोडिंग के रूप में चुनना एक गलती थी। इसमें यूटीएफ -8 (सरोगेट जोड़े की वजह से चर चौड़ाई) और यूसीएस -2 की अक्षमता जैसी समस्याएं हैं। हो सकता है कि वे स्क्रैप करें और फिर से UTF-8 से शुरू करें?
</speculation>
TLDR: कई PHP लाइब्रेरीज़ केवल देशी सी लाइब्रेरीज़ पर एक पतली परत होती हैं जो यूनिकोड का समर्थन नहीं करती हैं, या इसे उन तरीकों से समर्थन करती हैं जो एक दूसरे के साथ असंगत हैं। इस स्थिति को सुधारने से पिछड़े असंगत परिवर्तन की संभावना है।
अस्वीकरण: जैसा कि मैंने कुछ साल पहले PHP से Python (कभी पीछे मुड़कर नहीं) देखने के लिए स्विच किया है, मेरी राय स्पष्ट रूप से अक्षम है।
मुझे लगता है कि PHP एक अच्छा और चतुर हैक है। हैक के रूप में, यह सरल शुरू हुआ और विरल पुस्तकालयों के एक समूह से कुछ हद तक विकसित हुआ - एक अच्छी तरह से सोचा और एकीकृत डिजाइन (कंप्यूटर भाषा के सिद्धांत के नजरिए से) का अभाव था।
जैसा कि मैकियावेली ने कहा, "जिसने पहले अपनी नींव नहीं रखी है, वह बाद में उन्हें बिछाने की बहुत क्षमता के साथ सक्षम हो सकता है, लेकिन उन्हें वास्तुकार और इमारत के लिए खतरे के साथ रखा जाएगा"।
एक प्रोग्रामिंग भाषा के लिए, अधिक लोकप्रिय, बदलने के लिए कठिन। इसीलिए हर 10 साल में एक बार C जैसी भाषाएं बदलती हैं। उदाहरण के लिए, पायथन 3 ने कई पिछड़े असंगत परिवर्तन किए, और यह बहुत सुंदर नहीं था। पिछले पायथन अवतारों में यूनिकोड का समर्थन पहले से ही PHP में मामलों की वर्तमान स्थिति के लिए बेहतर माना जाता था, लेकिन लगता है कि क्या: पायथन 3 में सबसे अधिक ध्रुवीय परिवर्तन यूनिकोड से संबंधित हैं। इस शेख़ी से आर्मिन Ronacher अजगर समुदाय का एक बड़ा हिस्सा से हताशा का सारांश है।
PHP का "सर्वव्यापी वेब प्लेटफॉर्म" इसे अपनी सफलता का शिकार बनाता है। PHP में यूनिकोड के लिए एकीकृत समर्थन लाना अपरिहार्य है, लेकिन इसके लिए बहुत अधिक रक्त, पसीना और आँसू की आवश्यकता होगी।
पुराने पीएचपी 6 काम को रोकने के प्राथमिक कारणों में से एक यह आंतरिक जटिलता के कारण था और इसे लाने के लिए काम की मात्रा थी, जो किसी को भी पूरी तरह से अनसुना कर देती थी।
थोड़ा सा इतिहास: PHP 6 के यूनिकोड की नकल को एक बड़े PHP उपयोगकर्ता की आवश्यकता द्वारा डिजाइन किया गया था और उसने यूनिकोड को "सही" करने की कोशिश की। कुछ मूल्यांकन के बाद पीएचपी-टू-यूनिकोड-सपोर्ट के प्राथमिक डिजाइनर ने एक नए स्ट्रिंग प्रकार को जोड़ने के लिए चुना है जो आंतरिक रूप से यूटीएफ -16 है और विभिन्न स्थानों में अलग-अलग एनडिंग का उपयोग करने की अनुमति देता है। तो कोड को एक एन्कोडिंग में लिखा जा सकता है, आउटपुट एक अलग एन्कोडिंग और "रनटम ऑपरेशन" कुछ अन्य एन्कोडिंग का उपयोग कर सकता है। UTF-16 को चुनने का कारण यह था कि यह कार्य ICU के आधार पर होना चाहिए जो UTF-16 का उपयोग करता है और यह पाया गया कि यह एन्कोडिंग utf- और utf-16 के बीच बातचीत करते समय तेजी से सामान्य स्ट्रिंग संचालन करता है। । अब तक सब ठीक है।
अब ऐसा करने का परिणाम नए स्ट्रिंग प्रकार की शुरूआत में सबसे आगे है। तब तक PHP के आंतरिक प्रकार की प्रणाली में कुछ प्रकार (NULL, bool, int / long, float / double, string, array, resource, object) थे और बहुत सारे कोड इस पर कुछ मान्यताओं थे। ऐसी धारणाओं के अलावा, स्ट्रिंग्स पर काम करने वाले सभी कार्य हैं, और उनमें से बहुत सारे हैं, व्यक्तिगत रूप से मूल्यांकन किया जाना है और यह तय करना है कि एन्कोडिंग को कैसे संभालना है। क्या उन्हें बाइनरी स्ट्रिंग्स या यूनिकोड स्ट्रिंग्स पर काम करना चाहिए? यदि एक रूपांतरण की आवश्यकता होती है जो एन्कोडिंग आदि का उपयोग किया जाना चाहिए और यह बहुत काम है और कुछ मामलों में सही करने के लिए काफी जटिल है। इसके अतिरिक्त आंतरिक API काफी जटिल हो गए, क्योंकि PHP में अधिकांश प्रमुख API को बाइनरी स्ट्रिंग्स (पुराना वाला) के लिए संस्करण मिलते थे और फिर अक्सर "रनटाइम एन्कोडेड" स्ट्रिंग्स के लिए एक संस्करण,
ऐसा करने की प्रक्रिया पर कि कई डेवलपर्स कॉपीप्लेक्सिटी पर ठोकर खाए, utf-16 से नाराज हो गए और इस तथ्य को पसंद नहीं किया कि यह डबल मेमोरी उपयोग से अधिक होगा और अधिकांश मौजूदा अनुप्रयोगों को तोड़ते समय बहुत सारे स्ट्रिंग को परिवर्तित करने में खर्च करेगा। इसलिए, स्वयंसेवकों द्वारा संचालित किए जा रहे PHP, कम और कम डेवलपर्स इस पर काम कर रहे थे और अन्य चीजें ढेर हो गईं और योगदानकर्ता नाखुश हो गए और अंत में इसे छोड़ देना पड़ा।
अब भविष्य क्या ला सकता है? - धीमी गति से विकास हो रहा है कि PHP ae में अधिक से अधिक चीजें utf-8 के आसपास बनाई गई हैं। एक कस्टम प्रकार के साथ एक मजबूत तरीके से नहीं और सब कुछ मजबूर करने के लिए और वर्तमान में इस गर्म लोहे को छूने के लिए विकसित करने के लिए प्रेरित नहीं हैं। कोई यह आशा कर सकता है कि किसी के पास इसे अच्छी तरह से काम करने का एक अच्छा प्रस्ताव है, लेकिन वर्तमान में "हर कोई" भाग जाएगा यदि वे केवल शब्द सुनते हैं। :)
मुझे लगता है कि वास्तविक कारण यह है कि PHP विकासशील टीम में PHP विकास के लिए एक स्पष्ट रोडमैप की कमी है (चलो बस एक बहुत गर्म चर्चा का उल्लेख करते हैं जब php-internals पर किसी ने पहले PHP 5.4 शाखा को शुरू करने का फैसला किया था, जिसमें 5.4 शामिल नहीं होना चाहिए)। मुझे यह भाषा बहुत पसंद है, लेकिन इसे विकसित करने का तरीका मुझे थोड़ा चिंतित करता है।