2011-01-15 10 views
7

मुझे पता है कि वेब हाल ही में यूटीएफ -8 की तरफ मानकीकृत है और मैं बस सोच रहा था कि यूटीएफ -8 का उपयोग करने वाली कोई जगह खराब जगह होगी। मैंने तर्क सुना है कि यूटीएफ -8, 16, आदि अधिक जगह का उपयोग कर सकते हैं लेकिन अंत में यह नगण्य रहा है।क्या सब कुछ के लिए यूटीएफ -8, 16, आदि का उपयोग नहीं करने का कोई कारण है?

इसके अलावा, विंडोज प्रोग्राम, लिनक्स खोल और उस प्रकृति की चीजों के बारे में क्या - क्या आप सुरक्षित रूप से यूटीएफ -8 का उपयोग कर सकते हैं?

+0

यूटीएफ -8 का समर्थन नहीं करने वाले मौजूदा प्रोटोकॉल के लिए, यह यूटीएफ -8 का उपयोग न करने का एक अच्छा कारण है :) मैं व्यक्तिगत रूप से केवल यूटीएफ -8 एन्कोडिंग का समर्थन करना चाहता हूं क्योंकि यह मेरे जीवन को चारों ओर घूमने की अनुमति देते हुए यूनिकोड वर्णों की अनुमति देता है एएससीआईआई चरित्र-स्थान (एक "गूंगा" संपादक में यूटीएफ -16 सामग्री खोलने से मुझे आंखें खून बहती हैं)। –

+0

@pst: बी ई सी ए यू एस आई आई टी ओ ओ एस एस एल आई के ई टी एच आई एस? – dan04

उत्तर

1

यदि यूटीएफ -32 उपलब्ध है, तो प्रसंस्करण के लिए अन्य संस्करणों पर इसे प्राथमिकता दें।

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

बेशक

, यदि आप एक बहुत प्रतिबंधित परिवेश में की तरह, कहते हैं, एम्बेडेड सिस्टम प्रोग्रामिंग कर रहे हैं और कुछ हो सकता है वहाँ, केवल ASCII या आईएसओ के आसपास 8859-x वर्ण हो जाएगा कभी, तो आप के लिए उन वर्णसेट चुना कर सकते हैं दक्षता और गति। लेकिन सामान्य रूप से, यूनिकोड परिवर्तन प्रारूप के साथ चिपके रहें।

+2

यूटीएफ -32 उसी डेटा के लिए एएससीआईआई (या यूटीएफ -8 एन्कोडिंग करते समय यूटीएफ -8) की 4x जगह लेता है। यह निश्चित रूप से मायने रखता है। इसके अलावा, आईएसओ -885 9-* (और यूटीएफ -8 के विपरीत) "विरासत" वर्णमाला के विपरीत, आपके पास यूटीएफ -32 और यूटीएफ -16 के साथ बाइट-ऑर्डर एंडियननेस समस्याएं हैं। – dkarp

+0

["यूटीएफ -32 (या यूसीएस -4) यूनिकोड वर्णों को एन्कोड करने के लिए एक प्रोटोकॉल है जो प्रत्येक यूनिकोड कोड बिंदु के लिए बिल्कुल 32 बिट्स का उपयोग करता है। अन्य सभी यूनिकोड रूपांतरण प्रारूप चर-लंबाई एन्कोडिंग का उपयोग करते हैं। एक चरित्र का यूटीएफ -32 रूप है इसके कोडपॉइंट का प्रत्यक्ष प्रतिनिधित्व। "] (http://en.wikipedia.org/wiki/UTF-32/UCS-4) – dkarp

+0

@dkarp बस दो बार चेक किया गया और आप सही हैं। मेरा बुरा –

0

जब आपको कोई प्रोग्राम लिखना होगा (स्ट्रिंग मैनिप्लेशंस करना) जो बहुत तेज़ होने की आवश्यकता है और आपको यकीन है कि आपको विदेशी पात्रों की आवश्यकता नहीं होगी, तो यूटीएफ -8 सबसे अच्छा विचार नहीं हो सकता है। हर दूसरे परिस्थितियों में, यूटीएफ -8 एक मानक होना चाहिए।

यूटीएफ -8 विंडोज पर भी लगभग हर हालिया सॉफ्टवेयर पर अच्छी तरह से काम करता है।

+0

ठीक है, आप * विंडोज़ पर यूटीएफ -8-आधारित सॉफ़्टवेयर लिख सकते हैं (मैंने इसे किया है), लेकिन आपको "fopen' जैसे कार्यों से बचना होगा जो" एएनएसआई "स्ट्रिंग लेते हैं :-( – dan04

+0

क्या? Fopen? में क्या भाषा? क्या मैंने कहा कि विंडोज़ पर सॉफ्टवेयर लिखना असंभव था जो यूटीएफ -8 आधारित है?मैं तुम्हारी बात समझ में नहीं आता। या शायद किसी ने अपनी टिप्पणी हटा दी है। –

0

यह अच्छी तरह से ज्ञात है कि utf-8 फ़ाइल संग्रहण और नेटवर्क परिवहन के लिए सबसे अच्छा काम करता है। लेकिन लोग बहस करते हैं कि प्रसंस्करण के लिए utf-16/32 बेहतर है या नहीं। एक प्रमुख तर्क यह है कि utf-16 अभी भी परिवर्तनीय लंबाई है और यहां तक ​​कि utf-32 प्रति चरित्र एक कोड-पॉइंट नहीं है, तो वे utf-8 से बेहतर कैसे हैं? मेरी राय यह है कि utf-16 एक बहुत अच्छा समझौता है।

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

दूसरा, अक्सर हमें चरित्र गणना से संबंधित स्ट्रिंग मेमोरी आवंटन की आवश्यकता होती है। जैसे 10 अक्षरों के लिए डेटाबेस स्ट्रिंग कॉलम (मान लें कि हम सामान्यीकृत रूप में यूनिकोड स्ट्रिंग स्टोर करते हैं), जो utf-16 के लिए 20 बाइट्स होगा। ज्यादातर मामलों में यह इस तरह काम करेगा, चरम मामलों को छोड़कर इसमें केवल 5-8 वर्ण होंगे। लेकिन यूटीएफ -8 के लिए, पश्चिमी चरित्रों के लिए एक चरित्र की सामान्य बाइट लंबाई 1-3 है और एशिया भाषाओं के लिए 3-5 है। जिसका मतलब है कि हमें आम मामलों के लिए भी 10-50 बाइट की जरूरत है। अधिक डेटा, अधिक प्रसंस्करण।

+0

मैं उन पात्रों के बारे में बहुत ज्यादा चिंता न करें, क्योंकि यदि आप उन्हें ठीक से संभाल नहीं पाते हैं तो वे आपके सॉफ़्टवेयर को खराब नहीं दिखाएंगे "। "मेरा प्रोग्राम यूटीएफ -16 का उपयोग करता है/समर्थन करता है" कहता है, "मेरा प्रोग्राम यूटीएफ -16 के उप-समूह का उपयोग/समर्थन करता है" या तो अपमानजनक या सीधे झूठ है। कीड़े एक बात है; जानबूझकर पूरे यूटीएफ -16 का समर्थन नहीं करना एक बग नहीं है। – Kevin