क्या TCHAR अभी भी प्रासंगिक है?

Question

मैं विंडोज़ प्रोग्रामिंग के लिए नया हूँ और पेटज़ोल्ड पुस्तक पढ़ने के बाद मुझे आश्चर्य होता है:

तार को घोषित करने के लिए TCHARप्रकार और _T()फ़ंक्शन का उपयोग करना अच्छा है या क्या मुझे नए कोड में तार wchar_tऔर L""तार का उपयोग करना चाहिए ?

मैं केवल Windows 2000 और ऊपर लक्षित करूंगा और मेरा कोड स्टार्ट अप से i18n होगा ।

Answer 1

यदि मैं आज एक नई परियोजना कर रहा था, तब भी मैं TCHAR सिंटैक्स का उपयोग करूंगा। इसे और WCHAR सिंटैक्स का उपयोग करने के बीच बहुत व्यावहारिक अंतर नहीं है, और मैं कोड पसंद करता हूं जो स्पष्ट है कि चरित्र प्रकार क्या है। चूंकि अधिकांश एपीआई फ़ंक्शन और हेल्पर ऑब्जेक्ट TCHAR प्रकार (जैसे: CString) का उपयोग / उपयोग करते हैं, यह सिर्फ इसका उपयोग करने के लिए समझ में आता है। यदि आप किसी बिंदु पर ASCII ऐप में कोड का उपयोग करने का निर्णय लेते हैं, या यदि Windows कभी यूनिकोड 32 में विकसित होता है, आदि।

यदि आप WCHAR मार्ग पर जाने का निर्णय लेते हैं, तो मैं इसके बारे में स्पष्ट रहूंगा। अर्थात्, CSTring के बजाय CStringW का उपयोग करें, और TCHAR में कनवर्ट करते समय मैक्रो कास्टिंग (जैसे: CW2CT)।

वैसे भी मेरी राय है।

Comments

वास्तव में, यह तब भी काम करेगा जब चरित्र एन्कोडिंग को अंततः '' फिर से '' बदल दिया जाएगा।

— मेदिनेक

आप उस कोड को पसंद करते हैं जो वर्ण प्रकार में स्पष्ट है, और इस प्रकार एक प्रकार का उपयोग करें जो कभी-कभी यह होता है और कभी-कभी ऐसा होता है? बहुत प्रेरक है।

— Deduplicator

@Deduplicator द्वारा नोट की गई विसंगति के लिए −1 , और एक मैक्रो का उपयोग करने के लिए नकारात्मक अदायगी सलाह के लिए जो कुछ भी हो सकता है (और आमतौर पर एक से अधिक विशिष्ट मूल्य के लिए परीक्षण नहीं किया जाएगा)।

— चीयर्स एंड हीथ। - अल्फ

Answer 2

संक्षिप्त उत्तर: नहीं ।

पहले से ही लिखे गए अन्य सभी की तरह, बहुत सारे प्रोग्रामर अभी भी TCHAR और संबंधित कार्यों का उपयोग करते हैं। मेरी विनम्र राय में पूरी अवधारणा एक बुरा विचार था । UTF-16 स्ट्रिंग प्रसंस्करण सरल ASCII / MBCS स्ट्रिंग प्रसंस्करण से बहुत अलग है। यदि आप दोनों के साथ समान एल्गोरिदम / फ़ंक्शंस का उपयोग करते हैं (यह वही है जो TCHAR विचार पर आधारित है!), तो आप UTF-16 संस्करण पर बहुत खराब प्रदर्शन प्राप्त करते हैं यदि आप साधारण स्ट्रिंग संयोजन की तुलना में थोड़ा अधिक कर रहे हैं (जैसे पार्सिंग आदि)। मुख्य कारण सरोगेट हैं ।

एकमात्र अपवाद के साथ जब आपको वास्तव में एक ऐसी प्रणाली के लिए अपने आवेदन को संकलित करना होता है जो यूनिकोड का समर्थन नहीं करता है तो मुझे इस सामान को नए एप्लिकेशन में अतीत से उपयोग करने का कोई कारण नहीं दिखता है।

Comments

मजेदार तथ्य: UTF-16 हमेशा NT प्लेटफ़ॉर्म पर नहीं था। 1996 में यूनिकोड 2.0 के साथ सरोगेट कोड अंक पेश किए गए, जो उसी वर्ष NT 4 को जारी किया गया था। तक, IIRC, (सहित) Windows 2000 सभी NT संस्करणों ने UCS-2 का उपयोग किया, प्रभावी रूप से UTF-16 का एक सबसेट जो प्रत्येक वर्ण को एक कोड बिंदु (यानी कोई सरोगेट) के साथ प्रतिनिधित्व करने योग्य नहीं मानता था।

— 0xC0000022L

btw, जबकि मैं सहमत हूँ कि TCHARअब और इस्तेमाल नहीं किया जाना चाहिए, मैं असहमत हूँ कि यह एक बुरा विचार था। मुझे यह भी लगता है कि यदि आप उपयोग करने के बजाय स्पष्ट होना चुनते हैं तो आपको हर जगहTCHAR स्पष्ट होना चाहिए । I के साथ कार्यों का उपयोग नहीं करते /TCHAR_TCHAR_tmain घोषणा में (जैसे ) के हैं। सीधे शब्दों में कहें: सुसंगत हो। +1, अभी भी।

— 0xC0000022L

इसे शुरू करते समय यह एक अच्छा विचार था, लेकिन नए कोड में यह अप्रासंगिक होना चाहिए।

— एड्रियन मैक्कार्थी

आप गलत जानकारी देते हैं कि TCHARशुरू में किसके लिए पेश किया गया था: विन 9x और विंडोज के विंडोज एनटी आधारित संस्करणों के लिए कोड के विकास को आसान बनाने के लिए। उस समय, Windows NT का UTF-16 कार्यान्वयन UCS-2 था, और स्ट्रिंग पार्सिंग / हेरफेर के लिए एल्गोरिदम समान थे। कोई सरोगेट नहीं थे। और सरोगेट्स के साथ भी, DBCS के लिए एल्गोरिदम (विंडोज के लिए केवल समर्थित MBCS एन्कोडिंग) और UTF-16 समान हैं: एन्कोडिंग में, एक कोड बिंदु में एक या दो कोड इकाइयां होती हैं।

— IInspectable

मान लीजिए कि मैं WSAGetLastError () से मान को किसी मुद्रण योग्य में बदलने के लिए FormatMessage () का उपयोग करना चाहता हूं। WSAGetLastError () के लिए दस्तावेज़ीकरण कहता है कि यह LPTSTR को सूचक के रूप में बफर में ले जाता है। मेरे पास TCHAR का उपयोग करने के लिए वास्तव में ज्यादा विकल्प नहीं हैं, नहीं?

— एडवर्ड फॉक

Answer 3

मुझे साचा से सहमत होना होगा। TCHAR/ _T()/ आदि का अंतर्निहित आधार यह है कि आप "ANSI"-आधारित एप्लिकेशन लिख सकते हैं और फिर जादुई रूप से मैक्रो को परिभाषित करके यूनिकोड समर्थन दे सकते हैं। लेकिन यह कई बुरी धारणाओं पर आधारित है:

कि आप सक्रिय रूप से अपने सॉफ्टवेयर के एमबीसीएस और यूनिकोड दोनों संस्करणों का निर्माण करें

अन्यथा, आप फिसल जाएंगे और char*कई स्थानों पर साधारण तारों का उपयोग करेंगे ।

आप _T ("...") शाब्दिक भाग में गैर- ASCII बैकस्लैश एस्केप का उपयोग नहीं करते हैं

जब तक आपका "ANSI" एन्कोडिंग ISO-8859-1 नहीं होता है, तब तक परिणाम char*और wchar_t*शाब्दिक समान वर्णों का प्रतिनिधित्व नहीं करेंगे।

उस UTF-16 स्ट्रिंग्स का उपयोग "ANSI" स्ट्रिंग्स की तरह ही किया जाता है

वे नहीं हैं। यूनिकोड कई अवधारणाओं का परिचय देता है जो अधिकांश विरासत चरित्र एनकोडिंग में मौजूद नहीं हैं। सरोगेट्स। पात्रों का मेल। सामान्यीकरण। सशर्त और भाषा-संवेदनशील आवरण नियम।

और शायद सबसे महत्वपूर्ण बात यह है कि UTF-16 को डिस्क पर शायद ही कभी सहेजा जाता है या इंटरनेट पर भेजा जाता है: UTF-8 को बाहरी प्रतिनिधित्व के लिए प्राथमिकता दी जाती है।

कि आपका एप्लिकेशन इंटरनेट का उपयोग नहीं करता है

(अब, यह आपके लिए एक मान्य धारणा हो सकती है सॉफ़्टवेयर के , लेकिन ...)

वेब UTF-8 और दुर्लभ एन्कोडिंग के ढेरों पर चलता है । TCHARअवधारणा केवल दो को पहचानता है: "एएनएसआई" (जो नहीं कर सकते UTF-8 होना ) और "यूनिकोड" (UTF-16)। यह आपके विंडोज एपीआई कॉल यूनिकोड-जागरूक बनाने के लिए उपयोगी हो सकता है, लेकिन यह आपके वेब और ई-मेल एप्स यूनिकोड-जागरूक बनाने के लिए बेकार है।

आप गैर-Microsoft पुस्तकालयों का उपयोग करते हैं

कोई और उपयोग नहीं करता TCHAR। पोको का उपयोग करता है std::stringऔर UTF-8। SQLite में इसके API के UTF-8 और UTF-16 संस्करण हैं, लेकिन नहीं TCHAR। TCHARमानक पुस्तकालय में भी नहीं है, इसलिए नहींstd::tcout जब तक आप स्वयं इसे परिभाषित नहीं करना चाहते।

मैं TCHAR के बजाय क्या सलाह देता हूं

भूल जाते हैं कि "एएनएसआई" एन्कोडिंग मौजूद है, सिवाय इसके कि जब आपको एक फाइल पढ़ने की आवश्यकता हो जो मान्य UTF-8 नहीं है। भूल TCHARभी जाओ । हमेशा Windows API फ़ंक्शन के "W" संस्करण को कॉल करें। #define _UNICODEबस यह सुनिश्चित करने के लिए कि आप गलती से "ए" फ़ंक्शन नहीं कहते हैं।

हमेशा स्ट्रिंग्स के लिए UTF एनकोडिंग का उपयोग करें: स्ट्रिंग्स के लिए UTF-8 charऔर स्ट्रिंग्स के लिए UTF-16 (Windows पर) या UTF-32 (यूनिक्स जैसी प्रणालियों पर) wchar_t। typedef UTF16और UTF32मंच के मतभेदों से बचने के लिए चरित्र प्रकार।

Comments

2012 कॉलिंग: अभी भी बिना बनाए रखा जा करने के लिए आवेदन कर रहे #define _UNICODEहैं। संचरण का अंत :)

— 0xC0000022L

@ 0xC0000022L प्रश्न नए कोड के बारे में था । जब आप पुराने कोड को बनाए रखते हैं, तो आपको स्पष्ट रूप से उस पर्यावरण के साथ काम करना होगा जो कोड के लिए लिखा गया है। यदि आप एक COBOL एप्लिकेशन का रखरखाव कर रहे हैं, तो यह मायने नहीं रखता कि COBOL एक अच्छी भाषा है या नहीं, आप इसके साथ फंस गए हैं। और यदि आप एक एप्लिकेशन को बनाए रख रहे हैं जो TCHAR पर निर्भर है तो इससे कोई फर्क नहीं पड़ता कि यह एक अच्छा निर्णय था या नहीं, आप इसके साथ फंस गए हैं।

— jalf

दरअसल, TCHAR तब तक उपयोगी नहीं है जब तक कि COBOL में)

— Pavel Radzivilovsky

_UNICODEयह नियंत्रित करता है कि CRT में जेनरिक-टेक्स्ट मैपिंग को कैसे हल किया जाता है। यदि आप Windows API के ANSI संस्करण को कॉल नहीं करना चाहते हैं, तो आपको परिभाषित करने की आवश्यकता है UNICODE।

— IInspectable

Answer 4

यदि आप सोच रहे हैं कि क्या यह अभी भी चलन में है, तो हाँ - यह अभी भी काफी उपयोग किया जाता है। यदि आप TCHAR और _T ("") का उपयोग करते हैं तो कोई भी आपके कोड को मज़ेदार नहीं लगेगा। अब मैं जिस प्रोजेक्ट पर काम कर रहा हूं वह एएनएसआई से यूनिकोड में परिवर्तित हो रहा है - और हम पोर्टेबल (TCHAR) मार्ग पर जा रहे हैं।

तथापि...

मेरा वोट सभी ANSI / UNICODE पोर्टेबल मैक्रोज़ (TCHAR, _T (""), और सभी _tXXXXXX कॉल, आदि ... और सभी जगह यूनिकोड मानने को भूल जाएगा। मुझे वास्तव में पोर्टेबल होने की बात नहीं दिखती है अगर आपको कभी एएनएसआई संस्करण की आवश्यकता नहीं होगी। मैं सभी विस्तृत चरित्र कार्यों और प्रकारों का सीधे उपयोग करूंगा। एक एल के साथ सभी स्ट्रिंग शाब्दिक रोकें।

Comments

आप कुछ ऐसा कोड लिख सकते हैं, जिसका आप कहीं और उपयोग करना चाहेंगे, जहाँ आपको ANSI संस्करण की आवश्यकता हो, या (जैसा कि निक ने कहा) Windows DCHAR या जो भी हो सकता है, इसलिए मुझे अभी भी लगता है कि इसके बजाय TCHAR के साथ जाना बहुत अच्छा विचार है WCHAR।

— arke

मुझे संदेह है कि विंडोज़ कभी भी यूटीएफ -32 में बदल जाएगा।

— dan04

-1 UTF-16 अनुशंसा के लिए। इतना ही नहीं गैर-पोर्टेबल (विंडोज़-केंद्रित) कोड बनाता है, जो पुस्तकालयों के लिए अस्वीकार्य है - भले ही यूआई कोड जैसे मामलों में सबसे सरल के लिए इस्तेमाल किया जा सकता है - यह विंडोज पर भी कुशल नहीं है। utf8everywhere.org

— पावेल Radzivilovsky

Answer 5

MSDN पर Windows प्रोग्रामिंग आलेख का परिचय कहता है

नए अनुप्रयोगों को हमेशा यूनिकोड संस्करणों (एपीआई के) को कॉल करना चाहिए।

पाठ और TCHAR मैक्रो क्योंकि सभी आवेदनों को यूनिकोड का उपयोग करना चाहिए कम उपयोगी आज कर रहे हैं।

मैं करने के लिए छड़ी होगी wchar_tऔर L""।

Comments

स्टीवन, आप किसी ऐसे व्यक्ति द्वारा लिखित पाठ को उद्धृत कर रहे हैं जो 'यूनिकोड' शब्द का अर्थ नहीं समझता है। यह UCS-2 भ्रम के समय से उन दुर्भाग्यपूर्ण दस्तावेजों में से एक है।

— पावेल रेडविलविलोव्स्की 6

@PavelRadzivilovsky: दस्तावेज़ को एक प्रणाली के लिए लिखा गया था, जहां यूनिकोड और UTF-16LE आमतौर पर एक - दूसरे के लिए उपयोग किए जाते हैं। जबकि तकनीकी रूप से गलत है, फिर भी यह अस्पष्ट है। यह भी स्पष्ट रूप से एक ही पाठ की शुरूआत में बताया गया है: "यूटीएफ -16 एन्कोडिंग का उपयोग करके यूनिकोड वर्णों का प्रतिनिधित्व करता है [...]" ।

— IInspectable

Answer 6

मैं एक अलग दृष्टिकोण (दोनों में से कोई भी) का सुझाव देना चाहूंगा।

संक्षेप में, char * और std :: string का प्रयोग करें, UTF-8 एन्कोडिंग मानते हुए, और API फ़ंक्शन लपेटते समय केवल UTF-16 में रूपांतरण करें।

अधिक जानकारी और विंडोज कार्यक्रमों में इस दृष्टिकोण का औचित्य http://www.utf8everywhere.org में पाया जा सकता है ।

Comments

@PavelRadzivilovsky, वीसी ++ आवेदन में अपने सुझाव को लागू करते समय, क्या हम वीसी ++ चरचर को 'कोई नहीं' या 'मल्टीबाइट (एमबीसीएस)' पर सेट करेंगे? मैं जो कारण पूछ रहा हूं वह यह है कि मैंने बस Boost :: Locale और डिफ़ॉल्ट चरित्र सेट को MBCS स्थापित किया था। एफडब्ल्यूआईडब्ल्यू, मेरा शुद्ध एएससीआईआई अनुप्रयोग 'कोई नहीं' के लिए सेट किया गया था और मैंने अब इसे 'एमबीसीएस' के लिए सेट कर दिया है (क्योंकि मैं इसमें बूस्ट :: लोकेल का उपयोग करूंगा) और यह ठीक काम करता है। कृपया सलाह दें।

— कैरोलीन बेल्टट्रान

जैसा कि utf8everywhere अनुशंसा करता है, मैं इसे 'यूनिकोड वर्ण सेट का उपयोग' करने के लिए सेट करूंगा। यह अतिरिक्त सुरक्षा का विज्ञापन करता है, लेकिन इसकी आवश्यकता नहीं है। बूस्ट :: लोकेल का लेखक बहुत ही स्मार्ट लड़का है, मुझे यकीन है कि उसने सही काम किया है।

— पावेल रेड्ज़विलोवस्की

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

— IInspectable

"..UTF-16 एकमात्र एन्कोडिंग है, जिसे तुरंत किसी भी अन्य समर्थित एन्कोडिंग में परिवर्तित किया जा सकता है।" आपका मतलब क्या है? UTF-8 एन्कोडिंग को किसी और चीज़ में बदलने में क्या समस्या है?

— पावेल रेड्ज़विलोव्स्की 10

मुझे समझ नहीं आता। कुछ और करने के लिए - जैसे क्या? जैसे UCS-4? क्यों नहीं? बहुत आसान लगता है, सभी सांख्यिक एल्गोरिथ्म ..

— पावल रेड्ज़विलोवस्की 18

Answer 7

TCHAR/ WCHARकुछ विरासत परियोजनाओं के लिए पर्याप्त हो सकता है। लेकिन नए अनुप्रयोगों के लिए, मैं कहूंगा कि कोई ।

ये सभी चीजें TCHAR/ WCHARसामान ऐतिहासिक कारणों से हैं। TCHARANSI पाठ एन्कोडिंग (MBCS) और यूनिकोड पाठ एन्कोडिंग (UTF-16) के बीच स्विच करने के लिए एक बहुत साफ तरीका (भेस) प्रदान करता है। अतीत में, लोगों को दुनिया की सभी भाषाओं के पात्रों की संख्या की समझ नहीं थी। उन्होंने मान लिया कि 2 बाइट्स सभी वर्णों का प्रतिनिधित्व करने के लिए पर्याप्त थे और इस प्रकार एक निश्चित लंबाई वाले वर्ण एन्कोडिंग योजना का उपयोग कर रहे थे WCHAR। हालांकि, 1996 में यूनिकोड 2.0 की रिलीज के बाद यह सच नहीं है ।

यह कहना है: कोई बात नहीं जो आप CHAR/ WCHAR/ में उपयोग करते हैं TCHAR, आपके कार्यक्रम में पाठ प्रसंस्करण हिस्सा अंतर्राष्ट्रीयकरण के लिए चर लंबाई के पात्रों को संभालने में सक्षम होना चाहिए ।

आप वास्तव में से एक को चुनने की तुलना में अधिक करने की जरूरत है तो CHAR/ WCHAR/ TCHARWindows में प्रोग्रामिंग के लिए:

1. यदि आपका आवेदन छोटा है और इसमें टेक्स्ट प्रोसेसिंग नहीं है (यानी टेक्स्ट स्ट्रिंग के चारों ओर तर्क के रूप में गुजर रहा है), तो साथ रहें WCHAR । चूंकि यह यूनिकोड समर्थन के साथ WinAPI के साथ काम करने का आसान तरीका है।
2. अन्यथा, मैं यूटीएफ -8 को आंतरिक एन्कोडिंग के रूप में उपयोग करने का सुझाव दूंगा और चार्ट या स्ट्रिंग :: स्ट्रिंग में ग्रंथों को संग्रहीत करूंगा। और WinAPI पर कॉल करते समय उन्हें UTF-16 में कवर करें। UTF-8 अब प्रमुख एन्कोडिंग है और UTF-8 स्ट्रिंग्स को संसाधित करने के लिए बहुत सारे आसान पुस्तकालय और उपकरण हैं।

अधिक गहराई से पढ़ने के लिए इस अद्भुत वेबसाइट की जाँच करें: http://utf8everywhere.org/

Comments

"UTF-8 अब प्रमुख एन्कोडिंग है" - यह उद्धरण के दूसरे भाग ( "वर्ल्ड वाइड वेब के लिए" को छोड़कर) गलत हो गया । डेस्कटॉप अनुप्रयोगों के लिए, सबसे अधिक इस्तेमाल किया जाने वाला देशी वर्ण एन्कोडिंग अभी भी UTF-16 है। विंडोज इसका उपयोग करता है, मैक ओएस एक्स भी करता है, और इसलिए .NET के और जावा के स्ट्रिंग प्रकार भी करते हैं। कोड की एक बड़ी मात्रा के लिए वहाँ खाते हैं । मुझे गलत मत समझिए, क्रमबद्धता के लिए UTF-8 में कुछ भी गलत नहीं है। लेकिन अधिक बार नहीं (विशेष रूप से विंडोज पर), आप पाएंगे कि आंतरिक रूप से UTF-16 का उपयोग करना अधिक उचित है।

— IInspectable

Answer 8

हाँ बिल्कुल; कम से कम _T मैक्रो के लिए। मैं व्यापक चरित्र वाले सामान के बारे में इतना निश्चित नहीं हूँ, हालाँकि।

इसका कारण WinCE या अन्य गैर-मानक विंडोज प्लेटफार्मों का बेहतर समर्थन है। यदि आप 100% निश्चित हैं कि आपका कोड NT पर रहेगा, तो आप शायद नियमित C-string घोषणाओं का उपयोग कर सकते हैं। हालाँकि, यह अधिक लचीले दृष्टिकोण की ओर बढ़ने के लिए सबसे अच्छा है, क्योंकि #define के लिए यह बहुत आसान है कि एक गैर-विंडोज़ प्लेटफ़ॉर्म पर मैक्रो कोड की हजारों लाइनों के माध्यम से जाने की तुलना में और हर जगह इसे जोड़ने के मामले में जहां आपको कुछ लाइब्रेरी पोर्ट करने की आवश्यकता होती है विंडोज़ मोबाइल के लिए।

Comments

WinCE Win32 की तरह ही 16-बिट wchar_t स्ट्रिंग्स का उपयोग करता है। हमारे पास कोड का एक बड़ा आधार है जो WinCE और Win32 पर चलता है और हम कभी TCHAR का उपयोग नहीं करते हैं।

— mhenry1384

Answer 9

IMHO, यदि आपके कोड में TCHAR हैं, तो आप अमूर्त के गलत स्तर पर काम कर रहे हैं।

टेक्स्ट प्रोसेसिंग से निपटने के लिए जो भी स्ट्रिंग प्रकार आपके लिए सबसे सुविधाजनक है उसका उपयोग करें - यह उम्मीद है कि यूनिकोड का समर्थन करने वाला कुछ होगा, लेकिन यह आपके ऊपर है। आवश्यकतानुसार OS API सीमाओं में रूपांतरण करें।

फ़ाइल पथों के साथ काम करते समय, स्ट्रिंग का उपयोग करने के बजाय अपने स्वयं के कस्टम प्रकार को कोड़ा। यह आपको ओएस-स्वतंत्र पथ विभाजक की अनुमति देगा, आपको मैनुअल स्ट्रिंग संघनन और विभाजन के मुकाबले कोड करने के लिए एक आसान इंटरफ़ेस देगा, और विभिन्न ओएस (एएनआई, यूसीएस -2, यूटीएफ -8, जो भी हो) के लिए अनुकूलित करने के लिए बहुत आसान होगा ।

Comments

यूनिकोड में कम से कम तीन वर्तमान एनकोडिंग (UTF-8, UTF-16, UTF-32) और एक डिप्रेस्ड एन्कोडिंग (UCS-2, जो अब UTF-16 है, इसका एक उपसमुच्चय) है। आप किसका उल्लेख करते हैं? मुझे बाकी सुझाव पसंद हैं, हालांकि +1

— 0xC0000022L

Answer 10

एकमात्र कारण जो मैं स्पष्ट WCHAR के अलावा कुछ भी उपयोग करने के लिए देख रहा हूं वह पोर्टेबिलिटी और दक्षता है।

यदि आप अपने अंतिम निष्पादन को यथासंभव छोटा करना चाहते हैं तो चार का उपयोग करें।

यदि आप रैम के उपयोग की परवाह नहीं करते हैं और चाहते हैं कि अंतर्राष्ट्रीयकरण सरल अनुवाद जितना आसान हो, तो WCHAR का उपयोग करें।

यदि आप अपने कोड को लचीला बनाना चाहते हैं, तो TCHAR का उपयोग करें।

यदि आप केवल लैटिन वर्णों का उपयोग करने की योजना बनाते हैं, तो आप ASCII / MBCS तार का उपयोग कर सकते हैं ताकि आपके उपयोगकर्ता को अधिक RAM की आवश्यकता न हो।

"स्टार्ट अप से i18n" वाले लोगों के लिए, अपने आप को स्रोत कोड स्थान बचाएं और सभी यूनिकोड फ़ंक्शन का उपयोग करें।

Answer 11

बस एक पुराने प्रश्न को जोड़ना:

नहीं

VS2010 में एक नया CLR C ++ प्रोजेक्ट शुरू करें। Microsoft स्वयं का उपयोग करते हैं L"Hello World", 'नफ़ ने कहा।

Comments

सीएलआर अप्रबंधित कोड की तुलना में बहुत अलग वातावरण है। यह कोई तर्क नहीं है।

— कोड़ी ग्रे

यहां तक ​​कि Microsoft भी गलतियाँ करता है।

— पावेल रेड्ज़विलोव्स्की

-1 सवाल टैग किया गया है Cऔर C++। उत्तर हमेशा उनके संबंधित लेखकों द्वारा हटाए जा सकते हैं। यह उस प्रावधान का उपयोग करने का एक अच्छा समय होगा।

— IInspectable

Answer 12

TCHARसे पोर्ट करने के लिए एक नया अर्थ WCHARहै CHAR।

https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page

विंडोज़ 10 की हालिया रिलीज़ ने एएनएसआई कोड पेज और -एपीवाई का इस्तेमाल यूटीएफ -8 को ऐप्स को सपोर्ट करने के साधन के रूप में किया है। यदि ANSI कोड पृष्ठ UTF-8 के लिए कॉन्फ़िगर किया गया है, तो UTF-8 में एक API संचालित होता है।