यूनिकोड और .NET

अनुवादक से। Habré ने पहले से ही यूनिकोड और .NET में लाइनों पर दोनों तरह के लेख प्रकाशित किए हैं। हालाँकि, .NET के बारे में अभी तक कोई यूनिकोड लेख नहीं था, इसलिए मैंने मान्यता प्राप्त .NET गुरु जॉन स्कीट द्वारा लेख का अनुवाद करने का निर्णय लिया। यह .NET में स्ट्रिंग्स पर जे। स्कीट के तीन लेखों-अनुवादों का मेरा वादा किया चक्र बंद करता है। हमेशा की तरह, मुझे टिप्पणियों और सुधारों पर खुशी होगी।

परिचय

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

साधन

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

• यूनिकोड कंसोर्टियम आधिकारिक वेबसाइट । यूनिकोड जानकारी का सबसे पूर्ण और सटीक स्रोत जिसमें आपके सभी सवालों के जवाब हैं (हालांकि आपको साइट पर उपयोगी जानकारी देखने की आवश्यकता है)। नीचे दिए गए कुछ लिंक इस साइट का नेतृत्व करते हैं।
• यूनिकोड शब्दावली । चरित्र एन्कोडिंग, आदि पर चर्चा करने में उपयोग किए जाने वाले कई शब्दों की संक्षिप्त व्याख्या वाला एक शब्दकोश।
• यूनिकोड FAQ । समूहों में वितरित सैकड़ों सामान्य प्रश्नों के उत्तर।
• यूनिक्स / लिनक्स यूटीएफ -8 अक्सर पूछे जाने वाले प्रश्न । इस लिंक की उपेक्षा न करें, इसके नाम को देखते हुए - भले ही आप यूनिक्स / लिनक्स के साथ दोस्त नहीं हैं, अधिकांश जानकारी .NET के लिए बहुत प्रासंगिक है।
• यूनिकोड चरित्र एन्कोडिंग मॉडल । "वर्ण एन्कोडिंग योजना" आदि जैसे शब्दों की सटीक व्याख्या पर अधिक जानकारी प्रदान करता है।
• जोएल स्पोल्स्की। एक अनिवार्य न्यूनतम जो हर सॉफ्टवेयर डेवलपर को यूनिकोड और चरित्र सेट के बारे में पता होना चाहिए (बहाने की अनुमति नहीं है) । कुछ इसी तरह का एक लेख, लेकिन .NET पर जोर दिए बिना। ( रूसी में अनुवाद, हब्रे भाग 1 पर अनुवाद, भाग 2 )
• यूनिकोड की दया के बारे में । पढ़ने के लायक एक और परिचयात्मक लेख।

बाइनरी और टेक्स्ट डेटा दो अलग-अलग चीजें हैं।

अधिकांश आधुनिक प्रोग्रामिंग भाषाएं (कुछ पुरानी की तरह) बाइनरी (बाइनरी) सामग्री और प्रतीकात्मक (या पाठ) सामग्री के बीच एक स्पष्ट रेखा खींचती हैं। हालांकि यह अंतर सहज स्तर पर समझा जाता है, फिर भी मैं एक परिभाषा बनाऊंगा।

बाइनरी (बाइनरी) डेटा किसी भी प्राकृतिक अर्थ या व्याख्या से जुड़े बिना ऑक्टेट्स (एक ऑक्टेट में 8 बिट्स) का एक अनुक्रम है। और यहां तक ​​कि ओकटेट्स के एक या दूसरे सेट की बाहरी "व्याख्या" भी होती है, जैसे, एक निष्पादन योग्य फ़ाइल या ग्राफिक छवि, डेटा केवल ओकटेट्स का एक सेट है। इसके अलावा, शब्द "ओकटेट" के बजाय, मैं "बाइट" का उपयोग करूंगा, हालांकि, सटीक होने के लिए, हर बाइट एक ऑक्टेट नहीं है। उदाहरण के लिए, 9-बिट बाइट्स के साथ कंप्यूटर आर्किटेक्चर थे। हालांकि, इस संदर्भ में, इस तरह के विवरण की वास्तव में आवश्यकता नहीं है, इसलिए "बाइट" शब्द के बाद मेरा मतलब बिल्कुल 8-बिट बाइट होगा।

चरित्र (पाठ) डेटा वर्णों का एक क्रम है।

यूनिकोड शब्दकोष एक प्रतीक को परिभाषित करता है:

1. शब्दार्थ अर्थ युक्त लिखित भाषा का सबसे छोटा घटक; विशेष रूपों (जैसे ग्लिफ़ ) के विपरीत, एक अमूर्त अर्थ और / या रूप को इंगित करता है; कोड तालिकाओं में, पात्रों के दृश्य प्रतिनिधित्व के कुछ रूप पाठक को समझने के लिए बहुत महत्व रखते हैं।
2. एक सार प्रतीक का एक पर्याय (धारा 3.3, वर्ण और कोडित प्रतिनिधित्व में परिभाषा डी 3 देखें)।
3. यूनिकोड कोडिंग प्रणाली में कोडिंग की मूल इकाई।
4. चीनी मूल के वैचारिक लिखित तत्वों का अंग्रेजी नाम।

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

दुर्भाग्य से, हाल के दिनों में, द्विआधारी और पाठ डेटा के बीच का अंतर बहुत धुंधला, फजी था। उदाहरण के लिए, सी प्रोग्रामर के लिए, ज्यादातर मामलों में "बाइट" और "चरित्र" शब्दों का मतलब एक ही बात था। .NET और जावा जैसे आधुनिक प्लेटफार्मों में, जहां वर्ण और बाइट के बीच अंतर स्पष्ट और इनपुट / आउटपुट लाइब्रेरी में तय होता है, पुरानी आदतों के नकारात्मक परिणाम हो सकते हैं (उदाहरण के लिए, लोग इसके बारे में चरित्र तार पढ़कर एक द्विआधारी फ़ाइल की सामग्री को कॉपी करने का प्रयास कर सकते हैं, जो इस फ़ाइल की सामग्री को विकृत करेगा)।

तो यूनिकोड किसके लिए है?

यूनिकोड कंसोर्टियम चरित्र डेटा के प्रसंस्करण को मानकीकृत करने की कोशिश कर रहा है, जिसमें द्विआधारी से पाठ तक रूपांतरण और इसके विपरीत (जिसे क्रमशः डिकोडिंग और एन्कोडिंग कहा जाता है)। इसके अलावा, आईएसओ मानकों का एक सेट है (विभिन्न संस्करणों में 10646) जो ऐसा करते हैं; यूनिकोड और आईएसओ 10646 को एक ही चीज माना जा सकता है, क्योंकि वे लगभग पूरी तरह से संगत हैं। (सिद्धांत रूप में, आईएसओ 10646 एक व्यापक संभावित चरित्र सेट को परिभाषित करता है, लेकिन यह कभी भी एक समस्या बनने की संभावना नहीं है।) .NET और जावा सहित अधिकांश आधुनिक प्रोग्रामिंग भाषाएं और प्लेटफॉर्म, यूनिकोड का उपयोग पात्रों का प्रतिनिधित्व करने के लिए करते हैं।

यूनिकोड परिभाषित, अन्य बातों के अलावा:

• अमूर्त वर्णों की सूची ( अमूर्त चरित्र प्रदर्शनों की सूची ) - सभी पात्रों का एक सेट जो यूनिकोड द्वारा समर्थित हैं;
• वर्ण कोडों का एक समूह ( कोडित वर्ण सेट ) - इसमें प्रत्येक चरित्र के विभाजन को एक गैर-नकारात्मक पूर्णांक से एक कोड बिंदु कहा जाता है;
• कुछ वर्ण एन्कोडिंग फ़ॉर्म - कोड बिंदुओं और "कोड इकाइयों" के अनुक्रमों के बीच पत्राचार का निर्धारण करते हैं (सीधे शब्दों में कहें, किसी भी लम्बाई के एक पूर्णांक और इस संख्या को कूटने वाले बाइट्स के समूह के रूप में व्यक्त कोड बिंदु के बीच पत्राचार);
• कुछ वर्ण एन्कोडिंग योजनाएं - कोड इकाइयों और क्रमबद्ध बाइट अनुक्रमों के सेट के बीच पत्राचार निर्धारित करते हैं।

वर्ण एन्कोडिंग फ़ॉर्म और वर्ण एन्कोडिंग योजना के बीच का अंतर काफी सूक्ष्म है, हालांकि, यह एंडियननेस ऑर्डर को ध्यान में रखता है। (उदाहरण के लिए, UCS-2 एन्कोडिंग में, कोड इकाइयों 0xC2 0xA9 के अनुक्रम को 0xC2 0xA9 के रूप में या 0xA9 0xC2 के रूप में क्रमबद्ध किया जा सकता है - यह वर्ण एन्कोडिंग योजना का निर्णय करता है।)

अमूर्त यूनिकोड वर्णों के प्रदर्शन में 1114112 वर्णों तक के सिद्धांत शामिल हो सकते हैं, हालांकि कई पहले से ही अनुपयोगी के रूप में आरक्षित हैं, और शेष सबसे अधिक कभी भी असाइन नहीं किए जाएंगे। प्रत्येक वर्ण 0 से 1114111 (0x10FFFF) तक एक गैर-नकारात्मक पूर्णांक के साथ एन्कोड किया गया है। उदाहरण के लिए, राजधानी ए को दशमलव संख्या 65 के साथ एन्कोड किया गया है। कुछ साल पहले यह माना जाता था कि सभी वर्ण 0 और 2 ¹⁶ -1 के बीच सीमा में फिट होंगे, जिसका मतलब था कि किसी भी चरित्र को दो बाइट्स का उपयोग करके दर्शाया जा सकता है। दुर्भाग्य से, समय के साथ इसने और अधिक चरित्र ले लिए, जिससे तथाकथित की उपस्थिति हुई। "सरोगेट जोड़े" ( सरोगेट जोड़ी )। उनके साथ, सब कुछ बहुत अधिक जटिल हो गया है (कम से कम मेरे लिए), और इसलिए इस लेख के अधिकांश उनके साथ नहीं निपटेंगे - मैं उन्हें "मुश्किल क्षणों" अनुभाग में संक्षेप में बताऊंगा ।

तो .NET क्या प्रदान करता है?

उपरोक्त सभी अजीब लग रहा है, तो चिंता न करें। ऊपर वर्णित मतभेदों को जानना चाहिए, लेकिन वास्तव में वे अक्सर सामने नहीं आते हैं। आपके अधिकांश कार्य प्रायः बाइट्स के एक निश्चित सेट को कुछ पाठ और इसके विपरीत में परिवर्तित करने की परिक्रमा करेंगे। ऐसी स्थितियों में, आप System.Char संरचना (उपनाम # के अंतर्गत C # में जाना जाता है), System.String वर्ग (C # में string ), और System.Text.Encoding वर्ग के साथ काम करेंगे।

Char संरचना सी # में सबसे बुनियादी प्रकार का चरित्र है, Char का एक उदाहरण एक यूनिकोड चरित्र का प्रतिनिधित्व करता है और 2 बाइट्स मेमोरी का कब्ज़ा करता है, जिसका अर्थ है कि यह 0-65535 रेंज से कोई भी मूल्य ले सकता है। ध्यान रखें कि इस श्रेणी के सभी नंबर मान्य यूनिकोड वर्ण नहीं हैं।

String क्लास मूल रूप से पात्रों का एक क्रम है। यह अपरिवर्तनीय है, जिसका अर्थ है कि एक स्ट्रिंग का उदाहरण बनाने के बाद, आप अब इसे (उदाहरण) नहीं बदल सकते हैं - String वर्ग के विभिन्न तरीके, हालांकि वे ऐसा देखते हैं कि वे इसकी सामग्री को बदलते हैं, वास्तव में एक नया स्ट्रिंग बनाते हैं और वापस करते हैं।

System.Text.Encoding वर्ग वर्णों के एक सरणी या एक स्ट्रिंग में बाइट्स के एक सरणी को बदलने और इसके विपरीत के लिए साधन प्रदान करता है। यह वर्ग अमूर्त है; इसके विभिन्न कार्यान्वयन .NET में दोनों का प्रतिनिधित्व करते हैं और उपयोगकर्ताओं द्वारा स्वयं लिखे जा सकते हैं। ( System.Text.Encoding कार्यान्वयन को बनाने का कार्य शायद ही कभी उठता है - ज्यादातर मामलों में आपके पास बहुत सारी कक्षाएं होंगी जो .NET का हिस्सा हैं।) Encoding आपको एन्कोडर और डिकोडर्स को अलग-अलग निर्दिष्ट करने की अनुमति देता है जो कॉल के बीच राज्य की प्रक्रिया करते हैं। यह मल्टीबीट कैरेक्टर एन्कोडिंग योजनाओं के लिए आवश्यक है, जब एक धारा से प्राप्त सभी बाइट्स को वर्णों में सही ढंग से डिकोड करना असंभव है। उदाहरण के लिए, यदि UTF-8 डिकोडर को इनपुट के रूप में दो बाइट्स 0x41 0xC2 मिलते हैं, तो यह केवल पहला वर्ण (कैपिटल लेटर "A") वापस कर सकता है, हालाँकि, दूसरे कैरेक्टर को निर्धारित करने के लिए इसे तीसरे बाइट की आवश्यकता होती है।

अंतर्निहित एन्कोडिंग योजनाएं

.NET क्लास लाइब्रेरी में विभिन्न एन्कोडिंग योजनाएँ हैं। नीचे इन योजनाओं का वर्णन है और उनका उपयोग कैसे किया जाए।

ASCII

ASCII सबसे आम में से एक है और एक ही समय में सबसे गलत चरित्र चरित्र एनकोडिंग में से एक है। लोकप्रिय ग़लतफ़हमी के विपरीत, ASCII 7-बिट एन्कोडिंग है, 8-बिट नहीं: 127 से अधिक कोड (कोड पॉइंट) वाले वर्ण मौजूद नहीं हैं। यदि कोई कहता है कि वह उपयोग करता है, उदाहरण के लिए, कोड "ASCII 154", तो हम यह मान सकते हैं कि यह कोई नहीं समझता कि वह क्या कर रहा है और कह रहा है। सच है, एक बहाने के रूप में, वह "विस्तारित ASCII" ( विस्तारित ASCII ) के बारे में कुछ कह सकता है। इसलिए - "विस्तारित ASCII" नामक कोई योजना नहीं है। कई 8-बिट एन्कोडिंग योजनाएं हैं जो एएससीआईआई के एक सुपरसेट हैं, और "विस्तारित एएससीआईआई" शब्द का उपयोग कभी-कभी उन्हें संदर्भित करने के लिए किया जाता है, जो पूरी तरह से सही नहीं है। प्रत्येक ASCII वर्ण का कोड बिंदु एक समान यूनिकोड वर्ण के कोड बिंदु से मेल खाता है: दूसरे शब्दों में, निचले मामले में लैटिन अक्षर "x" का ASCII वर्ण और उसी वर्ण का यूनिकोड वर्ण समान संख्या (120 (हेक्साडेसिमल नोटेशन में 0x78) द्वारा इंगित किया गया है। ASCIIEncoding .NET वर्ग (जिसका एक उदाहरण आसानी से Encoding.ASCII संपत्ति के माध्यम से प्राप्त किया जा सकता है), मेरी राय में, थोड़ा अजीब है, क्योंकि यह आधार 7s के बाद बस सभी बिट्स को ड्रॉप करके एन्कोडिंग प्रदर्शन करता है। इसका मतलब यह है कि, उदाहरण के लिए, यूनिकोड वर्ण 0xB5 ("माइक्रो" साइन µ है ), ASCII में एन्कोडिंग और यूनिकोड पर वापस डिकोड करने के बाद, 0x35 वर्ण (अंक "5") में बदल जाएगा। (इसके बजाय, मैं पसंद करूंगा कि कुछ विशेष चरित्र को प्रदर्शित किया जाए, यह दर्शाता है कि मूल चरित्र ASCII में अनुपस्थित था और खो गया था।)

UTF-8

यूटीएफ -8 यूनिकोड वर्णों का प्रतिनिधित्व करने का एक अच्छा और सामान्य तरीका है। प्रत्येक वर्ण एक से चार तक समावेशी में बाइट्स के अनुक्रम द्वारा एन्कोड किया गया है। (65536 से कम कोड बिंदु वाले सभी वर्ण एक, दो, या तीन बाइट्स में एन्कोड किए गए हैं; मैंने परीक्षण नहीं किया है कि कैसे .NET सरोगेट जोड़े को एन्कोड करता है: 1-3 बाइट्स के दो अनुक्रमों या 4 बाइट्स के एक अनुक्रम के साथ।) UTF-8 सभी को प्रदर्शित कर सकता है। यूनिकोड वर्ण और ASCII संगत है ताकि ASCII वर्णों के किसी भी अनुक्रम को बिना बदलावों के UTF-8 में ट्रांसकोड किया जा सके (यानी, ASCII में वर्णों का प्रतिनिधित्व करने वाला बाइट्स का एक क्रम और UTF-8 में समान वर्णों का प्रतिनिधित्व करने वाले बाइट्स का एक क्रम वही हैं)। इसके अलावा, पहला बाइट एन्कोडिंग एक चरित्र यह निर्धारित करने के लिए पर्याप्त है कि कितने बाइट्स एक ही वर्ण को एन्कोड करते हैं, यदि कोई हो। UTF-8 को खुद बाइट ऑर्डर मार्क (BOM) की आवश्यकता नहीं है, हालाँकि इसका उपयोग यह दर्शाने के लिए किया जा सकता है कि पाठ UTF-8 प्रारूप में है। एक BOM युक्त UTF-8 पाठ हमेशा तीन बाइट्स 0xEF 0xBB 0xBF के अनुक्रम से शुरू होता है। .NET में UTF-8 में एक स्ट्रिंग को एनकोड करने के लिए, बस Encoding.UTF8 प्रॉपर्टी का उपयोग करें। वास्तव में, ज्यादातर मामलों में, आपको ऐसा करने की ज़रूरत नहीं है - कई वर्ग ( स्ट्रीमवॉटर सहित) डिफ़ॉल्ट रूप से UTF-8 का उपयोग करते हैं जब कोई अन्य एन्कोडिंग स्पष्ट रूप से सेट नहीं होती है। (कोई गलती न करें। एनकोडिंग । डीफॉल्ट यहां लागू नहीं होता है, यह पूरी तरह से अलग है।) फिर भी, मैं आपको सलाह देता हूं कि अपने कोड में एन्कोडिंग को हमेशा स्पष्ट रूप से निर्दिष्ट करें, यदि केवल पठनीयता और समझ के लिए।

UTF-16 और UCS-2

UTF-16 सिर्फ एन्कोडिंग है जिसमें .NET वर्णों के साथ काम करता है। प्रत्येक चरित्र को दो बाइट्स के अनुक्रम द्वारा दर्शाया गया है; तदनुसार, एक सरोगेट जोड़ी 4 बाइट्स लेती है। सरोगेट जोड़े का उपयोग करने की क्षमता UTF-16 और UCS-2 के बीच एकमात्र अंतर है: UCS-2 (जिसे यूनिकोड के रूप में भी जाना जाता है) सरोगेट जोड़े की अनुमति नहीं देता है और 0-65535 (0xxFFFF) श्रेणी के वर्णों का प्रतिनिधित्व कर सकता है। UTF-16 में बाइट्स (एंडियननेस) का एक अलग क्रम हो सकता है: यह उच्च से निम्न ( बिग-एंडियन ), निम्न से उच्च ( थोड़ा-एंडियन ) हो सकता है, या यह वैकल्पिक BOM (0xFF 0xFE) के लिए मशीन-निर्भर हो सकता है एंडियन, 0xFE 0xFF बड़े-एंडियन के लिए)। .NET में, जहां तक ​​मुझे पता है, सरोगेट जोड़े की समस्या "रन" थी, और सरोगेट जोड़ी में प्रत्येक चरित्र को एक स्वतंत्र प्रतीक माना जाता है, जो UCS-2 और UTF-16 के बीच एक प्रकार का "समीकरण" होता है। (UCS-2 और UTF-16 के बीच सटीक अंतर सरोगेट जोड़े की बहुत गहरी समझ है, और मैं इस पहलू में सक्षम नहीं हूं।) बड़े-एंडियन दृश्य में UTF-16 एनकोडिंग का उपयोग करके प्राप्त किया जा सकता है। BndEndianUnicode संपत्ति, और थोड़ा- एंडियन - एनकोडिंग का उपयोग कर। यूनिकोड । दोनों गुण System.Text.UnicodeEncoding वर्ग का एक उदाहरण लौटाते हैं, जिसे विभिन्न कन्स्ट्रक्टर ओवरलोड का उपयोग करके भी बनाया जा सकता है: यहां आप निर्दिष्ट कर सकते हैं कि BOM का उपयोग किया जाए या नहीं और बाइट्स को किस क्रम में सेट किया जाना चाहिए। मुझे लगता है (हालाँकि मैंने इसका परीक्षण नहीं किया है) कि द्विआधारी सामग्री को डिकोड करने के दौरान, सामग्री में मौजूद बीओएम एनकोडर में निर्धारित बाइट ऑर्डर सेटिंग्स को ओवरराइड करता है, ताकि प्रोग्रामर को कोई अतिरिक्त इशारे न करें यदि वह किसी भी सामग्री को डिकोड करता है, तो भी यदि बाइट ऑर्डर और / या इस सामग्री में BOM की उपस्थिति उसके लिए अज्ञात है।

UTF-7

UTF-7, मेरे अनुभव को देखते हुए, इसका उपयोग शायद ही कभी किया जाता है, लेकिन यह आपको ASCII वर्णों में यूनिकोड (शायद केवल पहले 65535 अक्षर) को ट्रांसकोड करने की अनुमति देता है (बाइट्स नहीं!)। यह उन स्थितियों में ई-मेल के साथ काम करते समय उपयोगी हो सकता है जहां मेल गेटवे केवल ASCII वर्णों का समर्थन करते हैं, या यहां तक ​​कि ASCII का केवल सबसेट (उदाहरण के लिए, EBCDIC एन्कोडिंग)। मेरा विवरण धीमा दिखता है, क्योंकि मैं कभी भी UTF-7 के विवरण में नहीं चढ़ता और मैं अब से ऐसा नहीं करने जा रहा हूं। यदि आपको UTF-7 का उपयोग करने की आवश्यकता है, तो आप शायद पहले से ही पर्याप्त जानते हैं, और यदि आपको UTF-7 का उपयोग करने की पूर्ण आवश्यकता नहीं है, तो मैं आपको सलाह देता हूं कि आप नहीं। UTF-7 में एन्कोडिंग के लिए एक श्रेणी उदाहरण Encoding.UTF7 संपत्ति का उपयोग करके प्राप्त किया जा सकता है।

विंडोज / एएनएसआई कोड पेज

विंडोज कोड पेज आम तौर पर एक या दो बाइट कैरेक्टर सेट होते हैं जो क्रमशः 256 या 65,536 वर्णों तक के होते हैं। प्रत्येक कोड पृष्ठ का अपना नंबर होता है, और ज्ञात संख्या वाले कोड पृष्ठ के लिए एनकोडर को स्थैतिक विधि Encoding.GetEncoding (Int32) का उपयोग करके प्राप्त किया जा सकता है। ज्यादातर मामलों में, कोड पृष्ठ पुराने डेटा के साथ काम करने के लिए उपयोगी होते हैं, जिसे अक्सर " डिफ़ॉल्ट कोड पृष्ठ " में संग्रहीत किया जाता है। डिफ़ॉल्ट कोड पृष्ठ के लिए एनकोडर Encoding.Default संपत्ति का उपयोग करके प्राप्त किया जा सकता है। फिर, जब भी संभव हो कोड पृष्ठों का उपयोग करने से बचें। अधिक जानकारी के लिए, MSDN से संपर्क करें।

आईएसओ-8859-1 (लैटिन -1)

एएससीआईआई की तरह, लैटिन -1 कोड पृष्ठ के प्रत्येक चरित्र में यूनिकोड के समान वर्ण के कोड के समान कोड होता है। मैंने यह पता लगाने की जहमत नहीं उठाई कि क्या लेटिन -1 में 128 से 159 तक के कोड वाले अनकाउंटेड कैरेक्टर्स का "होल" है, या लेटिन -1 में यूनिकोड जैसा ही कंट्रोल कैरेक्टर है या नहीं। (मैं एक "छेद" के विचार की ओर झुकाव करना शुरू कर दिया, लेकिन विकिपीडिया मेरे साथ असहमत है, इसलिए मैं अभी भी सोच रहा हूं! लेखक के विचार स्पष्ट नहीं हैं , क्योंकि विकिपीडिया लेख स्पष्ट रूप से अंतर की उपस्थिति दिखाता है ; संभवतः, मूल लेख लिखते समय, सामग्री विकिपीडिया लेख अलग था। - लगभग। अनुवाद। )) लैटिन -1 में 28591 का कोड पेज नंबर है, इसलिए एनकोडर प्राप्त करने के लिए, Encoding.GetEncoding(28591) उपयोग करें। Encoding.GetEncoding(28591) विधि।

धाराएँ, पाठक और लेखक

धाराएं बाइनरी प्रकृति में हैं, वे बाइट्स पढ़ती हैं और लिखती हैं। सब कुछ जो एक स्ट्रिंग को स्वीकार करता है, उसे एक निश्चित तरीके से बाइट्स में बदलना चाहिए, और यह रूपांतरण आपके लिए सफल हो सकता है या नहीं। पाठ पढ़ने और लिखने के लिए धाराओं के समकक्ष क्रमशः अमूर्त वर्ग System.IO.TextReader और System.IO.TextWriter हैं। यदि आपके पास पहले से एक स्ट्रीम तैयार है, तो आप पढ़ने के लिए और System.IO.StreamWriter के लिए System.IO.StreamReader classes (जो सीधे TextReader इनहेरिट करता है) का उपयोग कर सकते हैं (जो सीधे TextWriter इनहेरिट करते हैं, इन वर्गों के कंस्ट्रक्टर को स्ट्रीम पास करके और कोडिंग इस तरह से करते हैं। जितनी जरूरत हो। यदि आप स्पष्ट रूप से एन्कोडिंग निर्दिष्ट नहीं करते हैं, तो UTF-8 का उपयोग डिफ़ॉल्ट रूप से किया जाएगा। नीचे कोड का एक उदाहरण है जो UTF-8 से UCS-2 में एक फ़ाइल को परिवर्तित करता है:

 using System; using System.IO; using System.Text; public class FileConverter { const int BufferSize = 8096; public static void Main(string[] args) { if (args.Length != 2) { Console.WriteLine ("Usage: FileConverter <input file> <output file>"); return; } String inputFile = args[0]; String outputFile = args[1]; //  TextReader      using (TextReader input = new StreamReader (new FileStream (inputFile, FileMode.Open), Encoding.UTF8)) { //  TextWriter         using (TextWriter output = new StreamWriter (new FileStream (outputFile, FileMode.Create), Encoding.Unicode)) { //   char[] buffer = new char[BufferSize]; int len; //       while ( (len = input.Read (buffer, 0, BufferSize)) > 0) { output.Write (buffer, 0, len); } } } } } 

ध्यान दें कि यह कोड TextReader और TextWriter का उपयोग करता है जो स्ट्रीम स्वीकार करते हैं। अन्य कन्स्ट्रक्टर ओवरलोड हैं जो इनपुट के रूप में फ़ाइल पथ स्वीकार करते हैं, इसलिए आपको मैन्युअल रूप से एक FileStream खोलने की आवश्यकता नहीं है; मैंने यह केवल एक उदाहरण के रूप में किया। अन्य रचनाकार ओवरलोड हैं जो बफर आकार को भी स्वीकार करते हैं और बीओएम को परिभाषित करने की आवश्यकता है - सामान्य तौर पर, प्रलेखन पर एक नज़र डालें। और अंत में, यदि आप .NET 2.0 और उच्चतर का उपयोग करते हैं, तो यह स्थिर वर्ग System.IO.File को देखने के लिए अच्छा है, जिसमें कई सुविधाजनक तरीके भी शामिल हैं जो आपको एन्कोडिंग के साथ काम करने की अनुमति देते हैं।

मुश्किल क्षण

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

संस्कृति पर निर्भर खोज, छंटाई और इतने पर।

इन मुद्दों को .NET ( मूल , अनुवाद ) में स्ट्रिंग्स पर मेरे लेख में वर्णित किया गया है।

सरोगेट जोड़े

अब जबकि यूनिकोड में 65536 से अधिक वर्ण हैं, यह उन सभी को 2 बाइट में समायोजित नहीं कर सकता है। इसका मतलब यह है कि Char संरचना का एक भी उदाहरण सभी संभावित पात्रों को स्वीकार नहीं कर सकता है। UTF-16 (और .NET) सरोगेट जोड़े का उपयोग करके इस समस्या को हल करता है - ये दो 16-बिट मान हैं, जहां प्रत्येक मान 0xD800 से 0xDFFF तक होता है। दूसरे शब्दों में, दो "प्रकार के प्रतीक" एक "वास्तविक" प्रतीक बनाते हैं। (UCS-4 और UTF-32 पूरी तरह से इस समस्या को हल करते हैं कि उनके पास व्यापक मान उपलब्ध है: प्रत्येक वर्ण में 4 बाइट्स होते हैं, और यह सभी के लिए पर्याप्त है।) सरोगेट जोड़े एक सिरदर्द हैं, क्योंकि इसका मतलब है कि स्ट्रिंग। , जिसमें 10 वर्ण होते हैं, वास्तव में "वास्तविक" यूनिकोड वर्णों के 10 से 5 समावेशी हो सकते हैं। सौभाग्य से, अधिकांश एप्लिकेशन वैज्ञानिक या गणितीय नोटेशन और खान प्रतीकों का उपयोग नहीं करते हैं, और इसलिए आपको इसके बारे में ज्यादा चिंता करने की आवश्यकता नहीं है।

संशोधक वर्ण

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

मानकीकरण

आंशिक रूप से पात्रों को संशोधित करने जैसी चीजों के कारण, एक अर्थ में, एक ही चरित्र को दर्शाने के कई तरीके हो सकते हैं। एक उच्चारण के साथ अक्षर "á", उदाहरण के लिए, एक चिह्न "एक" बिना किसी उच्चारण के और उच्चारण के संशोधक चरित्र के द्वारा दर्शाया जा सकता है, और केवल एक प्रतीक द्वारा प्रतिनिधित्व किया जा सकता है समाप्त लहजे के साथ "अक्षर" का प्रतिनिधित्व। जहाँ भी संभव हो वर्णों का उपयोग करने के लिए वर्ण अनुक्रम को सामान्य किया जा सकता है, या इसके विपरीत - जहाँ भी उन्हें एकल वर्ण से प्रतिस्थापित किया जा सकता है, उनका उपयोग नहीं करना। क्या आपके आवेदन को एक उच्चारण के साथ "á" अक्षर वाली दो पंक्तियों पर विचार करना चाहिए, लेकिन एक में दो वर्णों का प्रतिनिधित्व होता है, और दूसरे में, समान या अलग के रूप में? छँटाई के बारे में क्या? क्या आपके द्वारा उपयोग किए जाने वाले तृतीय-पक्ष घटक और लाइब्रेरी स्ट्रिंग्स के सामान्यीकरण का उत्पादन करते हैं, और सामान्य तौर पर, ऐसी बारीकियों को ध्यान में रखते हैं? आप इन सवालों के जवाब दीजिए।

डिबगिंग यूनिकोड मुद्दे

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

चरण 1: यूनिकोड मूल बातें समझें

सीधे शब्दों में, लेख का मुख्य पाठ पढ़ें। आप लेख की शुरुआत में दिए गए लिंक पर भी ध्यान दे सकते हैं। तथ्य यह है कि बुनियादी ज्ञान के बिना आप तना हुआ होगा।

चरण 2: यह निर्धारित करने का प्रयास करें कि कौन से रूपांतरण हो सकते हैं

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

चरण 3: प्रत्येक चरण में डेटा की जाँच करें

पहला नियम: किसी भी चीज़ पर भरोसा नहीं करना चाहिए जो चरित्र डेटा को ग्लिफ़ के अनुक्रम (यानी मानक चरित्र चिह्न) के रूप में लॉग करता है। इसके बजाय, आपको बाइट्स में वर्ण कोड के एक सेट के रूप में डेटा लॉग करना चाहिए। उदाहरण के लिए, यदि मेरे पास "हैलो" शब्द वाली एक पंक्ति है, तो मैं इसे "0068 0065 006C 006C 006F" के रूप में प्रदर्शित करूंगा। (हेक्साडेसिमल कोड का उपयोग करने से आप आसानी से कोड तालिकाओं के खिलाफ एक चरित्र की जांच कर सकेंगे।) ऐसा करने के लिए, आपको स्ट्रिंग में सभी वर्णों से गुजरने और प्रत्येक वर्ण के लिए अपना कोड प्रदर्शित करने की आवश्यकता है, जो नीचे दी गई विधि में किया गया है, जो कंसोल में परिणाम प्रदर्शित करता है:

 static void DumpString (string value) { foreach (char c in value) { Console.Write("{0:x4} ", (int)c); } Console.WriteLine(); } 

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

मेरे विचार का सार एनकोडिंग, फोंट आदि के साथ सभी प्रकार की समस्याओं से छुटकारा पाना है। विशिष्ट यूनिकोड वर्णों के साथ काम करते समय यह तकनीक उपयोगी हो सकती है।यदि आप सही ASCII पाठ के हेक्साडेसिमल कोड को सही ढंग से लॉग नहीं कर सकते हैं, तो आपको बड़ी समस्याएँ हैं।

अगला कदम यह सुनिश्चित करना है कि आपके पास एक परीक्षण मामला है जिसे आप उपयोग कर सकते हैं। अधिमानतः स्रोत डेटा का एक छोटा सेट खोजें, जिस पर आपका एप्लिकेशन "विफल" होने की गारंटी है, सुनिश्चित करें कि आपको पता है कि सही परिणाम क्या होना चाहिए, और सभी समस्या क्षेत्रों में परिणामी परिणाम का प्रतिज्ञा करें।

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

निष्कर्ष

जैसा कि सॉफ्टवेयर विकास में उत्पन्न होने वाली त्रुटियों के विशाल बहुमत के साथ, पाठ के साथ समस्याओं को सार्वभौमिक "विभाजित और जीत" रणनीति का उपयोग करके हल किया जाता है। एक बार जब आप हर कदम पर आश्वस्त हो जाते हैं, तो आप सामान्य रूप से आश्वस्त हो सकते हैं। यदि ऐसी त्रुटियों के सुधार के दौरान आप विशेष रूप से समझ से बाहर हैं और उनमें से अजीब अभिव्यक्तियाँ हैं, तो मैं दृढ़ता से सलाह देता हूं कि उन्हें सुधारने के बाद, यूनिट के परीक्षणों के साथ कोड के इस भाग को कवर करें; वे भविष्य में होने वाली रजिस्ट्रियों के खिलाफ क्या हो सकता है और संरक्षण के दोनों दस्तावेज के रूप में काम करेंगे।

सूत्रों का कहना है

• जॉन स्कीट यूनिकोड और .NET
• जॉन स्कीट डिबगिंग यूनिकोड समस्याएं