कुछ यूनिकोड वर्णों के साथ टिप्पणियों में जावा कोड को क्यों निष्पादित किया जाता है?

Question

निम्न कोड आउटपुट "हैलो वर्ल्ड!" (नहीं वास्तव में, यह कोशिश)।

public static void main(String... args) {

   // The comment below is not a typo.
   // \u000d System.out.println("Hello World!");
}

इसका कारण यह है कि जावा कंपाइलर \u000dएक नई लाइन के रूप में यूनिकोड वर्ण को पार्स करता है और इसमें रूपांतरित हो जाता है:

public static void main(String... args) {

   // The comment below is not a typo.
   //
   System.out.println("Hello World!");
}

इस प्रकार एक टिप्पणी के परिणामस्वरूप "निष्पादित" किया गया।

चूंकि यह दुर्भावनापूर्ण कोड "छिपाने" के लिए इस्तेमाल किया जा सकता है या जो भी एक दुष्ट प्रोग्रामर गर्भ धारण कर सकता है, उसे टिप्पणियों में क्यों अनुमति दी जाती है ?

जावा विनिर्देश द्वारा इसकी अनुमति क्यों है?

Comments

"यह अनुमति क्यों है" मेरे लिए बहुत राय-आधारित लगता है। भाषा डिजाइनरों ने एक निर्णय लिया, और क्या जानने की आवश्यकता है? जब तक आप उस निर्णय लेने वाले व्यक्ति का एक बयान नहीं पाते, हम केवल अनुमान लगा सकते हैं।

— इंगो बुर्क

कम से कम एक दिलचस्प बात यह है कि ओपी का आईडीई स्पष्ट रूप से गलत हो जाता है और गलत हाइलाइटिंग प्रदर्शित करता है,

— 9'15 को 15:09

संभवतः संबंधित: stackoverflow.com/questions/4448180/…

— dhke

@Tobb लेकिन जावा डिजाइनरों अतः दौरा कर रहे हैं तो यह है संभव उनमें से एक ने उत्तर पाने के लिए। इसके अलावा वे ऐसे संसाधन मौजूद हो सकते हैं जो पहले से ही इस प्रश्न का उत्तर देते हैं।

— Pshemo

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

— user207421

Answer 1

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

जैसा कि JLS धारा 3.3 में कहा गया है, यह किसी भी ASCII आधारित उपकरण को स्रोत फ़ाइलों को संसाधित करने की अनुमति देता है:

[...] जावा प्रोग्रामिंग भाषा यूनिकोड में लिखे गए प्रोग्राम को ASCII में बदलने का एक मानक तरीका निर्दिष्ट करती है जो प्रोग्राम को एक ऐसे रूप में बदल देती है जिसे ASCII- आधारित टूल द्वारा संसाधित किया जा सकता है। [...]

यह प्लेटफॉर्म की स्वतंत्रता (समर्थित चरित्र सेटों की स्वतंत्रता) के लिए एक मूलभूत गारंटी देता है जो हमेशा जावा प्लेटफॉर्म के लिए एक महत्वपूर्ण लक्ष्य रहा है।

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

इस विषय पर कई गोचर्स हैं और जोशुआ बलोच और नील गेलर के जावा पज़लर्स में निम्नलिखित संस्करण शामिल हैं:

क्या यह एक कानूनी जावा प्रोग्राम है? यदि हां, तो यह क्या प्रिंट करता है?

\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020\u0020
\u0063\u006c\u0061\u0073\u0073\u0020\u0055\u0067\u006c\u0079
\u007b\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020
\u0020\u0020\u0020\u0020\u0073\u0074\u0061\u0074\u0069\u0063
\u0076\u006f\u0069\u0064\u0020\u006d\u0061\u0069\u006e\u0028
\u0053\u0074\u0072\u0069\u006e\u0067\u005b\u005d\u0020\u0020
\u0020\u0020\u0020\u0020\u0061\u0072\u0067\u0073\u0029\u007b
\u0053\u0079\u0073\u0074\u0065\u006d\u002e\u006f\u0075\u0074
\u002e\u0070\u0072\u0069\u006e\u0074\u006c\u006e\u0028\u0020
\u0022\u0048\u0065\u006c\u006c\u006f\u0020\u0077\u0022\u002b
\u0022\u006f\u0072\u006c\u0064\u0022\u0029\u003b\u007d\u007d

(यह कार्यक्रम एक सादे "हैलो वर्ल्ड" कार्यक्रम के रूप में सामने आया।)

गूढ़ व्यक्ति के समाधान में, वे निम्नलिखित बातें बताते हैं:

अधिक गंभीरता से, यह पहेली पिछले तीन के पाठों को सुदृढ़ करने का कार्य करती है: यूनिकोड से बचना आवश्यक है जब आपको उन पात्रों को सम्मिलित करने की आवश्यकता होती है जिन्हें आपके कार्यक्रम में किसी अन्य तरीके से प्रस्तुत नहीं किया जा सकता है। अन्य सभी मामलों में उनसे बचें।

---

स्रोत: जावा: टिप्पणियों में निष्पादन कोड ?!

Comments

संक्षेप में, जावा जानबूझकर इसे अनुमति देता है: ओपी के आईडीई में "बग" है?

— बाथशीबा

@ बाथशीबा: यह लोगों के सिर में अधिक है। लोग यह समझने की कोशिश नहीं करते हैं कि जावा पार्सिंग कैसे काम करता है, इसलिए आईडीई कभी-कभी कोड को गलत तरीके से प्रदर्शित करते हैं। ऊपर दिए गए उदाहरण में, टिप्पणी के साथ समाप्त होना चाहिए \u000dऔर इसके बाद का भाग कोड हाइलाइट होना चाहिए।

— आरोन दिगुल्ला

एक अन्य सामान्य गलती है कि विंडोज पाथ को कोड में पेस्ट करना है जैसे // C:\user\...कि \userएक यूनिकोड एस्केप सीक्वेंस नहीं होने के कारण एक कंपाइल एरर हो जाता है।

— हारून दिगुल्ला

\u000dआंशिक रूप से हाइलाइट किए जाने के बाद कोड ग्रहण में । Ctrl + Shift + F दबाने के बाद चरित्र को नई लाइन से बदल दिया जाता है और बाकी लाइन को लपेट दिया जाता है

— BluelDe

@ TheLostMind यदि मैं उत्तर को सही ढंग से समझता हूं तो आपको इसे ब्लॉक टिप्पणियों के साथ भी पुन: पेश करने में सक्षम होना चाहिए। \u002A/टिप्पणी समाप्त करनी चाहिए।

— तैमूर

Answer 2

चूंकि यह अभी तक संबोधित नहीं किया गया है, यहां एक स्पष्टीकरण, यूनिकोड का अनुवाद किसी अन्य स्रोत कोड प्रसंस्करण से पहले क्यों होता है:

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

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

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

यह एक और अजीब विशेषता का कारण है जिसका उल्लेख भी नहीं किया गया है: \uuuuuuxxxxवाक्यविन्यास:

जब एक अनुवाद उपकरण पात्रों से बचने और एक दृश्य पहले से ही भाग निकले अनुक्रम है कि सामना करना पड़ता है, यह एक अतिरिक्त डालूँ uअनुक्रम में, परिवर्तित \ucafeकरने के लिए \uucafe। अर्थ नहीं बदलता है, लेकिन जब दूसरी दिशा में परिवर्तित होता है, तो उपकरण को केवल एक को हटा देना चाहिए uऔर केवल एक ही अनुक्रम को uउनके यूनिकोड वर्णों से बदलना चाहिए । इस तरह, यहां तक ​​कि यूनिकोड से बचकर आगे और पीछे जाने पर अपने मूल रूप में बच जाते हैं। मुझे लगता है, कोई भी कभी भी उस सुविधा का उपयोग करता है ...

Comments

दिलचस्प है, वाक्यविन्यास native2asciiका उपयोग नहीं लगता है \uu...xxxx,

— Ninjalj

हाँ, native2asciiउन्हें बुत-लैटिन -1 में परिवर्तित करके संसाधन बंडलों को तैयार करने में मदद करने का इरादा था , क्योंकि Properties.loadकेवल लैटिन -1 को पढ़ने के लिए तय किया गया था। और वहाँ, नियम अलग हैं, कोई \uuu…सिंटैक्स और कोई प्रारंभिक प्रसंस्करण चरण नहीं है। संपत्ति फ़ाइलों में, property=multi\u000alineवास्तव में के रूप में ही है property=multi\nline। (दस्तावेज़ के जावा ™ भाषा विनिर्देश के अनुभाग 3.3 में परिभाषित के अनुसार "यूनिकोड के उपयोग से वाक्यांश" का विरोध करना)

— होल्गर

ध्यान दें कि यह डिज़ाइन लक्ष्य किसी भी मौसा के बिना हासिल किया जा सकता था; सबसे आसान तरीका \uयू + 0000–007F श्रेणी में वर्ण उत्पन्न करने से बचने के लिए होता है। (इस तरह के सभी पात्रों को मूल रूप से उन सभी राष्ट्रीय एन्कोडिंग द्वारा प्रस्तुत किया जा सकता है जो 1990 के दशक में प्रासंगिक थे - ठीक है, शायद कुछ नियंत्रण वर्णों को छोड़कर, लेकिन आपको उन लोगों को जावा लिखने की आवश्यकता नहीं है।)

— zwol

@zwol: ठीक है, अगर आप नियंत्रण वर्णों को बाहर करते हैं जो कि जावा स्रोत कोड के भीतर वैसे भी अनुमति नहीं है, तो आप सही हैं। फिर भी, यह नियमों को और अधिक जटिल बना देगा। और आज, निर्णय पर चर्चा करने के लिए बहुत देर हो चुकी है ...

— Holger

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

— डेविड

Answer 3

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

जावा स्रोत कोड में \ u000d हर तरह से एक ASCII CR वर्ण के बराबर है। यह जहां कहीं भी होता है, एक अंत होता है, सादा और सरल होता है। प्रश्न में प्रारूपण भ्रामक है, वर्णों का वह क्रम वास्तव में किसके अनुरूप है:

public static void main(String... args) {
   // The comment below is no typo. 
   // 
 System.out.println("Hello World!");
}

IMHO सबसे सही उत्तर इसलिए है: कोड निष्पादित होता है क्योंकि यह एक टिप्पणी में नहीं है; यह अगली पंक्ति पर है। जावा में "टिप्पणियों में निष्पादन की अनुमति नहीं है", जैसे आप उम्मीद करेंगे।

अधिकांश भ्रम इस तथ्य से उपजा है कि सिंटेक्स हाइलाइटर्स और आईडीई इस स्थिति को ध्यान में रखने के लिए पर्याप्त परिष्कृत नहीं हैं। वे या तो यूनिकोड से बचने की प्रक्रिया बिल्कुल नहीं करते हैं, या वे पहले के बजाय कोड को पार्स करने के बाद करते हैं, जैसे javacकि करते हैं।

Comments

मैं मानता हूं, यह एक जावा "डिजाइन त्रुटि" नहीं है, लेकिन यह एक आईडीई बग है।

— bvdb

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

— फिल

@Phil: यह केवल एक टिप्पणी की तरह दिखता है जब किसी विशेष उपकरण के साथ देखा जाता है, अन्य इसे अन्यथा दिखाते हैं।

— jmoreno

@jmoreno एक नहीं होना चाहिए है कुछ भी एक पाठ संपादक की तुलना में अधिक कोड को पढ़ने के लिए है। बहुत कम से कम, यह कम से कम आश्चर्य के प्रिंसिपल का उल्लंघन करता है, अर्थात् // शैली की टिप्पणियां अगले \ n वर्ण तक जारी रहती हैं - किसी अन्य अनुक्रम के लिए नहीं जो अंततः अंततः \ n द्वारा प्रतिस्थापित किया जाता है। टिप्पणियाँ कभी नहीं छीन के अलावा कुछ भी होने की उम्मीद है। बुरा उपसर्ग करनेवाला।

— फिल

Answer 4

\u000dभागने एक टिप्पणी समाप्त हो जाता है, क्योंकि \uपलायन समान रूप से इसी यूनिकोड वर्ण में बदल रही हैं इससे पहले कि कार्यक्रम tokenized है। आप टिप्पणी शुरू करने के \u0057\u0057बजाय समान रूप से उपयोग कर सकते हैं ।//

यह आपके IDE में एक बग है, जिसे यह स्पष्ट करने के लिए लाइन को सिंटैक्स-हाइलाइट करना चाहिए कि \u000dटिप्पणी समाप्त होती है।

यह भाषा में एक डिज़ाइन त्रुटि भी है। इसे अब ठीक नहीं किया जा सकता, क्योंकि यह उन कार्यक्रमों को तोड़ देगा जो इस पर निर्भर करते हैं। \uएस्केप को या तो कंपाइलर द्वारा संबंधित यूनिकोड चरित्र में केवल संदर्भों में परिवर्तित किया जाना चाहिए, जहां वह "समझ में आता है" (स्ट्रिंग शाब्दिक और पहचानकर्ता, और शायद कहीं और नहीं) या उन्हें यू 0000-007F रेंज में वर्ण उत्पन्न करने के लिए मना किया जाना चाहिए था , अथवा दोनों। या तो उन शब्दार्थों ने टिप्पणी को \u000dपलायन से समाप्त होने से रोक दिया होगा, उन मामलों में हस्तक्षेप किए बिना, जहां से \uबचने के लिए उपयोगी हैं - ध्यान दें कि टिप्पणियों के अंदर भागने का उपयोग शामिल\u है एक गैर-लैटिन लिपि में टिप्पणियों को सांकेतिक शब्दों में बदलना, क्योंकि पाठ संपादक कहां से व्यापक विचार कर सकता है\uसंकलक की तुलना में पलायन महत्वपूर्ण हैं। (मैं किसी भी संपादक या आईडीई के बारे में नहीं जानता जो किसी भी संदर्भ \uमें संबंधित पात्रों के रूप में पलायन प्रदर्शित करेगा , हालांकि।)

C परिवार में एक समान डिज़ाइन त्रुटि है, ¹ जिसमें बैकस्लैश-न्यूलाइन को संसाधित किया जाता है इससे पहले कि टिप्पणी सीमा निर्धारित की जाती है, इसलिए

// this is a comment \
   this is still in the comment!

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

^{1 बच्चों के} लिए: मुझे पता है कि सी का यह पहलू 100% जानबूझकर था, औचित्य के साथ - मैं इसे नहीं बना रहा हूं - कि यह आपको पंच कार्डों पर मनमाने ढंग से लंबी लाइनों के साथ यंत्रवत् रूप से फिट करने की अनुमति देगा। यह अभी भी एक गलत डिजाइन निर्णय था।

Comments

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

— aioobe

यह कहा गया है, मुझे लगता है कि \uऑक्टल नोटेशन के लिए अग्रणी शून्य का उपयोग करने में सी की लीड का पालन करने के निर्णय की तुलना में प्रसंस्करण चरण का विकल्प कम नहीं था। हालांकि ऑक्टल नोटेशन कभी-कभी उपयोगी होता है, मैंने अभी तक किसी को भी एक तर्क को स्पष्ट करने के लिए क्यों नहीं सुना है कि एक अग्रणी शून्य इसे इंगित करने का एक अच्छा तरीका है।

— सुपरकैट

@supercat C89 में उस सुविधा को फेंकने वाले लोग खरोंच से एक सुविधा डिज़ाइन करने के बजाय मूल K & R प्रीप्रोसेसर के व्यवहार को सामान्य कर रहे थे। मुझे संदेह है कि वे छिद्रित कार्ड सर्वोत्तम प्रथाओं से परिचित थे, और मुझे यह भी संदेह है कि इस सुविधा का उपयोग कभी - कभी अपने कथित उद्देश्य के लिए किया गया है, शायद एक या दो रेट्रोकोम्प्यूटिंग अभ्यासों को छोड़कर।

— zwol

@supercat मुझे \uपूर्व-टोकन परिवर्तन के रूप में जावा के साथ कोई समस्या नहीं होगी अगर इसे U + 0000..U + 007F रेंज में वर्णों को बनाने के लिए मना किया गया था। यह "यह हर जगह काम करता है" और "इस उपनाम ASCII अक्षर वाक्यिक महत्व के साथ" का संयोजन है जो इसे अजीब से फ्लैट-आउट गलत तक दर्शाता है।

— zwol

पर अपने "pedants के लिए": उस समय बेशक एकल लाइन टिप्पणी मौजूद नहीं था । और चूंकि C का एक स्टेटमेंट टर्मिनेटर है जो कि एक नई लाइन नहीं है, इसलिए इसे ज्यादातर लंबे स्ट्रिंग्स के लिए इस्तेमाल किया जाएगा, सिवाय इसके कि जहां तक ​​मैं यह निर्धारित कर सकता हूं कि "स्ट्रिंग शाब्दिक कॉन्सेप्टन" K & R से था । //

— मार्क हर्ड

Answer 5

यह एक जानबूझकर डिजाइन पसंद था जो जावा के मूल डिजाइन पर वापस जाता है।

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

यह निश्चित रूप से उन कार्यक्रमों में कमी है (जैसे आईडीई) स्रोत पाठ को देखने के लिए उपयोग किया जाता है कि ऐसे कार्यक्रम यूनिकोड से बच नहीं सकते हैं और संबंधित ग्लिफ़ को प्रदर्शित कर सकते हैं।

Comments

आजकल हम अपने सोर्स कोड के लिए UTF-8 का उपयोग करते हैं, और सीधे यूनिकोड वर्णों का उपयोग कर सकते हैं, पलायन की कोई आवश्यकता नहीं है।

— पाओलो एबरमन

Answer 6

मैं @zwol से सहमत हूं कि यह एक डिज़ाइन गलती है; लेकिन मैं इससे भी अधिक महत्वपूर्ण हूँ।

\uस्ट्रिंग स्ट्रिंग और चार लीटर में उपयोगी है; और यह एकमात्र जगह है कि यह मौजूद होना चाहिए। इसे उसी तरह से संभाला जाना चाहिए जैसे अन्य भाग जाते हैं \n; और बिल्कुल मतलब "\u000A" होना चाहिए"\n" ।

होने का कोई मतलब नहीं है \uxxxxटिप्पणियों में - कोई भी इसे पढ़ नहीं सकता है।

इसी तरह, \uxxxxकार्यक्रम के अन्य भाग में उपयोग करने का कोई मतलब नहीं है । एकमात्र अपवाद संभवत: सार्वजनिक एपीआई में है, जिसमें कुछ गैर-अस्की चर को समाहित किया जाता है - आखिरी बार हमने क्या देखा है?

1995 में डिजाइनरों के पास इसके कारण थे, लेकिन 20 साल बाद, यह एक गलत विकल्प प्रतीत होता है।

(पाठकों से सवाल - इस सवाल को नए वोट क्यों मिलते रहते हैं? क्या यह सवाल कहीं से जुड़ा है?)

Comments

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

— होल्गर

वे उचित फ़ाइल एन्कोडिंग का उपयोग कर सकते हैं। int \u5431जब आप कर सकते हैं तो क्यों लिखेंint 整

— झोंग्याऊ

जब आपको उनके एपीआई के खिलाफ कोड संकलित करना होगा तो आप क्या करेंगे और उचित एन्कोडिंग का उपयोग नहीं कर सकते (मान लें कि UTF-81995 में व्यापक समर्थन नहीं था )। आपको बस एक विधि को कॉल करना है और उस एकल पद्धति के लिए अपने ऑपरेटिंग सिस्टम (याद रखें, नब्बे के दशक) के एशियाई भाषा समर्थन पैक को स्थापित नहीं करना है ...

— Holger

1995 की तुलना में अब बहुत स्पष्ट है कि यदि आप कार्यक्रम करना चाहते हैं तो आप अंग्रेजी जानते हैं। प्रोग्रामिंग एक अंतरराष्ट्रीय बातचीत है, और लगभग सभी संसाधन अंग्रेजी में हैं।

— ZhongYu

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

— होल्गर

Answer 7

केवल वे लोग ही जवाब दे सकते हैं कि यूनिकोड के पलायन को क्यों लागू किया गया क्योंकि वे ऐसे लोग थे जिन्होंने विनिर्देश लिखा था।

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

• आप किसी भी BMP वर्ण का उपयोग करने में सक्षम होना चाहते हैं।
• आप किसी भी BMP charater को आसान तरीके से इनपुट करने में सक्षम होना चाहते हैं। ऐसा करने का एक तरीका है यूनीकोड ​​पलायन।
• आप मनुष्यों के पढ़ने और लिखने के लिए शाब्दिक विनिर्देशन को आसान रखना चाहते हैं, और यथोचित रूप से लागू करना आसान है।

यह अविश्वसनीय रूप से मुश्किल है जब यूनिकोड बच जाता है तो मैदान में प्रवेश करता है: यह नए लेसर नियमों का एक पूरा भार बनाता है।

आसान तरीका यह है कि दो चरणों में लेक्सिंग करें: पहले खोज करें और सभी यूनिकोड को उस वर्ण के साथ भाग दें, जो इसके द्वारा निरूपित होता है और फिर परिणामी दस्तावेज़ को पार्स करता है जैसे कि यूनिकोड बचता नहीं है।

इसका उल्टा यह है कि यह निर्दिष्ट करना आसान है, इसलिए यह विनिर्देशन को सरल बनाता है, और इसे लागू करना आसान है।

नकारात्मक पक्ष यह है, ठीक है, आपका उदाहरण।

Comments

या, पहचानकर्ताओं, स्ट्रिंग शाब्दिक और वर्ण स्थिरांक के लिए \ uxxxx के उपयोग को प्रतिबंधित करें। जो C11 करता है।

— नंजल

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

— Martijn