दृश्य C ++ में यूनिकोड वर्णों के लिए printf फ़ंक्शन प्रारूप निर्दिष्ट करने का दुखद भाग्य

विंडोज पर यूनिकोड का समर्थन अन्य ऑपरेटिंग सिस्टमों की तुलना में पहले दिखाई दिया। इस वजह से, विंडोज में वर्णों के प्रतिनिधित्व से जुड़ी कई समस्याएं उसी तरह से हल नहीं हुईं जैसे कि अन्य प्रणालियों में जिनके डेवलपर्स ने नए मानक के कार्यान्वयन को बेहतर समय तक स्थगित कर दिया [1]। सबसे अधिक उदाहरण: विंडोज पर, यूसीएस -2 एन्कोडिंग का उपयोग यूनिकोड वर्णों का प्रतिनिधित्व करने के लिए किया जाता है। यह यूनिकोड कंसोर्टियम द्वारा अनुशंसित किया गया था, क्योंकि संस्करण 1.0 ने केवल 65,536 वर्णों [2] का समर्थन किया था। पांच साल बाद, कंसोर्टियम ने अपना विचार बदल दिया, लेकिन तब तक विंडोज में कुछ बदलने में बहुत देर हो चुकी थी, क्योंकि Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 और Windows 95 पहले ही बाजार में जारी हो चुके थे - वे सभी BCS एन्कोडिंग का इस्तेमाल करते थे। -2 [३]।

लेकिन आज हम प्रिंटफ फ़ंक्शन के प्रारूप स्ट्रिंग के बारे में बात करेंगे।

चूंकि यूनिकोड को C से पहले विंडोज पर अपनाया गया था, इसका मतलब यह था कि Microsoft डेवलपर्स को यह पता लगाना था कि C रनटाइम में इस मानक के लिए समर्थन कैसे लागू किया जाए। परिणामस्वरूप, wcscmp , wcschr और wprintf जैसी सुविधाएँ दिखाई दीं । प्रिन्टिंग में स्ट्रिंग्स को फॉर्मेट करने के लिए, निम्न क्वालिफायर उनके लिए पेश किए गए थे:

• % s प्रारूप स्ट्रिंग के समान चौड़ाई की स्ट्रिंग का प्रतिनिधित्व करता है;
• % S प्रारूप स्ट्रिंग की चौड़ाई के विपरीत चौड़ाई के साथ एक स्ट्रिंग का प्रतिनिधित्व करता है;
• % hs प्रारूप स्ट्रिंग की चौड़ाई की परवाह किए बिना एक नियमित स्ट्रिंग का प्रतिनिधित्व करता है;
• % ws और % ls प्रारूप स्ट्रिंग की चौड़ाई की परवाह किए बिना एक विस्तृत स्ट्रिंग का प्रतिनिधित्व करते हैं।

इस तरह कोड लिखने का विचार था:

TCHAR buffer[256]; GetSomeString(buffer, 256); _tprintf(TEXT("The string is %s.\n"), buffer); 

और एएनएसआई मोड में संकलन करते समय, यह परिणाम प्राप्त करें:

 char buffer[256]; GetSomeStringA(buffer, 256); printf("The string is %s.\n", buffer); 

और यूनिकोड मोड में संकलन करते समय - यह [4]:

 wchar_t buffer[256]; GetSomeStringW(buffer, 256); wprintf(L"The string is %s.\n", buffer); 

चूँकि % s निर्दिष्ट प्रारूप स्ट्रिंग के समान चौड़ाई की एक स्ट्रिंग को स्वीकार करता है, यह कोड ANSI और यूनीकोड ​​दोनों स्वरूपों में सही ढंग से काम करेगा। साथ ही, यह समाधान ANSI प्रारूप से यूनिकोड प्रारूप में पहले से लिखे गए कोड के रूपांतरण को बहुत सरल करता है, क्योंकि % s स्पेसियर के लिए आवश्यक चौड़ाई के स्ट्रिंग को प्रतिस्थापित किया जाता है।

जब यूनिकोड समर्थन को आधिकारिक तौर पर C99 में जोड़ा गया था, C भाषा मानकीकरण समिति ने प्रिंटफ फ़ंक्शन के लिए एक अलग प्रारूप स्ट्रिंग मॉडल अपनाया:

• % s और % hs एक नियमित स्ट्रिंग का प्रतिनिधित्व करते हैं;
• % ls एक विस्तृत स्ट्रिंग का प्रतिनिधित्व करता है।

यहीं से समस्याएं शुरू हुईं। उस समय तक पिछले छह वर्षों में, विंडोज के लिए अरबों लाइनों की मात्रा वाले कार्यक्रमों की एक बड़ी संख्या लिखी गई थी, और उन्होंने पुराने प्रारूप का उपयोग किया था। विजुअल C और C ++ कंपाइलर कैसे बनें?

यह पुराने, गैर-मानक मॉडल पर रहने का निर्णय लिया गया था, ताकि दुनिया के सभी मौजूदा विंडोज कार्यक्रमों को न तोड़ा जा सके।

यदि आप चाहते हैं कि आपका कोड रनटाइम वातावरण में काम करे, जो प्रिंटफ़ के लिए शास्त्रीय नियमों का पालन करता है और जो सी मानक के नियमों का पालन करते हैं, तो आपको अपने आप को नियमित स्ट्रिंग्स के लिए % hs के लिए सीमित करना होगा और विस्तृत विवरण के लिए % ls । इस मामले में, परिणामों की स्थिरता की गारंटी है, चाहे प्रारूप स्ट्रिंग स्प्रिंटफ या wsprintf फ़ंक्शन को पारित किया गया हो।

 #ifdef UNICODE #define TSTRINGWIDTH TEXT("l") #else #define TSTRINGWIDTH TEXT("h") #endif TCHAR buffer[256]; GetSomeString(buffer, 256); _tprintf(TEXT("The string is %") TSTRINGWIDTH TEXT("s\n"), buffer); char buffer[256]; GetSomeStringA(buffer, 256); printf("The string is %hs\n", buffer); wchar_t buffer[256]; GetSomeStringW(buffer, 256); wprintf("The string is %ls\n", buffer); 

एक अलग TSTRINGWIDTH परिभाषा आपको लिखने की अनुमति देती है, उदाहरण के लिए, यह कोड:

 _tprintf(TEXT("The string is %10") TSTRINGWIDTH TEXT("s\n"), buffer); 

चूंकि लोगों को जानकारी की सारणीबद्ध प्रस्तुति पसंद है, इसलिए यहां आपके लिए एक तालिका है।

मैंने क्वालीफायर के साथ लाइनों को हाइलाइट किया, जिसे सी में उसी तरह परिभाषित किया गया है जैसे कि विंडोज [5] में अपनाया गया है। यदि आप चाहते हैं कि आपका कोड दोनों प्रारूपों में समान परिणाम उत्पन्न करे तो इन क्वालीफायर का उपयोग करें।

नोट

[१] ऐसा प्रतीत होता है कि अन्य प्रणालियों से पहले विंडोज में यूनिकोड की शुरूआत ने माइक्रोसॉफ्ट को पहली चाल का लाभ दिया होगा, लेकिन - कम से कम यूनिकोड के मामले में - यह उनके लिए "अग्रणी का अभिशाप" में बदल गया, क्योंकि बाकी ने बेहतर समय तक इंतजार करने का फैसला किया, जब अधिक आशाजनक समाधान होंगे (जैसे कि UTF-8 एन्कोडिंग), और उसके बाद ही उनके सिस्टम में यूनिकोड का परिचय दें।

[२] स्पष्ट रूप से, उनका मानना ​​था कि ६५,५३६ वर्ण सभी के लिए पर्याप्त होने चाहिए ।

[३] बाद में इसे UTF-16 द्वारा बदल दिया गया। सौभाग्य से, यूटीएफ -16 उन कोड पात्रों के लिए यूसीएस -2 के साथ पिछड़ा हुआ है, जिन्हें दोनों एन्कोडिंग में दर्शाया जा सकता है।

[४] औपचारिक रूप से, यूनिकोड संस्करण को इस तरह दिखना चाहिए:

 unsigned short buffer[256]; GetSomeStringW(buffer, 256); wprintf(L"The string is %s.\n", buffer); 

तथ्य यह है कि wchar_t अभी तक एक स्वतंत्र प्रकार नहीं था, और जब तक इसे मानक में नहीं जोड़ा गया, तब तक यह अहस्ताक्षरित लघु का एक पर्याय था। भाग्य wchar_t के मोड़ और मोड़ एक अलग लेख में पाए जा सकते हैं।

[५] विंडोज द्वारा विकसित क्लासिक प्रारूप पहले दिखाई दिया, इसलिए यह अधिक संभावना थी कि सी मानक को इसके अनुकूल होना था, न कि इसके विपरीत।

अनुवादक का नोट

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