क्या यूटीएफ -8 (और शायद यूटीएफ -16 / यूटीएफ -32) के अलावा चरित्र एनकोडिंग को हटा दिया जाना चाहिए?

Question

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

उदाहरण के लिए, मुझे PostgreSQL और उसके चरित्र सेट समर्थन पर लेने दें । PostgreSQL दो प्रकार के एनकोडिंग से संबंधित है:

• क्लाइंट एन्कोडिंग: क्लाइंट और सर्वर के बीच संचार में उपयोग किया जाता है।
• सर्वर एन्कोडिंग: पाठ को आंतरिक रूप से डेटाबेस में संग्रहीत करने के लिए उपयोग किया जाता है।

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

UTF-8 एकमात्र मानक, ASCII- संगत वर्ण सेट है जो सभी यूनिकोड कोडपॉइंट्स को एन्कोड कर सकता है (यदि मैं गलत हूं, तो मुझे बताएं)। मैं इस शिविर में हूं कि UTF-8 सबसे अच्छा चरित्र सेट है, लेकिन मैं अन्य सार्वभौमिक चरित्र सेट जैसे UTF-16 और UTF-32 के साथ रखने को तैयार हूं।

मेरा मानना ​​है कि सभी गैर-सार्वभौमिक चरित्र सेटों को हटा दिया जाना चाहिए। वहाँ कोई सम्मोहक कारण वे नहीं होना चाहिए?

Comments

@ उमरियो: UTF-8 की मूल परिभाषा 6 बाइट तक की अनुमति है। बाद में इसे कृत्रिम रूप से केवल उन वर्णों को कवर करने के लिए प्रतिबंधित कर दिया गया जो UTF-16 समर्थन कर सकते थे।

— ०४

कम से कम PostgreSQL जानबूझकर कई चरित्र एन्कोडिंग से संबंधित है। यह बेकार है UTF-8 और windows-1252 के यादृच्छिक मिश्रण से निपटने के लिए क्योंकि किसी को परवाह नहीं थी।

— dan04

@ dan04: रूसी ग्रंथों के साथ काम करना एक दर्द हुआ करता था, क्योंकि वे कई एन्कोडिंग का उपयोग करते थे जो काफी अलग थे और आमतौर पर विभिन्न फोंट का उपयोग करके काम करने के लिए चीजों को हैक करेंगे (जो अक्सर उनके मेटाडेटा में उपयोग किए जाने वाले एन्कोडिंग के बारे में झूठ होगा)। सब सब में, एक भयानक गड़बड़। मुझे संदेह है कि वे हालांकि साफ हो गए हैं - शायद यूटीएफ -8 में जाने से - क्योंकि उस दिशा से समर्थन अनुरोधों की संख्या सही बंद हो गई है।

— डोनल फैलो

सैद्धांतिक यूनिकोड श्रेणी 0 से 0x10ffff तक है। और कुछ नहीं। यही यूनिकोड मानक कहता है। यूटीएफ -8 यूनिकोड के सभी को संभालता है और हमेशा रहेगा। यह एक एन्कोडिंग की काल्पनिक रेंज को कवर नहीं करता है जो यूनिकोड नहीं है, लेकिन यह यूनिकोड के सभी को कवर करता है।

— gnasher729

utf8everywhere.org

— phuclv

Answer 1

चूंकि आपने PostgreSQL का उल्लेख किया है, इसलिए मैं कुछ प्राधिकरण के साथ कह सकता हूं कि मुख्य हत्यारे कारण गैर-यूटीएफ 8 सर्वर-साइड एन्कोडिंग का इतने विस्तार से समर्थन किया जाता है कि जापानी को इसकी आवश्यकता है। स्पष्ट रूप से, यूनिकोड और विभिन्न जापानी "विरासत" एन्कोडिंग के बीच समान गोल-यात्रा रूपांतरण हमेशा संभव नहीं होता है, और कुछ मामलों में विक्रेताओं के बीच रूपांतरण तालिकाएं भी भिन्न होती हैं। यह वास्तव में चौंकाने वाला है, लेकिन यह जाहिरा तौर पर ऐसा है। (व्यापक चरित्र सेट समर्थन भी एक कारण है कि PostgreSQL जापान में इतना लोकप्रिय है।)

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

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

Comments

तो, इन एनकोडिंग्स के कारण, पाठ का UTF-8 और बैक में रूपांतरण सामान्य रूप से नुकसानदेह है? यहां तक ​​कि अगर रूपांतरण वापस तुरंत किया जाता है (बजाय अब से 6 महीने)?

— जॉय एडम्स

जॉय एडम्स: जाहिर है।

— पीटर आइजेंट्राट

Google "हान एकीकरण" के लिए यह देखने के लिए कि क्यों

— पेट्र विक्टोरिन

Answer 2

दो स्पष्ट कारण: आपके द्वारा संग्रहित किए जा रहे डेटा के आधार पर, एक अलग प्रारूप में कनवर्ट करने में काफी समय और अतिरिक्त कमरा लग सकता है। यदि आप 400 मेगाबाइट जानकारी संग्रहीत कर रहे हैं, तो स्टोरेज आवश्यकताओं को दोगुना करना कोई बड़ी बात नहीं है - लेकिन यदि आप 400 टेराबाइट्स का भंडारण कर रहे हैं तो इसका मतलब थोड़ा अधिक है। (कहते हैं) शिफ्ट-जेआईएस को यूटीएफ-एक्स से 400 टेराबाइट डेटा के रूप में अच्छी तरह से थोड़ा समय लग सकता है।

यह विशेष रूप से कठिन हो जाता है यदि आपके पास (उदाहरण के लिए) अपटाइम गारंटी है कि डेटाबेस सभी के लिए उपलब्ध होगा, लेकिन कहते हैं, किसी भी वर्ष में से 10 मिनट हैं, और आपके पास एक डेटाबेस है जिसे एक सेकंड में कई सौ बार अपडेट किया जा रहा है। ध्यान रहे, ऐसी स्थिति में प्रमुख रूपांतरणों का प्रबंधन करना अभी भी संभव है, लेकिन इसे हल्के में लेना कुछ नहीं है। कुछ मामलों में, इस तरह के रूपांतरण के लिए तैयार होने में कई साल लग सकते हैं ।

यदि आप एक डेटाबेस के साथ शुरू कर रहे थे जो (उदाहरण के लिए) केवल ASCII का समर्थन करता था, तो बहस करने का अच्छा कारण हो सकता है कि क्या यह उन सभी एनकोडिंग के लिए समर्थन को जोड़ने के लिए समझ में आता है - लेकिन अगर आप पहले से ही उनका समर्थन करते हैं, तो छोड़ने से कम लाभ होता है उनके लिए समर्थन।

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

कम से कम अगर मैं इसे डिजाइन कर रहा था, तो मैं संभवतः UCS-4 में काम करने के लिए डेटाबेस का कोर लिखूंगा, और फिर कोर और डिस्क के बीच और कोर और उपयोगकर्ता के बीच रूपांतरण रूटीन होगा। मैं दोनों मामलों में रूटीन के एक ही सेट का उपयोग करता हूं, इसलिए सबसे सरल मार्ग डिस्क भंडारण की अनुमति देना होगा जो एन्कोडिंग के बिल्कुल उसी सेट का उपयोग करने की अनुमति देगा जैसा कि ग्राहकों को उपयोग करने की अनुमति थी।

Comments

शिफ्ट-जेआईएस गैर-आत्म-सिंक्रनाइज़िंग है, जो खोज को बोझिल बनाता है। आप इसका समर्थन नहीं करके महत्वपूर्ण सरलीकरण प्राप्त करेंगे ।

— दान ०४

@ dan04: यदि आपके पास Shift-JIS के लिए पहले से ही समय-सिद्ध खोज / अनुक्रमण दिनचर्या है, तो UTF-8 या UCS2 पर स्विच करने से संभवतः प्रदर्शन में सुधार होगा। एक नए डेटाबेस के लिए आप UCS2 या UTF-16 जैसे बेहतर, अधिक सुविधाजनक और नियमित एन्कोडिंग चुन सकते हैं।

— 9000

@ dan04: यदि आप इसे बिल्कुल भी समर्थन नहीं करने के साथ दूर हो सकते हैं, तो आपको काफी लाभ होगा। जब तक आप इसे ग्राहकों से आने / जाने का समर्थन करते हैं, तब तक आप इसकी अधिकांश बदसूरती के साथ फंस जाते हैं ...

— जैरी कॉफ़िन

Answer 3

सर्वर पर केवल UTF-8 को संग्रहीत करने में कुछ समस्याएं हैं:

1. VARCHAR(20)स्तंभ की सीमा क्या है ? क्या वह 20 बाइट्स, या 20 "वर्ण" (और यूनिकोड में, वर्ण, संयुक्ताक्षर आदि खाते में लेते समय क्या "वर्ण" है?)। इससे भी बदतर, CHAR(20)जहां इसके बारे में वास्तव में पूरे संभावित स्थान को आरक्षित करना है: मेरा मानना ​​है कि MySQL में, यह CHAR(20)सबसे खराब स्थिति को संभालने के लिए UTF-8 एन्कोडेड कॉलम (इसलिए 80 बाइट्स ) के लिए 4 गुना बाइट्स की संख्या रखता है ।
2. आपको सर्वर एन्कोडिंग और आपके क्लाइंट एन्कोडिंग के बीच निरंतर एन्कोडिंग रूपांतरण करने की आवश्यकता है। आप यह तर्क दे सकते हैं कि आप कई क्लाइंट एन्कोडिंग का समर्थन करना बंद कर देना चाहते हैं, लेकिन जब तक आप ऐसा नहीं करते हैं, तब सभी तारों को हर समय परिवर्तित करने की आवश्यकता होती है। यदि आप अपने सर्वर एन्कोडिंग और क्लाइंट एन्कोडिंग से मेल कर सकते हैं, तो रूपांतरणों की आवश्यकता नहीं है।
3. जैसा कि दूसरों ने बताया है, UTF-8 अंग्रेजी पाठ को संग्रहीत करने के लिए काफी कुशल है, लेकिन यह विशेष रूप से अन्य भाषाओं - पूर्व एशियाई भाषाओं, के लिए बहुत अक्षम है । आप सूट के रूप में यूटीएफ -16 या यूटीएफ -8 के उपयोग की अनुमति दे सकते हैं, मुझे लगता है। या पाठ संपीड़ित करें, लेकिन यह अनुक्रमण और खोज को अक्षम बनाता है।

यह सब कहने के बाद, मैं आपसे सहमत हूं: विरासत एन्कोडिंग ज्यादातर व्यर्थ हैं और यूनिकोड आमतौर पर सभी नए अनुप्रयोगों के लिए उपयोग करने के लिए सबसे अच्छा एन्कोडिंग है। अगर मैं आज खरोंच से एक डेटाबेस सर्वर लिख रहा था, तो मैं केवल यूनिकोड का समर्थन करूंगा और किसी भी विरासत एन्कोडिंग का समर्थन नहीं करूंगा।

अंतर यह है कि यूनिकोड एक व्यवहार्य विकल्प होने से पहले आज पोस्टग्रेएसक्यूएल और अधिकांश अन्य डेटाबेस सर्वर उपयोग में थे । इसलिए उनके पास पहले से ही विरासत एन्कोडिंग के लिए समर्थन था (वे तब निश्चित रूप से विरासत नहीं थे), और मोटे तौर पर वैचारिक कारणों से उस कोड के सभी को बाहर निकालने के लिए बहुत अधिक बिंदु नहीं है।

Comments

"लेकिन यह अन्य भाषाओं के लिए बहुत ही अक्षम है - विशेष रूप से पूर्व एशियाई भाषाएँ," यहां तक ​​कि व्यवहार में भी? इस चीनी विकिपीडिया पृष्ठ पर विचार करें । हालाँकि, यह पृष्ठ स्रोत में, बहुत सारे चीनी पात्रों को प्रदर्शित करता है, ASCII के पात्रों ने उन्हें लगभग 7: 1 में अभिभूत कर दिया।

— जोए एडम्स

यदि आपके CHAR (N) कॉलम में N एक अच्छी तरह से परिभाषित पहचानकर्ता प्रारूप का हिस्सा है (उदाहरण के लिए, एक VIN को ठीक 17 वर्णों के रूप में परिभाषित किया गया है), तो इसे संभवतः वर्णों या संयुक् तों के संयोजन की आवश्यकता नहीं है। यदि नहीं, तो एन सिर्फ एक मनमानी सीमा है, जिसे ट्रंकटिंग डेटा से बचने के लिए उदारता से व्याख्या की जानी चाहिए।

— ०४

@ जोए एडम्स: यह एचटीएमएल और एक्सएमएल के बारे में सच है जहां मार्कअप स्वयं पाठ का एक बड़ा हिस्सा बनाता है (और यही कारण है कि मुझे लगता है कि यूटीएफ -8 वेब के लिए एक अच्छा विकल्प है), लेकिन एक डेटाबेस में आप अक्सर स्टोर नहीं करते हैं एचटीएमएल। दिन के अंत में, यह केवल दो (या कम) अंतर का एक कारक है, जो वास्तव में इतना अधिक नहीं है।

— डीन हार्डिंग

इस उत्तर में बुलेट बिंदु # 2 अप्रासंगिक है: यह लागू होता है कि क्या यूनिकोड का उपयोग किया जाता है या नहीं। बुलेट बिंदु # 3 पूरी तरह से अक्षमता और इसके दायरे को बढ़ाता है। इसी समय, यह उत्तर विरासती एन्कोडिंग के कारण होने वाली समस्याओं को काफी हद तक समझता है। यह मान लेना आसान है कि समस्या इतनी बड़ी बात नहीं है यदि आप अपने जीवन में कभी भी अंग्रेजी का उपयोग करते हैं।

— तिमवी

@ डीन: मुझे नहीं पता था कि मुझे अपने एक पोस्ट के बिना एक उत्तर पर टिप्पणी करने की अनुमति नहीं थी।

— तिमवी

Answer 4

गैर-सार्वभौमिक (और विशेष रूप से एकल-बाइट) एन्कोडिंग में अपना स्थान होता है: सिस्टम पर जो:

• यूनिकोड कैरेक्टर डेटाबेस को स्टोर करने के लिए पर्याप्त मेमोरी नहीं है।
• ROM में हार्ड-कोडित एक सिंगल-बाइट फ़ॉन्ट है।
• अलग-अलग एन्कोडेड फ़ाइलों का एक स्रोत प्रदान करने के लिए कोई इंटरनेट एक्सेस नहीं है।

यह कुछ प्रकार के एम्बेडेड उपकरणों के लिए आज सच है। लेकिन डेस्कटॉप पर, और सर्वर रूम में, गैर-यूनिकोड एन्कोडिंग अब तक लंबे समय तक अप्रचलित होना चाहिए ।

Comments

मेरे पास घर के कंप्यूटर जैसे होते थे। मुझे 80 के दशक की शुरुआत में उनमें से ज्यादातर से छुटकारा मिल गया।

— डेविड थॉर्नले

Answer 5

UTF-8 के लिए आप अहंकारपूर्ण सबसे अच्छा है ¹ अंग्रेजी वक्ता। यदि आप जापानी होते, तो आपके लगभग 99% वर्ण UTF-16 में दो के बजाय 3-4 बाइट लेते।

गैर-लैटिन बोलियां वास्तव में आकार स्तर पर UTF-8 से पीड़ित हैं। यह मत भूलो कि कुछ वर्षों के भीतर, आपके अधिकांश ग्राहक चीनी हो सकते हैं, और चीनी लेखन में लाखों वर्ण हैं। आप इसे कुशलतापूर्वक UTF-8 के साथ बनाए नहीं रख सकते।

अन्यथा, मुझे इससे नफरत है जब मेरे पास टेक्स्ट दस्तावेज़ हैं जो UTF में नहीं हैं- कुछ । अगर मुझे उचित एन्कोडिंग की आवश्यकता है तो मैं अक्सर अपने रास्ते से हट जाऊंगा। मेरी पुस्तक में, गैर-यूनिकोड एनकोडिंग मृत हैं।

_{1. व्यक्तिगत रूप से अहंकारी हिस्सा न लें। मैं एक रंगीन चित्रण बनाना चाहता था और इसका वास्तव में मतलब नहीं है।}

Comments

@ मैथ्यू - 4x स्पष्ट रूप से एक्स (सकारात्मक एक्स के लिए) से 4 गुना बड़ा है। मैं यह नहीं देखता कि यहाँ स्पर्शोन्मुख संकेतन कितना प्रासंगिक है। मैंने कभी भी हार्ड डिस्क को एसिम्प्टोटिक ग्रोथ रेट के साथ विज्ञापित नहीं देखा है। आम तौर पर, ड्राइव के पूरे जीवन के दौरान आकार समान रहता है।

— स्टीव

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

— डेविड थॉर्नले 16

@ डेविड:> 99% जापानी और चीनी लेखन में उन वर्णों का उपयोग किया जाता है, जिन्हें UTF-16 और UTF-8 में केवल 2 बाइट्स की आवश्यकता होती है। जिन वर्णों की आवश्यकता होती है वे बहुत ही दुर्लभ और / या ऐतिहासिक हैं।

— तिमवी

ध्यान रखें कि जापानी और चीनी आम तौर पर प्रति शब्द कम वर्णों का उपयोग करते हैं। मैं एक ऐसे ऐप के साथ काम करता हूं, जिसमें अंग्रेजी, जापानी और चीनी में बड़ी भाषा की फाइलें हैं, सभी utf-8 में एन्कोडेड हैं। चीनी फ़ाइल वास्तव में सबसे छोटी है, जबकि जापानी फ़ाइल अंग्रेजी मूल से लगभग 15% बड़ी है।

— रोबोट

बकवास। कुछ भी जो UTF-16 में दो बाइट्स लेता है, UTF-8 में 3 बाइट्स से अधिक नहीं लेता है। कुछ भी जो UTF-8 में चार बाइट्स है, UTF-16 में 4 बाइट्स है। चीनी पात्रों का कोई "लाखों" नहीं है, और जाहिर है कि वे 16 बिट में फिट नहीं होंगे।

— gnasher729

Answer 6

यूनिकोड मौलिक रूप से टूट गया है, और कभी भी तय होने की संभावना नहीं है। यह कुछ बेहतर, कुछ सही मायने में सार्वभौमिक द्वारा प्रतिस्थापित किया जाना चाहिए। अगर किसी चीज की जरूरत नहीं है, तो वह है यूनिकोड।

उदाहरण के मुद्दों के साथ आत्महत्या:

• UTF8 एक उचित हैक है, लेकिन अधिकांश UTF16 आधारित सॉफ़्टवेयर टूट गया है। ज्यादातर विंडोज ऐप जो यूनिकोड का समर्थन करते हैं, वे ओएस सहित यूटीएफ 16 का उपयोग करते हैं। सबसे आम मुद्दा बुनियादी विमान, यानी बहु-शब्द पात्रों से अधिक का समर्थन नहीं कर रहा है।

• हान एकीकरण एक एकीकृत आपदा है। अतिरिक्त मेटाडेटा के बिना किसी एकल दस्तावेज़ में जापानी / चीनी / कोरियाई पाठ को मिलाना असंभव है, और यह पता लगाना मुश्किल है कि किस फ़ॉन्ट का उपयोग किया जाना चाहिए।

• संयुक्त वर्ण एक और आपदा हैं। अधिक समझदार एन्कोडिंग योजनाएं एक चरित्र को एक कोड में मैप करती हैं, जो प्रसंस्करण स्ट्रिंग को अपेक्षाकृत समझदार बनाती हैं। यूनिकोड नहीं करता है। यूनिकोड भी सुसंगत नहीं है - हान वर्ण अधिकतर संयोजन होते हैं, लेकिन इनको इनकोडेड नहीं किया जाता है, जहां यूरोपीय कॉम्बिनेशन वर्ण होते हैं।

• कुछ लोगों के नाम यूनिकोड में सही ढंग से नहीं लिखे जा सकते हैं, या ऊपर बताए गए मुद्दों के कारण गलत तरीके से प्रस्तुत किए जाने का खतरा है। इसके गंभीर परिणाम हो सकते हैं, उदाहरण के लिए, जब पासपोर्ट में विमान के साथ बोर्ड करने की कोशिश की जा रही है जो टिकट पर मुद्रित (गलत) से मेल नहीं खाता है।

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

आदर्श रूप से, यूनिकोड को पदावनत किया जाना चाहिए। TRON वर्ण कोडिंग यूनिकोड के लिए एक बहुत अच्छा प्रतिस्थापन है, और मौजूदा सॉफ़्टवेयर के लिए काफी हद तक संगत है जिसे अपडेट नहीं किया जाएगा।

Comments

आपका दावा है कि वर्णों के विभिन्न प्रकारों (जापानी / कोरियाई / चीनी) को मिलाना असंभव है, 15 साल से पुराना लगता है, 2002 में यूनिकोड 3.2 मानक। यूनिकोड समर्थन भिन्नता चयनकर्ताओं, कोडपॉइंट्स जो एक हानिपूर्ण कोड के बाद निर्दिष्ट करते हैं कि कौन सा रूप है प्रदर्शित किया जाना चाहिए। इसके अलावा, दहनशील वर्णों को आधार वर्णों (एक °) और विशेष ग्लिफ़्स (å) के साथ "डियाक्रिटिकल मार्क्स के संयोजन" के रूप में निर्दिष्ट किया जाता है, इसके विपरीत उन्हें परिवर्तित करने की प्रक्रिया "सामान्यीकरण" है। तो, नहीं, यूनिकोड मौलिक रूप से टूटा नहीं है।

— थोर्स्टन एस।

आप कई दोषों का वर्णन करते हैं। कुछ भाषाएं कॉम्बिनेशन कैरेक्टर्स का उपयोग करती हैं, कुछ नहीं करती हैं, और यूनिकोड यह तय नहीं कर सकता है कि यह कौन पसंद करता है। जैसा कि मैंने बताया, अधिकांश सॉफ़्टवेयर जो यूनिकोड का समर्थन करने का दावा करते हैं, वे उन मुद्दों को वैसे भी नहीं समझते हैं और चयनकर्ताओं के साथ भी इसे गलत प्रदर्शित करेंगे। प्रोग्रामर से भाषा विशेषज्ञ होने की उम्मीद नहीं की जानी चाहिए, जो कि यूनिकोड का दूसरा मूलभूत दोष है।

— उपयोगकर्ता

Answer 7

शायद लिखने के लिए, लेकिन पढ़ने के लिए नहीं।

बहुत सी मौजूदा सामग्री है जो उन एनकोडिंग का उपयोग करती है, और बेस 64 जैसे कुछ एनकोडिंग कहीं नहीं जा रहे हैं क्योंकि कुछ टेक्स्ट प्रोटोकॉल बाइनरी डेटा को एम्बेड करने के तरीके के रूप में जनादेश देते हैं।

एक वास्तविक समस्या एनकोडिंग की ऑटो-डिटेक्शन है जो सुरक्षा छेद की ओर ले जाती है। मुझे कुछ अस्पष्ट सांकेतिक शब्दों में बदलना पसंद नहीं होगा जैसे यूटीएफ -7 बस गायब हो जाता है।

ऑटो-डिटेक्शन बाइट्स के भ्रामक तारों द्वारा उत्पादित सामग्री के साथ बुरी तरह से निपटने के लिए भी जाता है।

Comments

Base64 एक वर्ण एन्कोडिंग नहीं है।

— ०४

Answer 8

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

• यदि आप बेस 64 टेक्स्ट को स्टोर / ट्रांसफर कर रहे हैं, तो आपको केवल ASCII की आवश्यकता है और आप ईमेल जैसे 7-बिट एन्कोडेड प्रोटोकॉल से भी दूर हो सकते हैं। UTF-8 का अतिरिक्त ओवरहेड अनावश्यक है।
• कई फाइलें और मौजूदा डेटा इन पुराने चरित्र एन्कोडिंग पर बनाया गया है, उन्हें पढ़ने में सक्षम होना महत्वपूर्ण है।

ध्यान दें कि 4 मानक UTF सामान्यीकरण एल्गोरिदम हैं। यदि आप मल्टी-कोडपॉइंट वर्णों के बारे में चिंतित हैं, तो आप दो सामान्यीकरण एल्गोरिदम में से एक का उपयोग कर सकते हैं जो उन्हें समतुल्य एकल-कोडपॉइंट वर्ण में ढहते हैं। उनके बीच का अंतर तार्किक तुल्यता बनाम वर्णों के भौतिक तुल्यता के साथ है।

Comments

क्या डाउनवॉटर कृपया कह सकते हैं कि उन्होंने डाउनवोट क्यों किया ?

— बेरिन लोरिट्श

मैंने डाउनवोट नहीं किया, लेकिन बेस 64 का पूरा बिंदु एक टेक्स्ट चैनल के नीचे बाइनरी डेटा ट्रांसफर करना है। यदि आप चुन सकते हैं कि उस चैनल पर किस एन्कोडिंग का उपयोग करना है, तो आप टेक्स्ट एन्कोडिंग का उपयोग बिल्कुल नहीं करेंगे। यहां तक ​​कि अगर आपका चैनल वास्तव में सादा ASCII है, तो बेस 64 7 बिट्स में से केवल 6 का उपयोग कर रहा है - पहले से ही एक महत्वपूर्ण ओवरहेड।

— स्टीव ३४

मुझे आशा है कि किसी ने सिर्फ बुलेट पॉइंट नहीं पढ़ा। उन UTF का उपयोग करने के लिए अपवाद थे। और आप 8 बाइट्स में से 6 का उपयोग करके केवल आधार 64 के बारे में गलत हैं। ASCII "वर्णों" का पहला सेट गैर मुद्रण योग्य नियंत्रण वर्ण हैं, जो कि आधार के कुछ वर्णों को 8 बाइट्स में से 7 का उपयोग करने के लिए मजबूर करता है। यह जानबूझकर उच्च बिट से बचा जाता है क्योंकि उन सभी पात्रों को हर कोड पेज में मौजूद होने की गारंटी नहीं है, जबकि 0-127 से वर्ण हैं।

— बेरिन लोरिट्श

@Berin - (1) नहीं, लेकिन यह है कि "मैं सहमत हूं" सामान बुलेट बिंदुओं के बिना ज्यादा नहीं है, और (2) आधार 64 में 64 "अंक" हैं। 64 अंक 6 बिट के लायक है, क्योंकि 2 ^ 6 == 64। आप कैसे दर्शाते हैं कि 7 बिट कोड-स्पेस (या 8 बिट्स, या यहां तक ​​कि यदि आपको चाहिए तो 8 बाइट्स) से अलग है कि वास्तव में कितना डेटा है। गैर-मुद्रण वर्ण आदि से बचने के लिए ओवरहेड का कारण है - इसका मतलब यह नहीं है कि ओवरहेड मौजूद नहीं है। बाइनरी डेटा के लिए डिज़ाइन किया गया चैनल चुनें और वह ओवरहेड नहीं है।

— स्टीव 314

इस बात को ध्यान में रखते हुए कि बेस -64 का आविष्कार एक पाठ केवल चैनल पर द्विआधारी डेटा भेजने से निपटने के लिए किया गया था। यह अक्षम (3: 4 विस्तार) के लिए जाना जाता है, लेकिन कुछ परिवहन विकल्पों में तकनीकी सीमाओं से संबंधित है। विरासत ईमेल और UseNet फ़ोरम होगी, लेकिन एक अधिक आधुनिक एप्लिकेशन XML में बाइनरी डेटा एम्बेड करेगा। कभी-कभी उचित चैनल मौजूद नहीं होता है , और आपको मौजूदा लोगों की सीमाओं के माध्यम से काम करना पड़ता है।

— बेरिन लोरिट्श