2014-04-26 5 views
14

मुझे यूटीएफ -8 एन्कोडिंग का उपयोग करके बाइट सरणी में स्ट्रिंग को एन्कोड करने की आवश्यकता है। मैं Google अमरूद का उपयोग कर रहा हूं, इसमें चार्ससेट क्लास पहले से ही यूटीएफ -8 एन्कोडिंग के लिए चार्ससेट इंस्टेंस को परिभाषित करता है। मैं 2 तरीके क्या करना है:जावा स्ट्रिंग .getBytes (charsetName) बनाम String.getBytes (वर्णसेट ऑब्जेक्ट)

  1. String.getBytes (charsetName)

    try {   
        byte[] bytes = my_input.getBytes ("UTF-8"); 
    } catch (UnsupportedEncodingException ex) { 
    
    } 
    
  2. String.getBytes (वर्णसेट वस्तु)

    // Charsets.UTF_8 is an instance of Charset  
    
    byte[] bytes = my_input.getBytes (Charsets.UTF_8); 
    

मेरा प्रश्न है जो एक है मुझे उपयोग करना चाहिए? वे एक ही परिणाम लौटते हैं। रास्ते 2 के लिए - मुझे कोशिश/पकड़ने की ज़रूरत नहीं है! मैं जावा स्रोत कोड पर एक नज़र डालता हूं और मुझे लगता है कि इस तरह 1 और रास्ता 2 अलग-अलग लागू किए गए हैं।

किसी के पास कोई विचार है?

+0

क्या आपको दोनों से समकक्ष परिणाम मिलते हैं? यदि ऐसा है, तो मैं बाद के मामले का पक्ष लेगा। यदि नहीं, तो आपको यह तय करने की आवश्यकता है कि आप सही कहां मानते हैं। – merlin2011

+0

हां, वे एक ही परिणाम लौटते हैं। लेकिन मेरी चिंता यह है कि वे अलग-अलग क्यों लागू किए जाते हैं? क्यों 1 रास्ता आंतरिक रूप से 2 रास्ता नहीं बुलाएगा? – Loc

+0

@Loc आपको क्या लगता है कि पूर्व आंतरिक रूप से बाद में फोन नहीं कर रहा है?(या, वे दोनों कुछ अन्य सामान्य आंतरिक विधि नहीं बुलाएंगे?) http://www.docjar.com/html/api/java/lang/String.java.html रेखाएं 951 - 980 –

उत्तर

2

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

Charsets.UTF_8 संकलन-समय पर अधिक आसानी से चेक किया जा सकता है, जिसकी वजह से आपको try-catch की आवश्यकता नहीं है।

8

पहला एपीआई परिस्थितियों के लिए है जब आप संकलन समय पर वर्णमाला नहीं जानते हैं; दूसरी बात यह है कि जब आप करते हैं तो स्थितियों के लिए होता है। ऐसा लगता है कि अपने कोड विशेष रूप से UTF-8 की जरूरत है के बाद से, आप दूसरी एपीआई को प्राथमिकता देनी चाहिए:

byte[] bytes = my_input.getBytes (Charsets.UTF_8); // <<== UTF-8 is known at compile time 

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

2

यदि आपके पास पहले से ही चार्सेट है, तो दूसरे संस्करण का उपयोग करें क्योंकि यह कम त्रुटि प्रवण है।

13

यदि आप एक स्ट्रिंग शाब्दिक (उदाहरण के लिए "यूटीएफ -8") का उपयोग करने जा रहे हैं ... आपको नहीं करना चाहिए। इसके बजाय दूसरे संस्करण का उपयोग करें और इस मामले में StandardCharsets (विशेष रूप से, StandardCharsets.UTF_8) से निरंतर मान प्रदान करें।

पहला संस्करण तब प्रयोग किया जाता है जब वर्णसेट गतिशील है। यह तब होगा जब आप नहीं जानते कि वर्णमाला संकलन समय पर क्या है; इसे एक अंतिम उपयोगकर्ता द्वारा आपूर्ति की जा रही है, एक कॉन्फ़िगरेशन फ़ाइल या सिस्टम प्रॉपर्टी, आदि से पढ़ा जा रहा है।

आंतरिक रूप से, दोनों विधियां StringCoding.encode() के संस्करण को कॉल कर रही हैं। encode() का पहला संस्करण पहले आपूर्ति किए गए नाम से Charset को देख रहा है, और अगर वह वर्णमाला अज्ञात/उपलब्ध नहीं है तो अपवाद फेंक रहा है।

+0

नहीं। आंतरिक रूप से, वे StringCoding.encode() को कॉल करते हैं लेकिन StringCoding.encode() के दो संस्करण हैं। पहला पैरामीटर के साथ इस विधि को कॉल करने का तरीका charsetName है, way2 इस विधि को पहले पैरामीटर के साथ कॉल करें अक्षरसेट उदाहरण है। StringCoding.encode() के 2 संस्करण को अलग-अलग लागू किया गया है। मुझे नहीं पता क्यों। – Loc

+0

क्षमा करें, मैं स्पष्ट करने के लिए संपादित करूंगा - लुकअप 'एनकोड()' –

संबंधित मुद्दे