प्रत्येक डेवलपर को पाठ के साथ काम करने के लिए एन्कोडिंग और चरित्र सेट के बारे में जानने की आवश्यकता है, भाग 2

यह लेख के अनुवाद का दूसरा भाग है जो हर प्रोग्रामर को पूरी तरह से, एनकोडिंग और चरित्र सेट के बारे में जानने की जरूरत है पाठ के साथ काम करने के लिए, पहला भाग यहां है ।

मेरा दस्तावेज़ किसी भी एन्कोडिंग में पूर्ण बकवास है!

यदि बिट्स का अनुक्रम उचित नहीं लगता है (किसी व्यक्ति के दृष्टिकोण से), तो यह मामला है जब दस्तावेज़ को एक निश्चित समय पर सबसे अधिक गलत तरीके से परिवर्तित किया गया था। उदाहरण के लिए, हम टेक्स्ट ÉìÉGÉìÉRÉ [ÉfÉìÉBÇÕìÔǵÇO≠ ≠ Ç »and the लेते हैं, और बिना कुछ बेहतर सोचे, इसे UTF-8 में सहेजें। पाठ संपादक ने सुझाव दिया कि उसने मैक रोमन द्वारा एन्कोड किए गए पाठ को सही ढंग से पढ़ा और अब इसे एक अलग एन्कोडिंग में सहेजा जाना चाहिए। अंत में, ये सभी पात्र यूनिकोड में मान्य हैं। मेरा मतलब है, यूनिकोड में for, G के लिए और इसी तरह का एक क्लॉज है। तो हम इसे UTF-8 में सहेजते हैं:

11000011 10001001 01000111 11000011 10001001 11000011 10101100 11000011 10001001 01010010 11000011 10000101 01011011 11000011 10001001 01100110 11000011 10001001 01000010 11000011 10001001 11000011 10101100 11000011 10001001 01001111 11000011 10000111 11000011 10010101 11000011 10101100 11000011 10010100 11000011 10000111 11000010 10110101 11000011 10000111 11100010 10001001 10100000 11000011 10000111 11000010 10111011 11000011 10000111 11000010 10100010

तो अब पाठ nowGÉìÉRÅ [ÉfÉìÉBÇÕìÔǵÇO≠ Ç text »É a का प्रतिनिधित्व UTF-8 के बिट्स के अनुक्रम द्वारा किया जाता है। यह बिट अनुक्रम पूरी तरह से मूल दस्तावेज में क्या था से तलाकशुदा है। जो भी एन्कोडिंग हम इस क्रम को खोलते हैं, हम कभी भी सोर्स टेक्स्ट ン コ this this this this this this this this this encoding encoding नहीं देखेंगे। वह बस खो गया है। इसे बहाल किया जा सकता है अगर हम मूल शिफ्ट-जेआईएस एन्कोडिंग को जानते थे और हमने टेक्स्ट को मैक रोमन के रूप में माना, और फिर इसे यूटीएफ -8 में सहेजा। लेकिन ऐसे चमत्कार दुर्लभ हैं।

कई बार किसी विशेष एन्कोडिंग में एक विशेष बिट अनुक्रम गलत होता है। अगर हमने ASCII में मूल दस्तावेज को खोलने की कोशिश की, तो हम देखेंगे कि कुछ पात्रों को मान्यता दी गई थी, और कुछ को नहीं लिया गया था। आप जिस प्रोग्राम का उपयोग करते हैं, वह केवल बाइट्स को फेंकने का निर्णय ले सकता है जो वर्तमान एन्कोडिंग में फिट नहीं होते हैं, या उन्हें प्रश्न चिह्न के साथ बदल देते हैं। या यूनिकोड में एक विशेष प्रतिस्थापन चरित्र: special (U + FFFD)। यदि आप अनुपयोगी पात्रों को सहेजने के बाद दस्तावेज़ को सहेजते हैं, तो आप उन्हें स्थायी रूप से खो देंगे।

यदि आपने गलत तरीके से एन्कोडिंग का अनुमान लगाया है, और फिर इसे एक और में बचाया है, तो आप दस्तावेज़ को बर्बाद कर देंगे। आप इसे ठीक करने की कोशिश कर सकते हैं, लेकिन ये प्रयास आमतौर पर सफलता में समाप्त नहीं होते हैं। बिट-शिफ्टेड जादू आमतौर पर निष्क्रिय जादू रहता है: एक मृत मुर्गे की तरह।

और एन्कोडिंग कैसे बदलें?

यह वास्तव में आसान है! आपको पाठ के एक विशेष टुकड़े (बिट अनुक्रम) के एन्कोडिंग को जानना होगा और इसे डिक्रिप्शन के लिए लागू करना होगा। बस इतना ही करना है। यदि आप एक प्रोग्राम लिख रहे हैं जो उपयोगकर्ता से पाठ प्राप्त करता है, तो निर्धारित करें कि यह कौन सा एन्कोडिंग करेगा। किसी भी टेक्स्ट फील्ड को पता होना चाहिए कि उसे किस एन्कोडिंग में डेटा प्राप्त होता है। किसी भी प्रकार की फ़ाइल के लिए जिसे उपयोगकर्ता प्रोग्राम में लोड कर सकता है, एक एन्कोडिंग को परिभाषित किया जाना चाहिए। या इसके बारे में उपयोगकर्ता से पूछने का कोई तरीका होना चाहिए। फ़ाइल प्रारूप या उपयोगकर्ता द्वारा जानकारी प्रदान की जा सकती है (उनमें से अधिकांश को जानने की संभावना नहीं है, निश्चित रूप से, वे लेख पढ़ते हैं)।

यदि आपको पाठ को एक एन्कोडिंग से दूसरे में स्थानांतरित करने की आवश्यकता है, तो विशेष टूल का उपयोग करें। परिवर्तित करना एक थकाऊ काम है जो दो कोड पृष्ठों की तुलना करता है और उस चरित्र को एन्कोडिंग बी में एन्कोडिंग का निर्णय करता है। पहिया को सुदृढ़ करने की आवश्यकता नहीं है: हर आम प्रोग्रामिंग भाषा में टेक्स्ट को एन्कोडिंग से एन्कोडिंग में परिवर्तित करने के लिए बिट्स और कोड पृष्ठों से सार होता है।

कहते हैं कि आपके आवेदन को GB18030 में फ़ाइलों को स्वीकार करना चाहिए, लेकिन आंतरिक रूप से आप UTF-32 में काम करते हैं। Iconv टूल एक लाइन में रूपांतरण कर सकता है: iconv ('GB18030', 'UTF-32', $ string)। बिट प्रतिनिधित्व बदल गया है, भले ही अक्षर अपरिवर्तित रहेंगे।

चरित्र GB18030 एन्कोडिंग UTF-32 एन्कोडिंग
0 10111111 01101100 00000000 00000000 01111110 00100111

वह सब है। उसकी मानवीय समझ में स्ट्रिंग की सामग्री नहीं बदली है, लेकिन अब यह UTF-32 में सही स्ट्रिंग है। यदि आप UTF-32 में इसके साथ काम करना जारी रखते हैं, तो आपको अपठनीय पात्रों के साथ कोई समस्या नहीं होगी। हालांकि, जैसा कि हमने पहले चर्चा की, सभी एन्कोडिंग सभी वर्णों को प्रदर्शित करने में सक्षम नहीं हैं। यूरोपीय भाषाओं के लिए किसी भी एन्कोडिंग में चरित्र is को एनकोड करना संभव नहीं है। और कुछ भयानक हो सकता है।

यूनिकोड में सब कुछ

यही कारण है कि 21 वीं सदी में यूनिकोड का उपयोग नहीं करने का कोई बहाना नहीं है। यूरोपीय भाषाओं के लिए कुछ विशेष एन्कोडिंग विशिष्ट भाषाओं के लिए यूनिकोड की तुलना में अधिक उत्पादक हो सकते हैं। लेकिन जब आपको विशेष पाठ के टेराबाइट्स के साथ काम करने की ज़रूरत नहीं है (और यह बहुत है), तो आपको चिंता करने की कोई बात नहीं है। असंगत एन्कोडिंग से उत्पन्न समस्याएं खोई हुई गीगाबाइट की तुलना में बहुत खराब हैं। और यह तर्क केवल डेटा स्टोरेज और चैनल चौड़ाई के विकास और लागत में कमी के साथ और अधिक महत्वपूर्ण हो जाएगा।

यदि सिस्टम को अन्य एन्कोडिंग के साथ काम करने की आवश्यकता है, तो पाठ को पहले यूनिकोड में परिवर्तित करें, और यदि आपको इसे कहीं प्रदर्शित करने की आवश्यकता है, तो इसे वापस स्थानांतरित करें। अन्यथा, आपको डेटा तक पहुंचने के प्रत्येक मामले की सावधानीपूर्वक निगरानी करनी होगी और यदि आवश्यक हो तो बिना जानकारी के नुकसान के लिए आवश्यक रूपांतरण किए जा सकते हैं।

शुभ संयोग

मेरे पास डेटाबेस से जुड़ी एक वेबसाइट थी। मेरे आवेदन ने UTF-8 की तरह सब कुछ संसाधित किया और इसे डेटाबेस में इस तरह संग्रहीत किया, और सब कुछ सुपर था, लेकिन जब मैं डेटाबेस के व्यवस्थापक पैनल में गया, तो मुझे कुछ भी समझ नहीं आया।
- अनाम द्विपदीय

ऐसी स्थितियां हैं जब एन्कोडिंग को गलत तरीके से संसाधित किया जाता है, लेकिन सब कुछ अभी भी ठीक काम करता है। अक्सर ऐसा होता है कि डेटाबेस एन्कोडिंग लैटिन -1 में सेट हो जाता है, और एप्लिकेशन UTF-8 (या किसी अन्य) के साथ काम करता है। सामान्य तौर पर, 1 और 0 का कोई भी संयोजन सिंगल-बाइट लैटिन -1 में मान्य है। यदि डेटाबेस को आवेदन से फॉर्म 11100111 10111000 10100111 के आवेदन से डेटा प्राप्त होता है, तो उन्हें यह सोचकर प्रसन्नता होती है कि आवेदन का मतलब 縧 है। क्यों नहीं? बाद में, डेटाबेस उसी बिट्स को एप्लिकेशन में लौटाता है, जो खुश है, क्योंकि उसे UTF-8 प्रतीक UT प्राप्त हुआ था, जिसका उद्देश्य था। लेकिन डीबी प्रशासन इंटरफ़ेस जानता है कि लैटिन -1 का उपयोग किया जाता है, और यहां परिणाम है: कुछ भी समझना संभव नहीं है।
मूर्ख ने केवल लॉटरी जीती, हालांकि सितारे उसकी तरफ नहीं थे। डेटाबेस में पाठ पर कोई भी ऑपरेशन काम कर सकता है, लेकिन यह उद्देश्य के अनुसार नहीं किया जा सकता है, क्योंकि डेटाबेस पाठ की सही व्याख्या नहीं करता है। सबसे बुरी स्थिति में, डेटाबेस अनजाने में गलत एन्कोडिंग (और निश्चित रूप से, आपके लिए कोई बैकअप नहीं) के कारण स्थापना के 2 साल बाद एक मनमाना संचालन करते हुए, पूरे पाठ को अनजाने में नष्ट कर देगा।

UTF-8 और ASCII

UTF-8 की प्रतिभा ASCII के साथ द्विआधारी संगतता है, जो सभी एन्कोडिंग के लिए वास्तविक आधार है। सभी ASCII वर्ण UTF-8 में अधिकतम बाइट्स पर कब्जा कर लेते हैं और ASCII के समान बिट्स का उपयोग करते हैं। दूसरे शब्दों में, ASCII को UTF-8 में 1: 1 परिलक्षित किया जा सकता है। कोई भी गैर- ASCII वर्ण UTF-8 में 2 या अधिक बाइट्स रखता है। स्रोत कोड एन्कोडिंग के रूप में ASCII का उपयोग करने वाली अधिकांश प्रोग्रामिंग भाषाएं आपको टेक्स्ट में सीधे UTF-8 में पाठ शामिल करने की अनुमति देती हैं:

$ स्ट्रिंग = "string";

UTF-8 को सहेजना होगा अनुक्रम:

00100100 01110011 01110100 01110010 01101001 01101110 01100111 00100000
00111101 00100000 00100010 11100110 10111100 10100010 11100101 10101101
10010111 00100010 00111011

17 में से केवल 12 बाइट्स (1 से शुरू होने वाले) UTF-8 वर्ण (प्रत्येक के 3 बाइट्स के 2 वर्ण) हैं। अन्य पात्र ASCII में हैं। पार्सर निम्नलिखित पढ़ेगा:

$ स्ट्रिंग = "11100110 10111100 10100010 11100101 10101101 10010111";

Parser उद्धरण चिह्नों के पीछे सब कुछ मानता है बिट्स के एक अनुक्रम के रूप में व्याख्या की जानी चाहिए, सब कुछ, एक और उद्धरण के नीचे। यदि आप बस इस क्रम को आउटपुट करते हैं, तो आप टेक्स्ट को UTF-8 में आउटपुट करेंगे। और कुछ करने की जरूरत नहीं। पार्सर को विशेष रूप से utf-8 का समर्थन करने की आवश्यकता नहीं है, आपको बस लाइनों को शाब्दिक रूप से लेने की आवश्यकता है। सरल पार्सर यूनिकोड का समर्थन इस तरह से कर सकते हैं, वास्तव में यूनिकोड का समर्थन किए बिना। हालांकि, कई प्रोग्रामिंग भाषाएं यूनिकोड का स्पष्ट रूप से समर्थन करती हैं।

एनकोडिंग और PHP।

PHP यूनिकोड का समर्थन नहीं करता है। सच है, वह उसे अच्छी तरह से समर्थन करता है। पिछले पैराग्राफ में दिखाया गया है कि किसी भी समस्या के बिना प्रोग्राम टेक्स्ट में UTF-8 वर्णों को सीधे कैसे शामिल किया जाए, क्योंकि UTF-8 ASCII के साथ पिछड़ा हुआ है, और यह सभी PHP की जरूरत है। हालांकि, यह दावा कि "PHP यूनिकोड का समर्थन नहीं करता है" यह सच है क्योंकि यह PHP समुदाय में कई कठिनाइयों का कारण बनता है।

झूठे वादे

Utf8_encode और utf8_decode फ़ंक्शंस मेरे एक कॉलस बन गए। मुझे अक्सर बकवास लगता है जैसे "PHP में यूनिकोड का उपयोग करने के लिए, आपको इनपुट टेक्स्ट के लिए utf8_encode और आउटपुट के लिए utf8_decode कॉल करने की आवश्यकता है।" ये दो कार्य कुछ प्रकार के स्वचालित पाठ रूपांतरण UTF-8 का वादा करते हैं, जो माना जाता है कि आवश्यक है, क्योंकि "PHP यूनिकोड का समर्थन नहीं करता है।" यदि आप तिरछे तरीके से इस लेख को नहीं पढ़ रहे हैं, तो आप जानते हैं कि

1. UTF-8 में कुछ खास नहीं है
2. आप तथ्य के बाद UTF-8 में पाठ को एनकोड नहीं कर सकते

मैं 2 बिंदु की व्याख्या करूँगा: कोई भी पाठ पहले से ही किसी चीज़ से एन्कोडेड है। जब आप स्रोत कोड में लाइनों को चिपकाते हैं, तो उनके पास पहले से एन्कोडिंग होती है। अधिक सटीक रूप से, एन्कोडिंग जो आपके टेक्स्ट एडिटर वर्तमान में उपयोग कर रहा है। यदि आप उन्हें डेटाबेस से प्राप्त करते हैं, तो वे पहले से ही एन्कोडेड हैं। यदि आप उन्हें एक फ़ाइल से पढ़ते हैं ... पहले से ही जानते हैं, हाँ?

पाठ या तो UTF-8 में एन्कोडेड है या एन्कोडेड नहीं है। यदि नहीं, तो यह ASCII, ISO-8859-1, UTF-16 या कुछ और में एन्कोडेड है। यदि यह UTF-8 में नहीं है, लेकिन यह माना जाता है कि इसमें "UTF-8 वर्ण" हैं, तो आपके पास संज्ञानात्मक असंगति है। यदि पाठ में अभी भी वांछित वर्ण शामिल हैं जो UTF-8 में एन्कोड किए गए हैं, तो यह UTF-8 में है।

तो क्या नरक utf8_encode करता है?

"स्ट्रिंग ISO-8859-1 को एन्कोडिंग UTF-8 में अनुवाद करता है"

अहा! लेखक यह कहना चाहता था कि फ़ंक्शन ISO-8859-1 से पाठ को UTF-8 में बदल देता है। यहाँ यह किस लिए है। ऐसा भयानक नाम शायद उसे कुछ मेहमाननवाज यूरोपीय ने दिया था। वही utf8_decode के लिए जाता है। ये फ़ंक्शन ISO-8859-1 से UTF-8 में परिवर्तित करने के अलावा और किसी भी चीज के लिए लागू नहीं हैं। यदि आपको एन्कोडिंग की एक और जोड़ी की आवश्यकता है, तो आइकनव का उपयोग करें।
utf8_encode - यह आपके लिए कोई जादू की छड़ी नहीं है, जिसे आपको हर शब्द पर लहराने की आवश्यकता है क्योंकि "PHP यूनिकोड का समर्थन नहीं करता है।" यह हल करता है की तुलना में अधिक समस्याओं का कारण बनता है - उस यूरोपीय और अज्ञानी प्रोग्रामर को धन्यवाद कहें।

मूल निवासी-shmativny

तो उनका क्या मतलब है जब वे कहते हैं कि भाषा यूनिकोड का समर्थन करती है? यह महत्वपूर्ण है कि क्या भाषा यह मानती है कि एक चरित्र एक बाइट पर कब्जा करता है, या नहीं। इसलिए, PHP आपको चयनित वर्ण को एक्सेस करने की अनुमति देता है, स्ट्रिंग को एक वर्ण सरणी के रूप में मानता है:

गूंज $ स्ट्रिंग [0];

यदि $ स्ट्रिंग में एकल-बाइट एन्कोडिंग है, तो यह हमें पहला चरित्र देगा। लेकिन केवल इसलिए कि "चरित्र" एकल-बाइट एन्कोडिंग में "बाइट" से मेल खाता है। PHP केवल पात्रों के एक विचार के बिना पहली बाइट देता है। PHP के लिए स्ट्रिंग्स बाइट अनुक्रमों से ज्यादा कुछ नहीं हैं, न तो अधिक और न ही कम। आप के ये "पठनीय पात्र" एक व्यक्ति के एक कल्पना से ज्यादा कुछ नहीं हैं, PHP उनके बारे में कोई लानत नहीं देता है।

01000100 01101111 01101110 00100111 01110100
D पर 'टी
01100011 01100001 01110010 01100101 00100001
परवाह है!

यही कई मानक कार्यों पर लागू होता है, जैसे कि पदार्थ, स्ट्रैप, ट्रिम और अन्य। समर्थन समाप्त होता है जहां बाइट और चरित्र के बीच पत्राचार समाप्त होता है:

11100110 10111100 10100010 11100101 10101101 10010111
漢 漢

निर्दिष्ट स्ट्रिंग के लिए $ स्ट्रिंग [0] फिर से 11100110 के बराबर केवल पहली बाइट लौटाएगा। दूसरे शब्दों में, चरित्र the की तीसरी बाइट। अनुक्रम 11100110 UTF-8 के लिए अमान्य है, इसलिए स्ट्रिंग अब भी गलत है। यदि यह भी आपको लगता है, तो आप एक और एन्कोडिंग की कोशिश कर सकते हैं जिसमें 11100110 कुछ वैध यादृच्छिक चरित्र होगा। आप मज़े कर सकते हैं, लेकिन युद्ध सर्वर पर नहीं।

वह सब है। "PHP यूनिकोड का समर्थन नहीं करता है" का अर्थ है कि भाषा में अधिकांश फ़ंक्शन यह मानते हैं कि एक बाइट एक वर्ण के बराबर है, जो मल्टीबाइट वर्णों के ट्रंकेशन या स्ट्रिंग की लंबाई की गलत गणना की ओर जाता है। इसका मतलब यह नहीं है कि आप यूनिकोड को PHP में उपयोग नहीं कर सकते हैं, या किसी भी पाठ को utf8_encode, या किसी अन्य बेवकूफ चीज़ के माध्यम से चलाना चाहिए।

सौभाग्य से, एक विशेष विस्तार है जो सभी महत्वपूर्ण स्ट्रिंग कार्यों को जोड़ता है, लेकिन मल्टीबाइट एन्कोडिंग के लिए समर्थन के साथ। उपरोक्त लाइन पर mb_substr ($ string, 0, 1, 'UTF-8') सही ढंग से अनुक्रम 11100110 10111100 10100010 चरित्र to के अनुरूप लौटाएगा। इस तथ्य के कारण कि फ़ंक्शन को यह सोचने की ज़रूरत है कि वह क्या करता है, इसे एन्कोडिंग को पास करने की आवश्यकता है। इसलिए, ये फ़ंक्शन $ एन्कोडिंग पैरामीटर को स्वीकार करते हैं। वैसे, mb_internal_encoding का उपयोग करके सभी mb_ फ़ंक्शन के लिए एन्कोडिंग को वैश्विक रूप से सेट किया जा सकता है।

PHP त्रुटि हैंडलिंग का उपयोग और दुरुपयोग

PHP में (गैर-) यूनिकोड समर्थन के साथ पूरी समस्या यह है कि दुभाषिया परवाह नहीं करता है। बाइट सीक्वेंस, हा। कोई फर्क नहीं पड़ता कि उनका क्या मतलब है। स्मृति में तार संचय के अलावा कुछ भी नहीं किया जाता है। PHP की अवधारणा भी नहीं है - एन्कोडिंग। और जब आपको लाइनों में हेरफेर करने की आवश्यकता नहीं है, तो यह महत्वपूर्ण नहीं है। कार्य बाइट्स के अनुक्रमों के साथ किया जाता है, जिसे किसी व्यक्ति द्वारा पात्रों के रूप में माना जा सकता है। PHP को केवल ASCII के साथ संगत कोड स्रोत को सहेजने की आवश्यकता होती है। PHP पार्सर विशिष्ट वर्णों की तलाश में है जो यह बताता है कि क्या करना है। 00100100 कहते हैं: "एक चर घोषित करें", 00111101 - "असाइन करें", 00100010 - एक पंक्ति की शुरुआत या अंत, आदि। जो कुछ भी पार्सर के लिए महत्वपूर्ण नहीं है वह बाइट अनुक्रमों के शाब्दिक के रूप में माना जाता है। यह उन सभी चीजों पर भी लागू होता है जो उद्धरण चिह्नों में संलग्न हैं। इसका मतलब है:

1. आप PHP के साथ स्रोत को ASCII असंगत एन्कोडिंग में सहेजने में सक्षम नहीं होंगे। उदाहरण के लिए, UTF-16 में, उद्धरण चिह्न 00000000 00100010 के रूप में एन्कोड किया गया है। PHP के लिए, जो ASCII के रूप में सब कुछ मानता है, यह एक एनयूएल बाइट है जिसके बाद एक उद्धरण होता है। PHP शायद हर चरित्र पर हिचकी होगा NUL हो जाएगा।
2. आप PHP को ASCII संगत एन्कोडिंग में सहेज सकते हैं। यदि पहले 128 एन्कोडिंग अंक ASCII से मेल खाते हैं, तो PHP उन्हें खाएगा। PHP के लिए सभी महत्वपूर्ण वर्ण ASCII द्वारा परिभाषित पहले 128 बिंदुओं के भीतर स्थित हैं। यदि स्ट्रिंग शाब्दिकों में इस सीमा से परे कुछ भी है, तो PHP ध्यान नहीं देगा। आप ISO-8859-1, मैक रोमन, UTF-8 या किसी अन्य एन्कोडिंग में स्रोत को बचा सकते हैं। आपके कोड के स्ट्रिंग वर्णों को एन्कोडिंग प्राप्त होगी जिसमें आप फ़ाइल सहेजते हैं।
3. PHP के लिए किसी भी बाहरी फ़ाइल में कोई भी एन्कोडिंग हो सकती है। यदि पार्सर को फ़ाइल को संसाधित करने की आवश्यकता नहीं है, तो यह संतुष्ट रहेगा।
   
   

   $ फू = file_get_contents ('bar.txt');

   
   
   उपरोक्त बस $ foo चर में bar.txt से बाइट्स लगाएगा। PHP सामग्री के साथ अन्य धोखाधड़ी की व्याख्या, सांकेतिक शब्दों में बदलना या प्रदर्शन करने का प्रयास नहीं करेगा। एक फ़ाइल में बाइनरी डेटा या एक चित्र हो सकता है, PHP परवाह नहीं करता है।
4. यदि बाहरी और आंतरिक एनकोडिंग का मिलान होना चाहिए, तो उन्हें वास्तव में होना चाहिए। स्थानीयकरण एक सामान्य मामला है: कोड में आप इको लोकलाइज़ ('फ़ोबार') जैसा कुछ लिखते हैं, और एक बाहरी फ़ाइल में यह है:
   
   

   "फोबार"
   msgstr "" ー "ー ー"
   

   
   
   दोनों Foobar तार एक ही बिट प्रतिनिधित्व होना चाहिए। यदि स्रोत कोड ASCII में है, और स्थानीयकरण कोड UTF-16 में है, तो आप भाग्य से बाहर हैं। अतिरिक्त रूपांतरण करना आवश्यक है।
   

एक आश्चर्यजनक पाठक पूछ सकता है, कहते हैं, क्या ASCII में स्रोत फ़ाइल के शाब्दिक क्रम में UTF-16 बाइट्स को स्टोर करना संभव है, और उत्तर हमेशा यह होगा: निश्चित रूप से।

इको "यूटीएफ -16";

यदि आप अपने संपादक को ASCII और UTF-16 से UTF-16 में "इको" बचाने के लिए मजबूर करते हैं, तो सब कुछ काम करेगा। यहाँ द्विआधारी प्रतिनिधित्व है:

01100101 01100011 01101000 01101111 00100000 00100010
गूंज "
11111110 11111111 00000000 01010101 00000000 01010100
(UTF-16 मार्कर) UT
00000000 01000110 00000000 00101101 00000000 00110001
एफ - 1
00000000 00110110 00100010 00111011
6 ";

पहली पंक्ति और अंतिम 2 बाइट ASCII से हैं। बाकी को प्रति वर्ण 2 बाइट्स के साथ UTF-16 में दर्शाया गया है। दूसरी पंक्ति पर 11111110 11111111 को लीड करना UTF-16 में पाठ की शुरुआत के लिए एक मार्कर है (मानक के अनुसार, पीएचपी ने इस बारे में कोई सुनवाई नहीं की है)। यह स्क्रिप्ट UTF-16 में एन्कोड किए गए स्ट्रिंग "UTF-16" को आउटपुट करता है, क्योंकि यह बस दो कोट्स के बीच बाइट्स प्रदर्शित करता है, जिसके परिणामस्वरूप "UTF-16" टेक्स्ट UTF-16 में एनकोड हो जाता है। दूसरी तरफ, एएससीआईआई या यूटीएफ -16 में स्रोत पूरी तरह से सही नहीं है, इसलिए आप संपादक को खोल सकते हैं और कुछ मज़े कर सकते हैं।

कुल मिलाकर

PHP यूनिकोड का समर्थन करता है, या यों कहें कि कोई भी एन्कोडिंग तब तक बहुत सटीक है जब तक कि आप पार्सर को अपना काम करने के लिए प्राप्त कर सकते हैं, और डेवलपर यह समझने के लिए कि वह क्या करता है। स्ट्रिंग्स के साथ काम करते समय आपको केवल सावधान रहने की जरूरत है: विभाजन, रिक्त स्थान, गिनती और अन्य सभी ऑपरेशन जिन्हें वर्णों के साथ काम करने की आवश्यकता होती है, बाइट्स नहीं। अगर पढ़ने और आउटपुट को छोड़कर, लाइनों के साथ कुछ भी नहीं किया जाता है, तो शायद ही कोई समस्या है जो अन्य भाषाओं में नहीं मिलती है।

एन्कोडिंग समर्थित भाषाएँ

तो यूनिकोड का समर्थन करने के लिए भाषा का क्या मतलब है? उदाहरण के लिए जावास्क्रिप्ट यूनिकोड का समर्थन करता है। वास्तव में, जावास्क्रिप्ट में कोई भी तार UTF-8 में एन्कोडेड है। और यह एकमात्र एन्कोडिंग है जो जावास्क्रिप्ट के साथ काम करता है। आप बस जावास्क्रिप्ट को UTF-8 में न रखें। जावास्क्रिप्ट यूनिकोड को इस हद तक पूजता है कि भाषा के मूल में एक अलग एन्कोडिंग के साथ काम करने के लिए उपकरण नहीं होते हैं। चूंकि जावास्क्रिप्ट को अक्सर ब्राउज़र में निष्पादित किया जाता है, इसलिए आपको कोई समस्या नहीं है: ब्राउज़र एन्कोडिंग और डिकोडिंग I / O के तुच्छ तर्क को निष्पादित करने में सक्षम है।

अन्य भाषाएं केवल एनकोडिंग का समर्थन करती हैं। आंतरिक कार्य एक ही एन्कोडिंग में किया जाता है, अक्सर UTF-16 में। लेकिन इसका मतलब यह है कि उन्हें पाठ को एन्कोड करने में संकेत दिया जाना चाहिए, या वे स्वयं इसे निर्धारित करने का प्रयास करेंगे। यह इंगित करना आवश्यक है कि किस सोर्स कोड को एन्कोडिंग में सहेजा गया है, जिसमें फाइल को सहेजना एन्कोडिंग है, जिसे पढ़ा जाएगा, जिसमें एन्कोडिंग आउटपुट के लिए आवश्यक है। यदि यह इंगित किया जाता है कि यूनिकोड का उपयोग करने की आवश्यकता है, तो भाषा मक्खी पर परिवर्तित हो जाएगी। वे सब कुछ करते हैं जो PHP को पृष्ठभूमि में कहीं अर्ध-स्वचालित मोड में करने की आवश्यकता होती है। PHP से बेहतर और कोई बुरा नहीं, बस अलग। अच्छी खबर यह है कि स्ट्रिंग फ़ंक्शंस अंत में बस काम करते हैं, और आपको यह नहीं सोचना है कि स्ट्रिंग में मल्टीबीट वर्ण हैं या नहीं, जो कार्य और अन्य चीजों के लिए चुनना है जो पीएचपी में किए जाने हैं।

देबरी यूनिकोड

चूंकि यूनिकोड कई अलग-अलग समस्याओं को हल करता है और कई अलग-अलग परिदृश्यों में काम करता है, इसलिए आपको विडाल में खुदाई करके इसके लिए भुगतान करना होगा। उदाहरण के लिए, यूनिकोड मानक में YAKK जियोग्लिफ के एकीकरण जैसी समस्याओं को हल करने की जानकारी है। जापान, चीन और कोरिया के लिए आम कई पात्रों को थोड़ा अलग तरीकों से दर्शाया गया है। या निचले मामले से ऊपरी मामले में वर्णों को परिवर्तित करने की समस्याएं, इसके विपरीत या गोल-यात्रा, जो हमेशा की तरह पश्चिमी यूरोपीय भाषाओं के एन्कोडिंग के साथ सरल नहीं है।कुछ पात्रों को विभिन्न बिंदुओं द्वारा दर्शाया जा सकता है। उदाहरण के लिए अक्षर ö को पैराग्राफ U + 00F6 ("LATIN SMALL LETTER LETTER with DIERESIS") या दो पैराग्राफ U + 006F ("LITTLE LETTER LETTER O") और U + 0308 ("SUBSTITUTED DIARESIS") के रूप में दर्शाया जा सकता है, जिसका अर्थ है अक्षर। ¨ के साथ। UTF-8 में, यह 2 बाइट्स या 3 बाइट्स में से एक है, जो दोनों मामलों में एक सामान्य चरित्र है। इसलिए, मानक में सामान्यीकरण नियम हैं, अर्थात। इन रूपों को एक से दूसरे में कैसे परिवर्तित किया जाए। यह और बहुत कुछ लेख के दायरे से परे है, लेकिन आपको इन बिंदुओं के बारे में जानने की आवश्यकता है।

फिर से निसिल!

1. पाठ हमेशा बिट्स का एक अनुक्रम होता है जिसे तालिकाओं का उपयोग करके प्राकृतिक भाषा में अनुवाद करने की आवश्यकता होती है। अमान्य तालिका - अमान्य वर्ण।
2. आप पाठ के साथ सीधे काम नहीं कर सकते हैं - आप हमेशा उन बिट्स के साथ काम करते हैं जो अमूर्त में बदल जाते हैं। त्रुटियों में से एक अमूर्तता में त्रुटियों से संबंधित हैं।
3. सिस्टम जो एक-दूसरे को सूचना प्रसारित करते हैं, उन्हें हमेशा काम करने वाले एन्कोडिंग का संकेत देना चाहिए। उदाहरण के लिए, एक साइट ब्राउज़र को बताती है कि वह UTF-8 को जानकारी सबमिट कर रही है।
4. आजकल, UTF-8 ASCII के साथ पिछड़ा हुआ है, इस तथ्य के बावजूद कि यह लगभग किसी भी चरित्र को एन्कोड कर सकता है, और फिर भी ज्यादातर मामलों में अपेक्षाकृत प्रभावी है। अन्य एन्कोडिंग में भी आवेदन मिलता है, लेकिन यूनिकोड के केवल हिस्से का समर्थन करने वाले एन्कोडिंग के साथ खुद को पीड़ा देने का एक गंभीर कारण होना चाहिए।
5. प्रोग्राम और प्रोग्रामर दोनों को बाइट और कैरेक्टर के मिलान की समस्या से निपटना चाहिए।

जब आप पाठ को फिर से बर्बाद करते हैं तो अब औचित्य करने के लिए कुछ भी नहीं है।