2011-06-02 12 views
7

में एक int क्यों है, मैं सोच रहा हूं कि इंडेक्स के पैरामीटर को int क्यों करें, जब वर्णन एक char कहता है।स्ट्रिंग.इंडेक्सऑफ विधि का पैरामीटर जावा

सार्वजनिक पूर्णांक indexOf (पूर्णांक ch)

Returns the index within this string of the first occurrence of the specified **character** 

http://download.oracle.com/javase/1,5.0/docs/api/java/lang/String.html#indexOf%28int%29

Also, both of these compiles fine: 
char c = 'p'; 
str.indexOf(2147483647); 
str.indexOf(c); 

एक] मूल रूप से, मैं क्या लेकर दुविधा में हूँ जावा में पूर्णांक 32 बिट है, जबकि यूनिकोड वर्ण 16 बिट कर रहे हैं।

बी] int का उपयोग करने के बजाय चरित्र का उपयोग क्यों न करें। क्या यह कोई प्रदर्शन अनुकूलन है? क्या int int से प्रतिनिधित्व करना मुश्किल है? कैसे ?

मुझे लगता है कि यह इसके लिए सरल तर्क होना चाहिए और इससे मुझे इसके बारे में और भी पता चलता है!

धन्यवाद!

उत्तर

12

वास्तविक कारण यह है कि indexOf(int) एक यूनिकोड कोडपॉइंट की अपेक्षा करता है, 16-बिट यूटीएफ -16 "चरित्र" नहीं। यूनिकोड कोड बिंदु वास्तव में लंबाई में 21 बिट तक हैं। DBFF , और DC00 को D800 ;

(एक लंबे समय तक कोडपॉइंट की UTF-16 के प्रतिनिधित्व वास्तव में 2 16-बिट "चरित्र" मान है ये मान अग्रणी और surrogates अनुगामी के रूप में जाना जाता है। DFFF को क्रमशः, यह है कि कोडपॉइंट सांकेतिक शब्दों में बदलना UTF-16 के पात्रों में से जोड़ी के लिए खोज करेंगे रक्तमय जानकारी के लिए Unicode FAQ - UTF-8, UTF-16, UTF-32 & BOM देखें)

आप indexOf(int) एक कोड बिंदु> 65535 देते हैं।।

यह जावाडोक (यद्यपि बहुत स्पष्ट रूप से नहीं) द्वारा कहा गया है, और कोड की एक परीक्षा इंगित करती है कि यह वास्तव में विधि लागू की गई है।


क्यों न सिर्फ 16 बिट वर्ण का उपयोग करें?

यह बहुत स्पष्ट है। अगर उन्होंने ऐसा किया, स्ट्रिंग्स में 65535 से अधिक कोड पॉइंट्स का पता लगाने का कोई आसान तरीका नहीं होगा। यह उन लोगों के लिए एक बड़ी असुविधा होगी जो अंतर्राष्ट्रीयकृत अनुप्रयोग विकसित करते हैं जहां पाठ में ऐसे कोड अंक हो सकते हैं। (माना जाता है कि बहुत से अंतरराष्ट्रीयकृत अनुप्रयोग गलत धारणा करते हैं कि char कोड बिंदु का प्रतिनिधित्व करता है। अक्सर इससे कोई फर्क नहीं पड़ता, लेकिन कभी-कभी यह कोई फर्क नहीं पड़ता।)

लेकिन इससे आपको कोई फर्क नहीं पड़ता है। विधि अभी भी काम करेगी यदि आपके स्ट्रिंग्स में केवल 16 बिट कोड हैं ... या, उस मामले के लिए, केवल ASCII कोडों के लिए।

+0

Thnx। ठीक है, तो अब मैं इंडेक्सऑफ (int) को यूनिकोड कोडपॉइंट की अपेक्षा करता हूं, मेरा दूसरा सवाल था .. वह क्यों है? । क्यों न केवल 16-बिट वर्णों का उपयोग करें? – codeObserver

+1

क्योंकि एक यूनिकोड चेरेक्टर वास्तव में 22 बिट्स है, और 16 नहीं। इसलिए 'अक्षर/अक्षर' (कोड पॉइंट) हैं जिन्हें जावा चार में संग्रहीत नहीं किया जा सकता है। यही कारण है कि जावा स्ट्रिंग एक 'कोडपॉइंट/लेटर' स्टोर करने के लिए 2 वर्णों का उपयोग कर सकती है (यदि आप वास्तव में जानना चाहते हैं तो यूटीएफ -16 सरोगेट जोड़े देखें)। – MTilsted

3

जावा में वर्ण उनके यूनिकोड पूर्णांक प्रतिनिधित्व में संग्रहीत हैं। Character कक्षा प्रलेखन में इस प्रारूप के बारे में अधिक जानकारी है।

उस पृष्ठ पर डॉक्स से:

तरीकों कि एक पूर्णांक मूल्य समर्थन स्वीकार अनुपूरक पात्रों सहित सभी यूनिकोड वर्ण,। उदाहरण के लिए, Character.isLetter (0x2F81A) सत्य लौटाता है क्योंकि कोड बिंदु मान एक पत्र (एक सीजेके विचारधारा) का प्रतिनिधित्व करता है।

+0

Thnx। दस्तावेज़ से 2 कथन: कम (कम से कम महत्वपूर्ण) int के 21 बिट्स का उपयोग यूनिकोड कोड बिंदुओं का प्रतिनिधित्व करने के लिए किया जाता है और ऊपरी (सबसे महत्वपूर्ण) 11 बिट शून्य होना चाहिए। यूनिकोड विनिर्देश, जो परिभाषित वर्णों को निश्चित चौड़ाई 16-बिट इकाइयों के रूप में परिभाषित करता है तो यदि यूनिकोड 16 बिट्स हैं, तो 21 बिट्स का प्रतिनिधित्व करने के लिए उनका उपयोग क्यों करें? – codeObserver

+0

हां, लेकिन स्ट्रिंग्स बाइट [] कवर के तहत हैं, जो यूटीएफ -8 के रूप में एन्कोड किए गए हैं। मानक वर्ण (0-255) केवल एक बाइट पर कब्जा करते हैं (दो बाइट नहीं जो पूर्ण चौड़ाई वाले चार पर कब्जा करेंगे)। 255 से अधिक वर्ण कई बाइट्स लेते हैं, कभी-कभी 2 बाइट से अधिक। एक एन्कोडेड कैरेक्टर में एक पूर्णांक (32-बिट) समतुल्य होता है - यही है कि indexOf() – Bohemian

+0

@ p1 के लिए खोज करता है यूनिकोड बहुत लंबे समय तक 16-बिट नहीं रहा है। यूनिकोड 2.0 ने 16-बिट प्रतिबंध हटा दिया, और वह पांच साल पहले था (मुझे पुराना लगता है)। तकनीकी रूप से आईएसओ -10646 एक 31-बिट पता स्थान है, और यूनिकोड सिद्धांत में किसी भी का प्रतिनिधित्व कर सकता है। हकीकत में, यूटीएफ -16 21 बिट तक सीमित है, और यूनिकोड प्रभावी रूप से उन 21 बिट्स का समर्थन करने के लिए प्रतिबद्ध है। यह बेहद असंभव है कि आईएसओ -10646 को यूनिकोड के साथ सिंक से बाहर जाने की इजाजत दी जाएगी जो यूटीएफ -16 को तोड़ देगा, इसलिए 21-बिट प्रभावी रूप से एक हार्डकोडेड सीमा है। – Cowan

0

विधि str.indexOf(int) एक int लेता है। यदि आप इसमें char पास करते हैं, तो char से int पर char एक 16-बिट संख्या है, तो जावा char को int पर डालेगा।

+0

हां, लेकिन जावा में 32 बिट्स हैं और यह मुझे भ्रमित करता है !! – codeObserver

+1

@ पी 1, कोडपॉइंट 32-बिट हैं और यही वह है जो इसकी खोज करता है। उत्तर के लिए –

0

जावा में हुड के तहत किए गए अंतर्निहित टाइपकास्टिंग नियमों का पूरा मौका है। प्राइमेटिव्स के लिए, विशेष नियम हैं, जो सभी दस्तावेज Conversions and Promotions में उल्लिखित हैं, जो सूर्य के जावा दस्तावेज़ का हिस्सा हैं। आपके विशिष्ट प्रश्न के लिए, int से char का रूपांतरण एक "संकुचित आदिम रूपांतरण" है। उपरोक्त दस्तावेज़ में सेक्शन 5.1.3 देखें।

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

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