486

UTF-8, UTF-16 और UTF-32 में क्या अंतर हैं?

मैं समझता हूं कि वे सभी यूनिकोड को संग्रहीत करेंगे, और प्रत्येक एक चरित्र का प्रतिनिधित्व करने के लिए अलग-अलग संख्या में बाइट्स का उपयोग करता है। क्या एक को दूसरे के ऊपर चुनने का फायदा है?

— पीटर मोर्टेंसन
स्रोत

36

इस वीडियो को देखें यदि आप रुचि रखते हैं कि यूनिकोड youtube.com/watch?v=MijmeoH9LT4

1

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

— मिनट

1

मैंने रूपांतरण और तुलना के लिए एक ऑनलाइन टूल बनाया है ।

— अमित कुमार गुप्ता

1

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

— Kotauskas

@VladislavToncharov UTF-16 कभी भी एक निश्चित लंबाई एन्कोडिंग नहीं था। आप इसे UCS-2 के साथ भ्रमित कर रहे हैं।

373

UTF-8 के मामले में एक फायदा है जहां ASCII वर्ण पाठ के एक ब्लॉक में अधिकांश वर्णों का प्रतिनिधित्व करते हैं, क्योंकि UTF-8 इन्हें 8 बिट्स (ASCII की तरह) में एन्कोड करता है। इसमें यह भी लाभप्रद है कि केवल ASCII वर्णों वाली UTF-8 फ़ाइल में ASCII फ़ाइल के समान एन्कोडिंग है।

यूटीएफ -16 बेहतर है जहां एएससीआईआई प्रमुख नहीं है, क्योंकि यह मुख्य रूप से प्रति वर्ण 2 बाइट्स का उपयोग करता है। UTF-8 उच्च क्रम वर्णों के लिए 3 या अधिक बाइट्स का उपयोग करना शुरू कर देगा जहां UTF-16 अधिकांश वर्णों के लिए सिर्फ 2 बाइट्स पर रहता है।

UTF-32 4 बाइट्स में सभी संभावित पात्रों को कवर करेगा। यह यह बहुत फूला हुआ बनाता है। मैं इसका उपयोग करने के लिए किसी भी लाभ के बारे में नहीं सोच सकता।

— AnthonyWJones
स्रोत

165

UTF-32 का लाभ: आपको कैरेक्टर हैंडलिंग द्वारा उदाहरण के लिए 32-बिट यूनिकोड कोड बिंदु पर संग्रहीत डेटा को डीकोड करने की आवश्यकता नहीं है। कोड पॉइंट आपके सरणी / वेक्टर / स्ट्रिंग में पहले से ही उपलब्ध है।

— ऋक्

22

अगर आपको स्वर्ग को फिर से लागू करना है, तो यह भी आसान है कि आप (स्वर्ग आपकी मदद करें)।

— पॉल मैकमिलन

24

खैर, नेटवर्क ट्रांसफर में UTF-8 का एक फायदा है - जब से आप एक बार में डेटा एक बाइट ट्रांसफर कर रहे हैं, तो एंडियननेस के बारे में चिंता करने की ज़रूरत नहीं है (4 के विपरीत)।

— टिम Timस

30

@richq आप UTF-32 में कैरेक्टर-बाय-कैरेक्टर हैंडलिंग नहीं कर सकते, क्योंकि कोड पॉइंट हमेशा किसी कैरेक्टर के अनुरूप नहीं होता है।

— हम्सटरजेन

4

UTF-32 लाभ: स्ट्रिंग हेरफेर संभवतः utf-8 समकक्ष की तुलना में तेज है

— वेस

331

संक्षेप में:

UTF-8: चर-चौड़ाई एन्कोडिंग, ASCII के साथ पीछे संगत। ASCII के अक्षर (U + 0000 से U + 007F) 1 बाइट लेते हैं, कोड पॉइंट U + 0080 से U + 07FF ले 2 बाइट्स, कोड पॉइंट U + 0800 से U + FFFF टेक 3 बाइट्स, कोड पॉइंट्स + + 10000 से U + 10FFFF 4 बाइट लें। अंग्रेजी पाठ के लिए अच्छा है, एशियाई पाठ के लिए अच्छा नहीं है।
UTF-16: चर-चौड़ाई एन्कोडिंग। कोड अंक U + 0000 से U + FFFF 2 बाइट्स लेते हैं, कोड अंक U + 10000 से U + 10FFFF ले 4 बाइट्स। अंग्रेजी पाठ के लिए बुरा, एशियाई पाठ के लिए अच्छा है।
UTF-32: फिक्स्ड-चौड़ाई एन्कोडिंग। सभी कोड पॉइंट चार बाइट लेते हैं। एक विशाल मेमोरी हॉग, लेकिन तेजी से काम करने के लिए। बहुत कम प्रयुक्त।

लंबे समय में: यूटीएफ -8 , यूटीएफ -16 और यूटीएफ -32 देखें ।

— एडम रोसेनफील्ड
स्रोत

65

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

— एडम रोसेनफील्ड

12

UTF-32 का उपयोग शायद ही कभी नहीं किया जाता है ... 4x wchar_tबाइट पर osx और linux डिफॉल्ट पर। gcc में एक विकल्प है -fshort-wcharजो आकार को 2 बाइट्स तक कम करता है, लेकिन std libs के साथ बाइनरी संगतता को तोड़ता है।

— सिरका

9

@PandaWood ofcource UTF-8 किसी भी वर्ण को एन्कोड कर सकता है! लेकिन क्या आपने यूटीएफ -16 के साथ मेमोरी की आवश्यकता की तुलना की है? आप बिंदु याद आ रहे हैं!

— उस्मान संगत

16

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

— पॉल ग्रेगरी

5

@McGafter: बेशक वहाँ है। यदि आप भरोसेमंदता चाहते हैं, तो सीधे यूनिकोड कंसोर्टियम में घोड़े के मुंह पर जाएं । UTF- * एनकोडिंग के विवरण के लिए अध्याय 2.5 देखें। लेकिन एन्कोडिंग की एक सरल, उच्च-स्तरीय समझ प्राप्त करने के लिए, मुझे लगता है कि विकिपीडिया के लेख एक अधिक स्वीकार्य स्रोत हैं।

— एडम रोसेनफील्ड

116

UTF-8 चर 1 से 4 बाइट्स है।
UTF-16 चर 2 या 4 बाइट्स है।
UTF-32 4 बाइट तय है ।

नोट: UTF-8 नवीनतम सम्मेलन के साथ 1 से 6 बाइट ले सकता है: https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html

— Quassnoi
स्रोत

35

UTF8 वास्तव में 1 से 6 बाइट्स है।

— उरकेले २४'१४ को

6

@Urkle तकनीकी रूप से सही है क्योंकि UTF32 / LE / BE की पूरी श्रृंखला की मैपिंग में U-00200000 - U-7FFFFFFF शामिल है, भले ही यूनिकोड v6.3 U-0010FFFF समावेशी पर समाप्त होता है। यहाँ 5/6

4

प्रासंगिक संदर्भ भागों और उनके स्रोतों के साथ इनका बैकअप लेना?

— n611x007

20

@ यूर्कल नं, यूटीएफ -8 5 या 6 बाइट्स नहीं हो सकता है। यूनिकोड कोड पॉइंट 21 बिट्स तक सीमित हैं, जो UTF-8 से 4 बाइट्स तक सीमित हैं। (आप मनमाने ढंग से बड़े पूर्णांकों को एनकोड करने के लिए निश्चित रूप से UTF-8 के सिद्धांत का विस्तार कर सकते हैं, लेकिन यह यूनिकोड नहीं होगा।) RFC 3629 देखें।

— rdb

11

कोटिंग विकिपीडिया: नवंबर 2003 में, UTF-8 को RFC 3629 द्वारा UTF-16 वर्ण एन्कोडिंग के अवरोधों से मिलान करने के लिए प्रतिबंधित किया गया था: स्पष्ट रूप से उच्च और निम्न सरोगेट वर्णों के अनुरूप कोड बिंदुओं को तीन-बाइट अनुक्रमों के 3% से अधिक हटा दिया गया था , और यू + 10 एफएफएफ पर समाप्त होने पर चार-बाइट अनुक्रमों के 48% से अधिक और सभी पांच- और छह-बाइट अनुक्रमों को हटा दिया गया।

— एडम केल्व बोहल

79

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

संक्षेप में, UTF-32 प्रत्येक वर्ण के लिए 32-बिट मान का उपयोग करता है। यह उन्हें हर वर्ण के लिए एक निश्चित-चौड़ाई कोड का उपयोग करने की अनुमति देता है।

UTF-16 डिफ़ॉल्ट रूप से 16-बिट का उपयोग करता है, लेकिन यह आपको केवल 65k संभव अक्षर देता है, जो कि पूरे यूनिकोड सेट के लिए पर्याप्त नहीं है। इसलिए कुछ पात्र 16-बिट मानों के जोड़े का उपयोग करते हैं।

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

और यही हमें फायदे की ओर ले जाता है। कोई भी ASCII-वर्ण सीधे UTF-8 के साथ संगत है, इसलिए विरासत ऐप्स को अपग्रेड करने के लिए, UTF-8 एक सामान्य और स्पष्ट विकल्प है। लगभग सभी मामलों में, यह कम से कम मेमोरी का भी उपयोग करेगा। दूसरी ओर, आप किसी चरित्र की चौड़ाई के बारे में कोई गारंटी नहीं दे सकते। यह 1, 2, 3 या 4 वर्ण चौड़ा हो सकता है, जो स्ट्रिंग हेरफेर को मुश्किल बनाता है।

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

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

अंत में, यह अक्सर मंच के समर्थन के साथ जाने के लिए सहायक होता है। विंडोज यूटीएफ -16 का आंतरिक रूप से उपयोग करता है, इसलिए विंडोज पर, यह स्पष्ट विकल्प है।

लिनक्स थोड़ा भिन्न होता है, लेकिन वे आमतौर पर यूटीएफ -8 का उपयोग उन सभी चीजों के लिए करते हैं जो यूनिकोड-अनुरूप हैं।

इतना छोटा उत्तर: तीनों एनकोडिंग एक ही वर्ण सेट को सांकेतिक शब्दों में बदलना कर सकते हैं, लेकिन वे प्रत्येक चरित्र को अलग-अलग बाइट अनुक्रमों के रूप में दर्शाते हैं।

— jalf
स्रोत

12

यह कहना गलत है कि यूनिकोड प्रत्येक ग्राफिकल प्रतीक को एक अद्वितीय पूर्णांक प्रदान करता है । यह प्रत्येक कोड बिंदु पर ऐसा असाइन करता है, लेकिन कुछ कोड पॉइंट अदृश्य नियंत्रण वर्ण होते हैं , और कुछ ग्राफ़िकल प्रतीकों को प्रतिनिधित्व करने के लिए कई कोड बिंदुओं की आवश्यकता होती है ।

— 1

15

@ टीचर: हाँ, यह गलत है। समस्या यह है कि यूनिकोड की सही व्याख्या करने के लिए, आपको हजारों पृष्ठ लिखने की आवश्यकता है। मुझे एनकोडिंग के बीच के अंतर को समझाने के लिए बुनियादी अवधारणा को प्राप्त करने की उम्मीद थी

— jalf

@jalf lol सही तो मूल रूप से यूनिकोड की व्याख्या करने के लिए आपको यूनिकोड कोर विनिर्देश

— जस्टिन ओह्स

@ विशेष रूप से विशेष रूप से, आप प्रदान की गई प्राथमिकताओं से बाहर चीनी प्रतीकों का निर्माण कर सकते हैं (लेकिन वे एक ही चार्ट में हैं, इसलिए आप अवास्तविक राशि का उपयोग करके समाप्त कर देंगे - या तो डिस्क या रैम - उन्हें एनकोड करने के बजाय) बिल्ट-इन।

— कोटसकस

44

यूनिकोड एक मानक है और UTF-x के बारे में आप कुछ व्यावहारिक उद्देश्यों के लिए तकनीकी कार्यान्वयन के रूप में सोच सकते हैं:

UTF-8 - " आकार अनुकूलित ": लैटिन वर्ण आधारित डेटा (या ASCII) के लिए सबसे उपयुक्त, इसमें प्रति वर्ण केवल 1 बाइट लगता है, लेकिन आकार तदनुसार प्रतीकात्मक रूप से बढ़ता है (और सबसे खराब स्थिति में प्रति वर्ण 6 बाइट तक बढ़ सकता है)
UTF-16 - " बैलेंस ": इसमें प्रति वर्ण न्यूनतम 2 बाइट्स लगते हैं जो कि मुख्यधारा के भाषाओं के मौजूदा सेट के लिए पर्याप्त है, जिसमें चरित्र को संभालने में आसानी होती है (लेकिन आकार अभी भी परिवर्तनशील है और प्रति वर्ण 4 बाइट्स तक बढ़ सकता है )
UTF-32 - " प्रदर्शन ": निश्चित आकार वर्णों (4 बाइट्स) के परिणाम के रूप में सरल एल्गोरिदम का उपयोग करने की अनुमति देता है, लेकिन स्मृति हानि के साथ

— कौआ
स्रोत

«मुख्यधारा की भाषाएँ» दुनिया के बहुत सारे हिस्सों में वह मुख्यधारा नहीं है ^ ^

— tuxayo

2

UTF-16 वास्तव में गैर ASCII वर्णों के लिए अनुकूलित आकार है। इसके लिए यह वास्तव में निर्भर करता है कि किन भाषाओं का उपयोग किया जाएगा।

— टक्सायो

@ टक्सायो पूरी तरह से सहमत है, यह दुनिया के एशियाई भाग के लिए हंजी और कांजी पात्रों के ध्यान देने योग्य सेट है।

— किश्ती

शीर्ष उत्तर होना चाहिए। यहां दफन होना बहुत सही है।

— मिशल Mictein

28

मैंने अपने ब्लॉगपोस्ट में एक सरल व्याख्या देने की कोशिश की ।

UTF-32

किसी भी वर्ण को एनकोड करने के लिए 32 बिट्स (4 बाइट्स) की आवश्यकता होती है । उदाहरण के लिए, इस योजना का उपयोग करते हुए "A" वर्ण कोड-पॉइंट का प्रतिनिधित्व करने के लिए, आपको 32-बिट बाइनरी संख्या में 65 लिखना होगा:

00000000 00000000 00000000 01000001 (Big Endian)

यदि आप एक करीब से देखते हैं, तो आप ध्यान देंगे कि ASCII योजना का उपयोग करते समय सबसे दाएं सात बिट वास्तव में एक ही बिट्स हैं। लेकिन चूंकि UTF-32 निश्चित चौड़ाई वाली योजना है , इसलिए हमें तीन अतिरिक्त बाइट्स संलग्न करने होंगे। मतलब कि अगर हमारे पास दो फाइलें हैं जिनमें केवल "A" वर्ण है, एक ASCII-एन्कोडेड है और दूसरा UTF-32 एनकोडेड है, उनका आकार 1 बाइट और 4 बाइट्स समान होगा।

UTF-16

बहुत से लोग सोचते हैं कि जैसे यूटीएफ -32 एक कोड-पॉइंट का प्रतिनिधित्व करने के लिए निश्चित चौड़ाई 32 बिट का उपयोग करता है, वैसे ही यूटीएफ -16 की चौड़ाई 16 बिट्स है। गलत!

UTF-16 में कोड बिंदु शायद 16 बिट्स, या 32 बिट्स में दर्शाया गया है। तो यह योजना परिवर्तनशील लंबाई एन्कोडिंग प्रणाली है। UTF-32 पर क्या फायदा है? कम से कम ASCII के लिए, फ़ाइलों का आकार मूल (लेकिन अभी भी दो बार) से 4 गुना अधिक नहीं होगा, इसलिए हम अभी भी ASCII प्रासंगिक नहीं हैं।

चूंकि 7-बिट "ए" चरित्र का प्रतिनिधित्व करने के लिए पर्याप्त हैं, हम अब यूटीएफ -32 की तरह 4 के बजाय 2 बाइट्स का उपयोग कर सकते हैं। ऐसा लगेगा:

00000000 01000001

UTF-8

आपने सही अनुमान लगाया है .. UTF-8 में कोड बिंदु शायद 32, 16, 24 या 8 बिट्स का उपयोग करके दर्शाया गया है, और UTF-16 प्रणाली के रूप में, यह एक चर लंबाई एन्कोडिंग प्रणाली भी है।

अंत में हम "ए" का प्रतिनिधित्व कर सकते हैं उसी तरह हम एएससीआईआई एन्कोडिंग प्रणाली का उपयोग करके इसका प्रतिनिधित्व करते हैं:

01001101

एक छोटा सा उदाहरण जहां UTF-16 वास्तव में UTF-8 से बेहतर है:

चीनी पत्र "語" पर विचार करें - इसका UTF-8 एन्कोडिंग है:

11101000 10101010 10011110

जबकि इसका UTF-16 एन्कोडिंग छोटा है:

10001010 10011110

प्रतिनिधित्व को समझने के लिए और इसकी व्याख्या कैसे की जाती है, मूल पोस्ट पर जाएं।

— Maroun
स्रोत

19

UTF-8

बाइट-ऑर्डर की कोई अवधारणा नहीं है
प्रति वर्ण 1 और 4 बाइट्स के बीच का उपयोग करता है
ASCII एन्कोडिंग का एक संगत सबसेट है
पूरी तरह से सेल्फ-सिंक्रोनाइजेशन जैसे कि एक स्ट्रीम में कहीं से भी गिरा हुआ बाइट ज्यादातर सिंगल कैरेक्टर पर भ्रष्ट होगा
बहुत अधिक सभी यूरोपीय भाषाएं दो बाइट्स या प्रति वर्ण कम में एन्कोडेड हैं

UTF-16

ज्ञात बाइट-ऑर्डर के साथ पार्स किया जाना चाहिए या बाइट-ऑर्डर-मार्क पढ़ना (बीओएम)
प्रति वर्ण 2 या 4 बाइट्स का उपयोग करता है

UTF-32

हर चरित्र 4 बाइट्स है
ज्ञात बाइट-ऑर्डर के साथ पार्स किया जाना चाहिए या बाइट-ऑर्डर-मार्क पढ़ना (बीओएम)

जब तक CJK (चीनी, जापानी और कोरियाई) वर्ण स्थान से अधिकांश वर्ण नहीं हो जाते, तब तक UTF-8 सबसे अधिक अंतरिक्ष कुशल होने वाला है।

UTF-32 चरित्र बाइट द्वारा यादृच्छिक पहुँच के लिए सबसे अच्छा है एक बाइट-सरणी में।

— जेफ एडम्सन
स्रोत

UTF-8 में "सेल्फ सिंक्रोनाइज़िंग" कैसे काम करता है? क्या आप 1 बाइट और 2 बाइट पात्रों के लिए उदाहरण दे सकते हैं?

— १६:०५ पर कोरे तुगाये

2

@KorayTugay मान्य छोटी बाइट स्ट्रिंग्स का उपयोग लंबे वर्णों में कभी नहीं किया जाता है। उदाहरण के लिए, ASCII 0-127 की सीमा में है, जिसका अर्थ है कि सभी एक-बाइट वर्णों 0xxxxxxxका द्विआधारी में रूप है। सभी दो-बाइट वाले पात्रों की शुरुआत 110xxxxxदूसरे बाइट से होती है 10xxxxxx। तो मान लीजिए कि दो-बाइट वाले चरित्र का पहला चरित्र खो गया है। जैसे ही आप 10xxxxxxएक पूर्ववर्ती के बिना देखते हैं 110xxxxxx, आप यह सुनिश्चित कर सकते हैं कि एक बाइट खो गई थी या दूषित हो गई थी, और उस चरित्र को त्याग दें (या सर्वर या जो भी हो, उससे फिर से अनुरोध करें), और तब तक आगे बढ़ें जब तक आप एक वैध पहला बाइट फिर से न देखें। ।

— क्रिस

1

यदि आपके पास किसी चरित्र की ऑफसेट है, तो आपके पास उस चरित्र की ऑफसेट है - utf8, utf16 या utf32 उस मामले में बस एक ही काम करेगा; यानी वे सभी बाइट सरणी में चरित्र ऑफसेट द्वारा यादृच्छिक पहुँच पर समान रूप से अच्छे हैं। Utf8 की तुलना में वर्णों को गिनने में utf32 बेहतर है यह विचार भी पूरी तरह से गलत है। एक कोडपॉइंट (जो नहीं है जो फिर एक चरित्र के रूप में ही, एक ग्रफीम के समान नहीं है .. विलाप), utf32 में 32 बिट चौड़ा है और 8 और 32 के बीच UTF8 में बिट्स, लेकिन एक चरित्र कई कोड पॉइंट्स, अवधि सकता है उन प्रमुख लाभ को नष्ट कर देता है जो लोग दावा करते हैं कि utf32 का utf8 है।

— स्पष्ट

14

मैंने MySQL में UTF-8 और UTF-16 के बीच डेटाबेस प्रदर्शन की तुलना करने के लिए कुछ परीक्षण किए।

अद्यतन गति

UTF-8

यहां छवि विवरण दर्ज करें

UTF-16

यहां छवि विवरण दर्ज करें

स्पीड डालें

यहां छवि विवरण दर्ज करें

गति हटाएं

यहां छवि विवरण दर्ज करें

— फरीद चालसमोव
स्रोत

14

UTF-32 में सभी पात्रों को 32 बिट्स के साथ कोडित किया गया है। लाभ यह है कि आप आसानी से स्ट्रिंग की लंबाई की गणना कर सकते हैं। नुकसान यह है कि प्रत्येक ASCII वर्ण के लिए आप एक अतिरिक्त तीन बाइट बर्बाद करते हैं।

UTF-8 वर्णों में परिवर्तनशील लंबाई होती है, ASCII वर्णों को एक बाइट (आठ बिट्स) में कोडित किया जाता है, अधिकांश पश्चिमी विशेष वर्णों को या तो दो बाइट्स या तीन बाइट्स में कोडित किया जाता है (उदाहरण के लिए € तीन बाइट्स), और अधिक विदेशी वर्ण ले सकते हैं चार बाइट्स के लिए। स्पष्ट नुकसान यह है, कि एक प्राथमिकता आप स्ट्रिंग की लंबाई की गणना नहीं कर सकते। लेकिन यह UTF-32 की तुलना में लैटिन (अंग्रेजी) वर्णमाला पाठ को कोड करने के लिए बहुत कम बाइट्स लेता है।

UTF-16 भी परिवर्तनशील लंबाई है। वर्णों को दो बाइट्स या चार बाइट्स में कोडित किया जाता है। मैं वास्तव में बात नहीं देख रहा हूँ। इसकी परिवर्तनशील लंबाई होने का नुकसान है, लेकिन इसे UTF-8 के रूप में अधिक स्थान बचाने का लाभ नहीं मिला है।

उन तीनों में से, स्पष्ट रूप से UTF-8 सबसे व्यापक रूप से फैला हुआ है।

— vartec
स्रोत

वेबसाइटों को विकसित करते समय मैं स्ट्रिंग की लंबाई की गणना क्यों करना चाहूंगा? क्या वेब विकास में UTF-8 / UTF-16 को चुनने का कोई फायदा है?

— मॉर्फिडन

"लाभ यह है कि आप आसानी से स्ट्रिंग की लंबाई की गणना कर सकते हैं" यदि आप कोडपॉइंट के # द्वारा लंबाई को परिभाषित करते हैं, तो हाँ, आप यूटीएफ -32 के साथ इसे प्राप्त करने के लिए बाइट की लंबाई को 4 से विभाजित कर सकते हैं। हालांकि, यह बहुत उपयोगी परिभाषा नहीं है: यह वर्णों की संख्या से संबंधित नहीं हो सकता है। इसके अलावा, सामान्यकरण स्ट्रिंग में कोडपॉइंट की संख्या को बदल सकता है। उदाहरण के लिए, फ्रेंच शब्द "été" को 3 अलग कोडपॉइंट लंबाई के साथ कम से कम 4 अलग-अलग तरीकों से एन्कोड किया जा सकता है।

UTF-16 संभवतः UTF-8 की तुलना में तेज़ है, जबकि UTF-32 जैसी कोई भी बर्बाद करने वाली मेमोरी नहीं है।

— मिशाल Mictein

6

आपके विकास के माहौल के आधार पर, आपके पास यह विकल्प भी नहीं हो सकता है कि आपके स्ट्रिंग डेटा प्रकार को आंतरिक रूप से किस प्रकार का उपयोग किया जाए।

लेकिन डेटा संग्रहीत करने और उसका आदान-प्रदान करने के लिए, मैं हमेशा यूटीएफ -8 का उपयोग करूंगा, अगर आपके पास विकल्प है। यदि आपके पास ज्यादातर ASCII डेटा है, तो यह आपको स्थानांतरण करने के लिए सबसे छोटी मात्रा में डेटा देगा, जबकि अभी भी सब कुछ एनकोड करने में सक्षम है। आधुनिक मशीनों पर जाने के लिए कम से कम I / O का अनुकूलन।

— mghie
स्रोत

अंतरिक्ष आवश्यकताओं की तुलना में बहुत अधिक महत्वपूर्ण तथ्य यह है कि UTF-8 एंडियननेस के लिए प्रतिरक्षा है। UTF-16 और UTF-32 अनिवार्य रूप से धीरज के मुद्दों से निपटेंगे, जहाँ UTF-8 केवल ओकटेट की एक धारा है।

— IInspectable

2

जैसा कि उल्लेख किया गया है, अंतर मुख्य रूप से अंतर्निहित चर का आकार है, जो प्रत्येक मामले में अधिक वर्णों का प्रतिनिधित्व करने की अनुमति देने के लिए बड़ा हो जाता है।

हालांकि, फोंट, एन्कोडिंग और चीजें बुरी तरह से (अनावश्यक रूप से जटिल हैं), इसलिए अधिक विस्तार से भरने के लिए एक बड़ी कड़ी की आवश्यकता है:

http://www.cs.tut.fi/~jkorpela/chars.html#ascii

यह सब समझने की उम्मीद मत करो, लेकिन अगर आप बाद में समस्याओं के बारे में नहीं जानना चाहते हैं तो यह जितना संभव हो उतना सीखने लायक है, जितनी जल्दी आप कर सकते हैं (या बस किसी और को आपके लिए इसे सॉर्ट करने के लिए कर सकते हैं)।

पॉल।

— पॉल डब्ल्यू होमर
स्रोत

या यूटीएफ -8 का उपयोग डिफ़ॉल्ट रूप से करें क्योंकि यह डी-फैक्टो मानक बन गया है, और यह पता करें कि कोई नया सिस्टम इसका समर्थन करता है या नहीं। यदि ऐसा नहीं होता है, तो आप इस पोस्ट पर वापस आ सकते हैं।

— 10

-2

संक्षेप में, UTF-16 या UTF-32 का उपयोग करने का एकमात्र कारण क्रमशः गैर-अंग्रेजी और प्राचीन लिपियों का समर्थन करना है।

मैं सोच रहा था कि किसी ने गैर-यूटीएफ -8 एन्कोडिंग को क्यों चुना है जब यह स्पष्ट रूप से वेब / प्रोग्रामिंग उद्देश्यों के लिए अधिक कुशल है।

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

कुछ अच्छे पढ़ने: http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html और http://utf8everywhere.org

— killjoy
स्रोत

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

— IInspectable

यह प्रश्न डाउनवोटिंग के लिए उत्तरदायी है क्योंकि UTF-8 का अभी भी सामान्यतः HTML फ़ाइलों में उपयोग किया जाता है, भले ही अधिकांश वर्ण UTF-8 में 3-बाइट वर्ण हों,

— 5gǻňạcểơửṩ

@IIspectable समर्थन सबसे अच्छा शब्द नहीं है, बढ़ावा देना या बेहतर समर्थन अधिक सटीक होगा

— रोबोटिक

Utf8everywhere.org जैसे पेज को भेजना वह नहीं है जो मैं एसओ उत्तर में करूंगा।

— मिशाल Mictein