यूटीएफ -8 और यूटीएफ -16 के बीच अंतर? हमें इनकी आवश्यकता क्यों है?यूटीएफ -8 और यूटीएफ -16 के बीच अंतर?
MessageDigest md = MessageDigest.getInstance("SHA-256");
String text = "This is some text";
md.update(text.getBytes("UTF-8")); // Change this to "UTF-16" if needed
byte[] digest = md.digest();
मेरा मानना है कि अच्छा लेख का एक बहुत देखते हैं इस बारे में वेब के आसपास, लेकिन यहां एक संक्षिप्त सारांश है।
यूटीएफ -8 और यूटीएफ -16 दोनों परिवर्तनीय लंबाई एन्कोडिंग हैं। हालांकि, यूटीएफ -8 में एक चरित्र कम से कम 8 बिट्स पर कब्जा कर सकता है, जबकि यूटीएफ -16 में वर्ण की लंबाई 16 बिट्स के साथ शुरू होती है।
मुख्य UTF-8 पेशेवरों:
मुख्य UTF-8 विपक्ष:
मुख्य UTF-16 के पेशेवरों:
char का उपयोग करने की अनुमति देती है।मुख्य UTF-16 के विपक्ष: US-ASCII तार, जो कोई अशक्त-समाप्त तार और व्यर्थ स्मृति का एक बहुत मायने रखती है में अशक्त बाइट्स की
सामान्य तौर पर, UTF-16 के आम तौर पर इन-स्मृति प्रतिनिधित्व के लिए बेहतर है क्योंकि बीई/ले वहाँ अप्रासंगिक है (बस देशी आदेश का उपयोग करें) और अनुक्रमण तेजी से होता है (बस किराए की जोड़े ठीक से संभाल मत भूलना)। दूसरी तरफ, यूटीएफ -8, पाठ फ़ाइलों और नेटवर्क प्रोटोकॉल के लिए बेहद अच्छा है क्योंकि कोई बीई/ली मुद्दा नहीं है और निरंतर समाप्ति अक्सर काम में आती है, साथ ही एएससीआईआईआई-संगतता भी होती है।
केवल BE/UTF16 पर ले भाग गुम :) UTF-8 एक और नकारात्मक पक्ष यह है, यह हो सकता है है यूटीएफ 16 – bestsss
से अधिक उत्पादन उत्पन्न करें हां, मैं बीई/ली के बारे में भूल गया। हालांकि, यह विशेष रूप से इन-मेमोरी उपयोग के लिए एक बड़ा सौदा नहीं है। यूटीएफ -8 केवल लंबे आउटपुट उत्पन्न करेगा यदि तीन बाइट वर्ण शामिल हैं, लेकिन इसका मतलब ज्यादातर चीनी और जापानी है। दूसरी तरफ, यदि पाठ में बहुत से यूएस-एएससीआईआईआई अक्षर हैं, तो यह कम आउटपुट उत्पन्न कर सकता है, इसलिए यह एक नकारात्मक स्थिति है या नहीं, किसी विशेष स्थिति पर निर्भर करता है। –
मैंने यूटीएफ -8, कम लंबाई की तत्काल समर्थक का जिक्र करने का भी विचार नहीं किया। Utf-8 के लंबे आउटपुट के बारे में यह किसी कारण से 'मई' था, फिर भी यदि लक्ष्य बहुत पूर्व है, तो डिफ़ॉल्ट एन्कोडिंग utf-16 होना चाहिए। उदाहरण के लिए md.update (text.getBytes ("UTF-8")); एन्कोडिंग कोई फर्क नहीं पड़ता क्योंकि हैश दोनों तरीकों से स्थिर है। – bestsss
वे यूनिकोड वर्णों का प्रतिनिधित्व करने के लिए बस अलग-अलग योजनाएं हैं।
दोनों चर-लंबाई हैं - यूटीएफ -16 बुनियादी बहुभाषी विमान (बीएमपी) के सभी पात्रों के लिए 2 बाइट्स का उपयोग करता है जिसमें सामान्य उपयोग में अधिकांश वर्ण होते हैं।
यूटीएफ -8 बीएमपी में वर्णों के लिए 1 और 3 बाइट्स के बीच उपयोग करता है, यू +0000 से यू + 1 एफएफएफएफएफ की वर्तमान यूनिकोड रेंज में वर्णों के लिए 4 तक, और यदि यह कभी भी हो जाता है तो यू +7 एफएफएफएफएफएफएफ तक एक्स्टेंसिबल है आवश्यक ... लेकिन विशेष रूप से सभी ASCII वर्णों को प्रत्येक बाइट में दर्शाया जाता है।
संदेश पचाने के प्रयोजनों के लिए इससे कोई फर्क नहीं पड़ता कि आप इनमें से कौन सा चुनते हैं, जब तक कि पाचन को फिर से बनाने की कोशिश करने वाले हर कोई एक ही विकल्प का उपयोग करता है।
यूटीएफ -8 और यूनिकोड के बारे में अधिक जानकारी के लिए this page देखें।
(ध्यान दें कि सभी जावा पात्रों UTF-16 बीएमपी के भीतर कोड अंक हैं;। ऊपर U + FFFF पात्रों आप जावा में सरोगेट जोड़े उपयोग करने की आवश्यकता का प्रतिनिधित्व करने के)
यह यूटीएफ -8/16 से संबंधित नहीं है (सामान्य रूप से, हालांकि यह यूटीएफ 16 में परिवर्तित होता है और बीई/ली भाग को एक लाइन में सेट किया जा सकता है), फिर भी स्ट्रिंग को बाइट में परिवर्तित करने का सबसे तेज़ तरीका नीचे है []। उदाहरण के लिए: प्रदान किए गए मामले के लिए बिल्कुल सही (हैश कोड)। String.getBytes (enc) अपेक्षाकृत धीमी है।
static byte[] toBytes(String s){
byte[] b=new byte[s.length()*2];
ByteBuffer.wrap(b).asCharBuffer().put(s);
return b;
}
सरल UTF-8 और UTF-16 अंतर करने के लिए जिस तरह से उन दोनों के बीच समानताएं पहचान करना है।
दिए गए चरित्र के लिए समान यूनिकोड नंबर साझा करने के अलावा, प्रत्येक का अपना प्रारूप है।
जॉन स्कीट एन्कोडिंग .... http पर एक अच्छा लेख है: //csharpindepth.com/Articles/General/Unicode.aspx –