मुझे पता है कि यह परंपरागत है, लेकिन क्यों? क्या वास्तविक तकनीकी कारण हैं कि कोई अन्य तरीका वास्तव में बुरा विचार क्यों होगा या यह केवल एन्कोडिंग और पिछड़ा संगतता के इतिहास पर आधारित है? इसके अलावा, UTF-8 का उपयोग न करने के खतरे क्या हैं, लेकिन कुछ अन्य एन्कोडिंग (सबसे विशेष रूप से, UTF-16)?यूनिक्स/लिनक्स पर्यावरण के साथ बातचीत करते समय यूटीएफ -8 एन्कोडिंग का उपयोग क्यों किया जाता है?
संपादित करें: बातचीत करके, मेरा ज्यादातर अर्थ shell और libc है।
आंशिक रूप से क्योंकि फाइल सिस्टम एनयूएल ('0') बाइट्स को फाइल नामों को समाप्त करने की अपेक्षा करते हैं, इसलिए यूटीएफ -16 अच्छी तरह से काम नहीं करेगा। उस परिवर्तन को करने के लिए आपको बहुत सारे कोड को संशोधित करना होगा।
मेरा मानना है कि यह मुख्य रूप से पीछे की संगतता है जो यूटीएफ 8 एएससीआईआई के साथ देता है।
'खतरे' प्रश्न के उत्तर के लिए, आपको यह निर्दिष्ट करना होगा कि आप 'इंटरैक्टिंग' से क्या मतलब रखते हैं। क्या आपका मतलब है कि शैल के साथ, libc के साथ, या कर्नेल के साथ उचित बातचीत?
हां, यह संगतता कारणों के लिए है। यूटीएफ -8 एएससीआईआईआई के साथ पिछड़ा कंपटेबल है। लिनक्स/यूनिक्स एएससीआईआई आधारित थे, इसलिए यह सिर्फ बनाया/समझ में आता है।
मैंने सोचा कि 7-बिट ASCII ठीक था।
गंभीरता से, यूनिकोड अपेक्षाकृत चीजों की योजना में नया है, और UTF-8 पिछड़े ASCII साथ संगत है और बाद से यह कोड बिंदु (चरित्र) के अनुसार 1 से 4 बाइट्स का उपयोग करता है कम जगह (आधा) ठेठ फ़ाइलों के लिए उपयोग करता है, जबकि UTF-16 का उपयोग करता है या तो 2 या 4 बाइट प्रति कोड बिंदु (चरित्र)।
यूटीएफ -16 सरल चौड़ाई के कारण आंतरिक प्रोग्राम उपयोग के लिए बेहतर है। इसके पूर्ववर्ती यूसीएस -2 प्रत्येक कोड बिंदु के लिए बिल्कुल 2 बाइट थे।
को गलत समझता हूं मुझे नहीं लगता कि चौड़ाई बहुत सरल है। आपको अभी भी पूरी स्ट्रिंग स्कैन करना होगा। यदि आप बहुत से सीजेके टेक्स्ट से निपट रहे हैं, तो यूटीएफ -16 वास्तव में यूटीएफ -8 की तुलना में अधिक कॉम्पैक्ट हो सकता है और उस कारण से उपयोग करने योग्य हो सकता है, अन्यथा मैं हर जगह यूटीएफ -8 के साथ रहूंगा। –
दाएं, यूटीएफ -16 ने यूसीएस -2 के बड़े फायदे खो दिए हैं। –
(यूटीएफ -16 ने यूसीएस -2 के बड़े फायदे खो दिए हैं) ... लेकिन यूनिकोड पात्रों की पूरी श्रृंखला प्राप्त की। – tzot
आधुनिक यूनिक्स यूटीएफ -8 का उपयोग करते हैं, लेकिन यह हमेशा सत्य नहीं था। आरएचईएल 2 पर - जो केवल कुछ साल पुराना है - डिफ़ॉल्ट
$ locale LANG=C LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=सी/पॉज़िक्स लोकेल 7-बिट ASCII- संगत एन्कोडिंग होने की उम्मीद है।
हालांकि, जैसा कि जोनाथन लेफ्लर ने कहा था, किसी भी एन्कोडिंग जो एक वर्ण अनुक्रम के भीतर एनयूएल बाइट्स की अनुमति देता है, यूनिक्स पर अनावश्यक है, क्योंकि सिस्टम एपीआई लोकेल-अज्ञानी हैं; तारों को सभी बाइट अनुक्रमों को \ 0 द्वारा समाप्त किया जाता है।
यह एएससीआईआई-संगत एन्कोडिंग नहीं होना चाहिए, लेकिन पीओएसईक्स मानक कहता है "सभी बिट्स शून्य के साथ एक बाइट को शिफ्ट स्थिति से मुक्त शून्य चरित्र के रूप में व्याख्या किया जाएगा। इस प्रकार सभी बिट्स शून्य के साथ बाइट कभी नहीं होगा एक चरित्र के दूसरे या बाद के बाइट्स। " इसका मतलब है कि यूटीएफ -16 और यूटीएफ -32 की अनुमति नहीं है, लेकिन यूटीएफ -8 है। – dan04
मुझे लगता है कि ऐसा इसलिए है क्योंकि एएससीआईआई इनपुट की अपेक्षा रखने वाले प्रोग्राम यूटीएफ -16 जैसे एन्कोडिंग को संभालने में सक्षम नहीं होंगे। अधिकांश पात्रों (0-255 रेंज में) के लिए, उन कार्यक्रमों को उच्च बाइट को एनयूएल/0 चार के रूप में देखा जाएगा, जो स्ट्रिंग के अंत को चिह्नित करने के लिए कई भाषाओं और प्रणालियों में उपयोग किया जाता है। यह यूटीएफ -8 में नहीं होता है, जिसे एम्बेडेड एनयूएल से बचने और बाइट-ऑर्डर अज्ञेयवादी होने के लिए डिज़ाइन किया गया था।
जोनाथन-लेफ्लर का उल्लेख है, मुख्य मुद्दा ASCII शून्य चरित्र है। सी पारंपरिक रूप से एक स्ट्रिंग को समाप्त करने की अपेक्षा करता है। तो मानक सी स्ट्रिंग फ़ंक्शंस किसी भी यूटीएफ -16 चरित्र पर चक्कर लगाएंगे जिसमें एएससीआईआई नल (0x00) के बराबर बाइट होता है। जबकि आप निश्चित रूप से विस्तृत चरित्र समर्थन के साथ प्रोग्राम कर सकते हैं, यूटीएफ -16 filenames, text files, environment variables में यूनिकोड का उपयुक्त बाह्य एन्कोडिंग नहीं है।
इसके अलावा, यूटीएफ -16 और यूटीएफ -32 दोनों में बड़े एंडियन और छोटे एंडियन उन्मुखताएं हैं। इससे निपटने के लिए, आपको या तो एमआईएमई प्रकार, या Byte Orientation Mark जैसे बाहरी मेटाडेटा की आवश्यकता होगी।यह नोट,
कहाँ UTF-8 8 बिट के वातावरण में पारदर्शी रूप से प्रयोग किया जाता है, एक बीओएम के उपयोग, इस तरह के किसी भी प्रोटोकॉल या फ़ाइल स्वरूप शुरुआत में विशिष्ट ASCII वर्ण की उम्मीद के साथ हस्तक्षेप करेगा "#!" के उपयोग के रूप में यूनिक्स शैल स्क्रिप्ट की शुरुआत पर।
पूर्ववर्ती UTF-16 के लिए है, जो यूसीएस -2 कहा जाता था और किराए की जोड़े का समर्थन नहीं किया, same issues था। यूसीएस -2 से बचा जाना चाहिए।
मेरा मानना है कि जब माइक्रोसॉफ्ट ने दो बाइट एन्कोडिंग का उपयोग करना शुरू किया था, तो 0xffff से ऊपर वर्ण असाइन नहीं किए गए थे, इसलिए दो बाइट एन्कोडिंग का उपयोग करना था कि किसी को भी अलग-अलग लंबाई के बारे में चिंता करने की ज़रूरत नहीं थी।
अब इस श्रेणी के बाहर के पात्र हैं, इसलिए आपको अलग-अलग लंबाई के पात्रों से निपटना होगा, कोई भी यूटीएफ -16 का उपयोग क्यों करेगा? मुझे संदेह है कि माइक्रोसॉफ्ट एक अलग निर्णय लेगा अगर वे आज अपने यूनिकोड समर्थन को कम कर रहे थे।
एनटी डिजाइन किए जाने पर यूटीएफ -8 अस्तित्व में नहीं था। –
विंडोज ने पूरे विंडोज एपीआई का डुप्लिकेट संस्करण बनाकर यूटीएफ -16 के लिए समर्थन जोड़ा। यूटीएफ -8 के लिए समर्थन जोड़ना बहुत आसान था। – dan04
असल में विंडोज ने ऐसा करने के द्वारा 'यूसीएस -2' के लिए समर्थन जोड़ा, और फिर यह "640k फिर से" था जब यह निकला कि 16 बिट पर्याप्त नहीं थे ... ;-) –
@ dan04 यह मुश्किल होगा यूसीएस 2 के बजाय यूटीएफ -8 का उपयोग करके एनटी लिखें, एनटी पूर्व-दिनांक यूटीएफ -8। उसमें असाधारण दूरदर्शिता की आवश्यकता होगी। –