मैं एक पुस्तकालय (pugixml) पर काम कर रहा हूँ कि अन्य बातों के अलावा, फ़ाइल लोड प्रदान करता है/संकीर्ण चरित्र सी तार का उपयोग कर XML दस्तावेज़ों के लिए एपीआई बचाने:क्या सी ++ लाइब्रेरी में फ़ाइल खोलने वाला इंटरफ़ेस विंडोज पर यूटीएफ -8 का उपयोग करना चाहिए?
bool load_file(const char* path);
bool save_file(const char* path);
वर्तमान में पथ fopen को शब्दशः पारित हो जाता है, जिसका मतलब है कि लिनक्स/ओएसएक्स पर आप फ़ाइल खोलने के लिए एक यूटीएफ -8 स्ट्रिंग पास कर सकते हैं (या किसी अन्य बाइट अनुक्रम जो वैध पथ है), लेकिन विंडोज़ पर आपको विंडोज एएनएसआई एन्कोडिंग का उपयोग करना होगा - यूटीएफ -8 काम नहीं करेगा ।
दस्तावेज़ डेटा (डिफ़ॉल्ट रूप से) यूटीएफ -8 का उपयोग करके दर्शाया गया है, इसलिए यदि आपके पास फ़ाइल पथ वाला एक्सएमएल दस्तावेज़ था, तो आप दस्तावेज़ से पुनर्प्राप्त पथ को load_file फ़ंक्शन पर पास नहीं कर पाएंगे - या बल्कि, यह विंडोज पर काम नहीं करेगा।
bool load_file(const wchar_t* path);
लेकिन उनमें wchar_t को UTF8 एन्कोडिंग के लिए अतिरिक्त प्रयास की आवश्यकता है का उपयोग करते हुए: पुस्तकालय विकल्प कार्यों कि wchar_t का उपयोग प्रदान करता है।
एक अलग दृष्टिकोण (जिसका उपयोग एसक्यूलाइट और जीडीएएल द्वारा किया जाता है - यह सुनिश्चित नहीं है कि अन्य सी/सी ++ पुस्तकालय हैं जो ऐसा करते हैं) में पथ पर यूटीएफ -8 के रूप में पथ का इलाज करना शामिल है (जिसे इसे यूटीएफ में परिवर्तित करके कार्यान्वित किया जाएगा -16 और फ़ाइल को खोलने के लिए wchar_t -वेयर समारोह जैसे _wfopen का उपयोग करके)।
ऐसे कई पेशेवर और विपक्ष हैं जिन्हें मैं देख सकता हूं और मुझे यकीन नहीं है कि कौन सा ट्रेडऑफ सर्वोत्तम है।
एक ओर, सभी प्लेटफार्मों पर एक सतत एन्कोडिंग का उपयोग करना निश्चित रूप से अच्छा है। इसका मतलब यह होगा कि आप अन्य XML दस्तावेज़ों को खोलने के लिए XML दस्तावेज़ से निकाले गए फ़ाइल पथ का उपयोग कर सकते हैं। इसके अलावा यदि लाइब्रेरी का उपयोग करने वाला एप्लिकेशन यूटीएफ -8 को गोद लेता है तो पुस्तकालय के माध्यम से एक्सएमएल फाइल खोलते समय इसे अतिरिक्त रूपांतरण नहीं करना पड़ता है।
दूसरी ओर, इसका मतलब है कि फ़ाइल लोडिंग का व्यवहार अब मानक कार्यों के समान नहीं है - इसलिए पुस्तकालय के माध्यम से फ़ाइल का उपयोग मानक fopen/std::fstream के माध्यम से फ़ाइल पहुंच के बराबर नहीं है। ऐसा लगता है कि जबकि कुछ पुस्तकालय यूटीएफ -8 पथ लेते हैं, यह काफी हद तक एक अलोकप्रिय विकल्प है (क्या यह सच है?), इसलिए एक ऐसा एप्लिकेशन दिया गया है जो कई तृतीय पक्ष पुस्तकालयों का उपयोग करता है, इससे डेवलपर्स की मदद करने के बजाय भ्रम पैदा हो सकता है।
उदाहरण के लिए, load_file में argv[1] गुजर वर्तमान में Windows (पर सिस्टम स्थान एन्कोडिंग का उपयोग इनकोडिंग पथ के लिए काम करता है जैसे आप एक रूसी लोकेल आप ऐसा रूसी नाम के साथ किसी भी फाइल लोड कर सकते हैं, लेकिन आप को लोड करने में सक्षम नहीं होगा अगर जापानी पात्रों के साथ फाइलें)। यूटीएफ -8 पर स्विच करने का मतलब यह होगा कि केवल ASCII पथ तब तक काम करते हैं जब तक आप कुछ अन्य विंडोज-विशिष्ट तरीके से कमांड लाइन तर्क प्राप्त नहीं करते।
और निश्चित रूप से यह पुस्तकालय के कुछ उपयोगकर्ताओं के लिए एक तोड़ने वाला परिवर्तन होगा।
क्या मुझे यहां कोई महत्वपूर्ण बिंदु याद आ रहा है? क्या अन्य पुस्तकालय हैं जो एक ही दृष्टिकोण लेते हैं? सी ++ के लिए बेहतर क्या है - फाइल एक्सेस में निरंतर असंगत होना, या वर्दी क्रॉस-प्लेटफ़ॉर्म व्यवहार के लिए प्रयास करना?
ध्यान दें कि सवाल फ़ाइलें खोलने के लिए डिफ़ॉल्ट तरीके के बारे में है - निश्चित रूप से कुछ भी नहीं है मुझे एक और _utf8 प्रत्यय के साथ कार्यों की जोड़ी को जोड़ने या किसी अन्य तरीके से पथ एन्कोडिंग संकेत से रोकता है।
तीन चीजें: (1) क्यों न केवल यूटीएफ -16 में परिवर्तित करें, फिर विंडोज़ पर '_wfopen'/'std :: ifstream (wchar_t *)' का उपयोग करें? परिणामी फ़ाइल ऑब्जेक्ट गैर-'वाचर' कार्यों द्वारा खोले गए जैसा ही है। (2) क्या आपने http://utf8everywhere.org पढ़ा है, और क्या आप इसके साथ सहमत हैं? (3) http://stackoverflow.com/questions/11107608/whats-wrong-with-c-wchar-t-and-wstrings-what-are-ome-alternatives-to-wide देखें। – nneonneo
1) यह बिल्कुल सही है कि दूसरा दृष्टिकोण कैसे काम करेगा 2) मैंने इसे पढ़ा है। मैं मानता हूं कि यूटीएफ -8 आमतौर पर क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन में बेहतर होता है, लेकिन एक लाइब्रेरी अलग हो सकती है - क्या दुनिया एक जैसी सोचती है? :) – zeuxcg
विंडोज़ पर यूटीएफ -8 (और कोई विस्तृत-वर्ण) का उपयोग करने वाली एक अन्य लाइब्रेरी: gtkmm। हालांकि यह अन्य अपराध करता है। – ybungalobill