UTF-8 के लिए तर्क: यह बहुत आसान है। जावास्क्रिप्ट में एन्कोडर और डिकोडर । फिर से, UTF-8 यूनिकोड नहीं है ।

यूटीएफ -8 के खिलाफ तर्क: यह लंबाई + बाइट्स से थोड़ा अधिक जटिल है, जिससे संभावित कार्यान्वयन विचलन होता है।

फिर से, UTF-8 यूनिकोड नहीं है।

तुम कह भी क्या रहे हो? यह एक बेतुका वाक्य है।

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

लेकिन UTF-8 वस्तुतः एक यूनिकोड एन्कोडिंग है; आपका कथन लिखित के रूप में अर्थहीन है। ^_^

लेकिन UTF-8 वस्तुतः एक यूनिकोड एन्कोडिंग है; आपका कथन लिखित के रूप में अर्थहीन है। ^_^

हां, मैं विशेष रूप से कोडपॉइंट एन्कोडिंग का जिक्र कर रहा हूं जो यूटीएफ -8 वर्णन करता है, न कि कोडपॉइंट्स का उचित उपचार (इस प्रस्ताव के उद्देश्य के लिए, एक कोडपॉइंट एक अपारदर्शी पूर्णांक है)। wasm-isms में रखें, UTF-8 var[u]int के समान है, लेकिन पात्रों के लिए अधिक उपयुक्त है। इसके अलावा, UTF-8 केवल यूनिकोड एन्कोडिंग नहीं है, और इसका उपयोग गैर-यूनिकोड पूर्णांकों को एन्कोड करने के लिए किया जा सकता है। तो, यूटीएफ -8 यूनिकोड नहीं है।

एक और प्रस्ताव अलग-अलग कोडपॉइंट्स को देखेगा और उनके साथ कुछ करेगा। यह वह प्रस्ताव नहीं है।

और कोई कारण नहीं होगा। किसी भी वेब एपीआई को सख्त समानता तुलना और छँटाई से परे कोडपॉइंट पर आत्मनिरीक्षण करने की आवश्यकता नहीं मिली है, जब तक कि यह सचमुच एक i18n एपीआई नहीं है।

प्रत्येक कोड बिंदु के लिए एक और विकल्प बाइट लम्बाई + यूटीएफ -8 है ( @jfbastien जब तक कि आपका मतलब यह नहीं है जब आपने प्रत्येक बाइट के लिए यूटीएफ -8 कहा था, जिसे मैं मानता हूं कि मुझे समझ में नहीं आया)। मुझे नहीं लगता कि यह एक आदिम पार्सर के लिए चीजों को और अधिक कठिन बना देगा जो वास्तव में परवाह नहीं करता है, जबकि एक परिष्कृत यूनिकोड लाइब्रेरी को बाइट सरणी, ऑफसेट और लंबाई इनपुट के रूप में लेने और एक स्ट्रिंग वापस करने की इजाजत देता है।

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

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

यहां अंतर्निहित मुद्दों और उनके कारणों को संक्षेप में प्रस्तुत करने का प्रयास किया गया है। सुधार और परिवर्धन का स्वागत है।

क्या wasm को मॉड्यूल आयात/निर्यात पहचानकर्ताओं को मान्य UTF-8 की आवश्यकता होनी चाहिए?

इसके खिलाफ कारणों की मेरी समझ है:

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

क्या उन क्षेत्रों में यूटीएफ -8 की सिफारिश करनी चाहिए जहां इसकी आवश्यकता नहीं है?

इसका कारण यह होगा कि भले ही हमें इसकी आवश्यकता न हो, UTF-8 का उल्लेख करने से पारिस्थितिकी तंत्र के बीच अनावश्यक असंगतियों को हतोत्साहित किया जा सकता है।

इसके खिलाफ कारण के बारे में मेरी समझ यह है कि यूटीएफ -8 का उल्लेख भी स्ट्रिंग व्याख्या चिंताओं के वैचारिक encapsulation से समझौता करेगा।

क्या wasm को नाम-अनुभाग नामों के लिए UTF-8 निर्दिष्ट करना चाहिए?

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

इसके विरुद्ध कारण के बारे में मेरी समझ यह है: यदि wasm के पास अन्य क्षेत्रों में अन्य स्ट्रिंग जैसी चीजें हैं जिनके पास निर्दिष्ट एन्कोडिंग नहीं है (यानी ऊपर चर्चा की गई आयात/निर्यात), तो स्थिरता के लिए इसे किसी भी स्ट्रिंग के लिए एन्कोडिंग नामित नहीं करना चाहिए .

@sunfishcode एक अच्छा सारांश प्रदान करता है, लेकिन मैं तीन महत्वपूर्ण बिंदु जोड़ना चाहता हूं।

@jfbastien ,

@tabatkins , मुझे लगता है कि आपके तर्क में एक डोमेन त्रुटि है। हम जिन स्ट्रिंग्स के बारे में बात कर रहे हैं उनमें से कोई भी _user-faced_ नहीं है। वे _देव-सामना_नाम हैं। कई/अधिकांश प्रोग्रामिंग भाषाएं यूनिकोड पहचानकर्ताओं का समर्थन नहीं करती हैं, न ही उपकरण। उदाहरण के लिए जीडीबी यूनिकोड स्रोत पहचानकर्ताओं को संभाल सकता है? मुझे ऐसा नहीं लगता। इसलिए यह मान लेना काफी आशावादी (या बल्कि, अवास्तविक) है कि सभी उपभोक्ताओं ने यूनिकोड _इस स्पेस_ में अभिसरण किया है।

और अंत में, असहमति यह नहीं है कि वेब पर वासम को यूटीएफ -8 मान लेना चाहिए, लेकिन _कहां_ हम इसे निर्दिष्ट करते हैं।

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

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

अगर आपको लगता है कि बहुत सारे टूलचेन यूनिकोड को समझने नहीं जा रहे हैं, तो मुझे यकीन नहीं है कि आपको क्यों लगता है कि वे किसी अन्य मनमानी बाइनरी एन्कोडिंग को समझेंगे। यदि यह आपकी सीमा है, तो बस ASCII निर्दिष्ट करें और इसकी आवश्यकता है, जो हर जगह 100% समर्थित है। यदि आप अपने आप को ASCII तक सीमित करने के लिए तैयार नहीं हैं, तो आपको यह स्वीकार करने की आवश्यकता है कि एक स्वीकृत गैर-ASCII एन्कोडिंग योजना है - UTF-8।

कह रही है "हाँ, सबसे बातें शायद केवल ASCII का समर्थन है, लेकिन हम devs डाल जो कुछ भी वे वहाँ में सिर्फ मामले में चाहते दूँगा" दोनों दुनिया का सबसे खराब है।

"एह, ज्यादातर चीजें शायद केवल एएससीआईआई का समर्थन करती हैं, लेकिन हम देवों को जो कुछ भी चाहते हैं उसे वहां डाल देंगे" दोनों दुनिया में सबसे खराब है।

@tabatkins , कोई भी उपरोक्त का प्रस्ताव नहीं कर रहा है। जैसा कि मैंने कहा, सवाल यह नहीं है कि ऐसे प्लेटफॉर्म/पर्यावरण-विशिष्ट मामलों को परिभाषित करने के लिए _चाहे_बल्कि _कहां_है। Wasm को वातावरण की सबसे विस्तृत और सबसे विषम श्रेणी में एम्बेड करने योग्य माना जाता है, कुछ दूसरों की तुलना में अधिक समृद्ध (उदाहरण के लिए, JS _does_ यूनिकोड पहचानकर्ताओं का समर्थन करता है)। नतीजतन, आप प्रति-प्लेटफ़ॉर्म आधार पर चुनने की अनुमति देना चाहते हैं। इसलिए यह प्लेटफॉर्म एपीआई स्पेक्स में है न कि कोर स्पेक।

बनाने के लिए कोई विकल्प नहीं है, वैसे! यदि आपका एम्बेडिंग वातावरण गैर-ASCII का समर्थन नहीं करता है, तो आप अपने स्ट्रिंग्स में गैर-ASCII का उपयोग नहीं करते हैं । (और यदि ऐसा है, तो आपको अभी भी एन्कोडिंग आश्वासन की आवश्यकता है - उदाहरण के लिए, UTF-16 ASCII-संगत नहीं है!)

यदि आपका वातावरण गैर-ASCII का समर्थन करता है, तो आपको यह जानना होगा कि किस एन्कोडिंग का उपयोग करना है, और सभी स्थितियों में सही विकल्प UTF-8 है।

आप किस पर्यावरण की कल्पना कर रहे हैं जहां आपके तारों के एन्कोडिंग को नहीं जानने का लाभ है?

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

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

दोबारा, यदि आप इन नामों को केवल ASCII तक सीमित रखने के लिए ठीक हैं, तो एन्कोडिंग को यूएस-एएससीआईआई होना अनिवार्य है। यदि आप चाहते हैं कि एएससीआईआई से आगे जाना संभव हो, तो एन्कोडिंग को यूटीएफ -8 होना अनिवार्य है। कुछ और अनिवार्य करना, या कुछ भी अनिवार्य नहीं करना (और सभी उपभोक्ताओं को अनुमान लगाने या आउट-ऑफ-बैंड जानकारी का उपयोग करने के लिए मजबूर करना), केवल अनुचित संभावनाएं हैं।

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

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

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

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

व्यावहारिक रूप से, भले ही हमने कोर वासम स्पेक में utf8 को अनिवार्य नहीं किया हो, यदि आपके कस्टम टूलचेन ने utf8 का उपयोग नहीं किया है, तब तक आपके पास कुछ भी खराब समय होगा जब तक कि आप कुल द्वीप न हों और फिर शायद आप कहें "इसे पेंच करें" और वैसे भी अपना गैर-utf8 काम करें ... क्योंकि तब कौन परवाह करता है।

हालांकि, मैं वास्तव में क्या करना चाहता

@lukewagner मुझे नहीं लगता कि #984 इस पर अवरुद्ध है। मैं

मुझे लगता हे तुम सही हो।

आप किस पर्यावरण की कल्पना कर रहे हैं जहां आपके तारों के एन्कोडिंग को नहीं जानने का लाभ है?

@tabatkins , ऐसा लगता है कि मैं अभी भी पर्याप्त स्पष्ट नहीं हुआ हूं। मैं ऐसे माहौल की कल्पना नहीं करता। हालांकि, मैं असंगत आवश्यकताओं वाले वातावरण के व्यापक स्पेक्ट्रम की कल्पना करता हूं। सब कुछ UTF-8 का उपसमुच्चय नहीं है, उदाहरण के लिए लैटिन1 अभी भी काफी व्यापक उपयोग में है। आप परवाह नहीं कर सकते हैं, लेकिन पर्यावरण विविधता के रास्ते में अनावश्यक पत्थरों को डालना मूल वासम युक्ति का काम नहीं है।

यदि आपका कस्टम टूलचेन भी utf8 का उपयोग नहीं करता है, जब तक कि आप कुल द्वीप नहीं हैं, तो आपके पास कुछ भी खराब समय होगा

@lukewagner , मैं वास्तव में उम्मीद करता हूं कि

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

कुछ परिवेशों को अनुमत सामग्री को और प्रतिबंधित करने की अनुमति देने में मूल्य हो सकता है, लेकिन UTF-8 की आवश्यकता नहीं होने से केवल अधिक कठिनाई होगी।

@ MI3Guy , काउंटर प्रस्ताव जेएस एपीआई के हिस्से के रूप में यूटीएफ -8 एन्कोडिंग निर्दिष्ट करना है। तो यदि आप एक जेएस एम्बेडिंग बना रहे हैं तो इसे यूटीएफ -8 के रूप में परिभाषित किया गया है और इससे आपके लिए कोई फर्क नहीं पड़ता है। (हालांकि, हम अन्य एम्बेडर एपीआई के लिए भी अनुमति देना चाहते हैं जो न तो वेब हैं और न ही जावास्क्रिप्ट।)

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

प्रत्येक कोडपॉइंट के लिए कोडपॉइंट्स + UTF-8 की संख्या के लिए varuint करें।

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

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

सही; एक बार जब आप ASCII श्रेणी छोड़ देते हैं तो UTF-8 लगभग हर एन्कोडिंग से भिन्न होता है। मुझे यकीन नहीं है कि इसके साथ आपका क्या मतलब है। वास्तव में लैटिन -1 एन्कोडिंग का उपयोग करना ठीक नहीं है क्योंकि बहुत सारे अन्य एनकोडिंग हैं जो समान दिखते हैं लेकिन विभिन्न अक्षरों को एन्कोड करते हैं । यदि आपने अपने Wasm कोड में "æther" नाम का उपयोग करने का प्रयास किया है, और इसे लैटिन -1 में एन्कोड किया है, तो कोई और (उचित रूप से) UTF-8 टूलचेन के साथ नाम पढ़ने की कोशिश करता है, उन्हें एक डिकोडिंग त्रुटि मिलेगी। या हो सकता है कि दूसरा व्यक्ति भी इसी तरह की गलती कर रहा था, लेकिन इसके बजाय विंडोज-1250 एन्कोडिंग का इस्तेमाल किया (मध्य/पूर्वी यूरोपीय भाषाओं के लिए अभिप्रेत) - उन्हें बकवास शब्द "ćther" मिलेगा।

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

मैं आपको बताता रहता हूं कि वेब मानकों ने इस प्रश्न को वर्षों पहले सुलझा लिया था, इसलिए नहीं कि वासम एक वेब युक्ति है जिसे वेब नियमों का पालन करने की आवश्यकता है, बल्कि इसलिए कि टेक्स्ट एन्कोडिंग एक पारिस्थितिकी तंत्र की समस्या है जिससे लगभग सभी को समान समस्याएं होती हैं, और वेब पहले से ही निपटा हुआ है यह गलत होने के दर्द के साथ, और इसे सही तरीके से करना सीख लिया है। वासम में इसे फिर से गलत करने में कोई गुण नहीं है; प्रत्येक वातावरण जिसे पाठ को एन्कोड करना होता है या तो शुरुआत से सीधे UTF-8 में चला जाता है, या वही गलतियाँ करता है और वही दर्द सहता है जो बाकी सभी करते हैं, और फिर अंततः UTF-8 पर बस जाते हैं। (या, दुर्लभ मामलों में, एक पर्याप्त रूप से पृथक वातावरण विकसित करता है जिसे वे एक अलग एन्कोडिंग पर मानकीकृत कर सकते हैं, और केवल शायद ही कभी बाहरी वातावरण के साथ संचार करने की कीमत चुकाते हैं। लेकिन वे एक एन्कोडिंग पर मानकीकृत करते हैं , जो इस सब का बिंदु है।)

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

इस मुद्दे का वेब या जेएस से कोई लेना-देना नहीं है। पारिस्थितिकी तंत्र का प्रत्येक भाग एक ज्ञात, सुसंगत पाठ एन्कोडिंग चाहता है, और एक एकल है जो प्रोग्रामिंग वातावरण, देशों और भाषाओं में व्यापक रूप से सहमत है: UTF-8।

मैं 'प्रत्येक बाइट के लिए लंबाई के लिए varuint (बाइट्स में) + UTF-8' के लिए वोट करता हूं। यह मानते हुए कि यह एक विवादास्पद विकल्प नहीं है - बहुत अधिक प्रत्येक स्ट्रिंग कार्यान्वयन स्ट्रिंग्स को "कोड इकाइयों की संख्या" के बजाय "कोड इकाइयों की संख्या" के रूप में संग्रहीत करता है, क्योंकि यह सरल है - फिर वास्तविक प्रश्न नहीं है "यदि स्ट्रिंग नहीं है तो सत्यापन विफल होना चाहिए वैध यूटीएफ -8"?

जैसा कि मैंने #970 में बताया, अमान्य UTF-8 को UTF-16 में

कुल मिलाकर मैं यह कहना चाहता हूं कि आइए यूटीएफ -8 को अनिवार्य करें। अजीब मामले में कि किसी के पास बाइट हैं, वे यूटीएफ -8 में अनुवाद नहीं कर सकते हैं (शायद क्योंकि एन्कोडिंग अज्ञात है), मनमानी बाइट्स को यूटीएफ -8 में अनुवादित किया जा सकता है।

मुझे सच में यकीन नहीं है कि आप किस तरह की "विविधता" की रक्षा करने की कोशिश कर रहे हैं।

@tabatkins , हाँ, यह गलतफहमी का मूल प्रतीत होता है।

यह महसूस करना महत्वपूर्ण है कि WebAssembly, अपने नाम के बावजूद, वेब तक ही सीमित नहीं है। हम इसे उपयुक्त परतों में परिभाषित करने के लिए बहुत सतर्क हैं, जैसे कि प्रत्येक परत यथासंभव व्यापक रूप से प्रयोग करने योग्य है।

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

इस प्रकार, _core_ Wasm पर यूनिकोड थोपने का कोई मतलब नहीं है, जैसा कि यह कहना होगा, C प्रोग्रामिंग भाषा में सभी स्ट्रिंग शाब्दिकों पर यूनिकोड को लागू करना। आप केवल कुछ संभावित ग्राहकों को मानक के इस बिट का उल्लंघन करने के लिए बाध्य करेंगे। क्या फायदा?

हालांकि, इस कोर स्पेक के शीर्ष पर अतिरिक्त विशिष्ट परतें होंगी जो _concrete_ वातावरण (जैसे जावास्क्रिप्ट) में इसके एम्बेडिंग और एपीआई को परिभाषित करती हैं। उस स्तर पर स्ट्रिंग एन्कोडिंग को ठीक करना सही समझ में आता है, और हर तरह से, हमें करना चाहिए।

पुनश्च: एक नारा जो वासम के दायरे को परिभाषित करता है वह यह है कि यह सामान्य हार्डवेयर पर एक अमूर्त है, सामान्य प्रोग्रामिंग भाषाओं पर एक अमूर्त नहीं है। और हार्डवेयर स्ट्रिंग एन्कोडिंग जैसी सॉफ़्टवेयर चिंताओं के लिए अज्ञेयवादी है। यही एबीआई के लिए है।

@ रॉसबर्ग-क्रोमियम

इस प्रकार, सी प्रोग्रामिंग भाषा में सभी स्ट्रिंग अक्षर पर यूनिकोड को लागू करने के लिए, कोर वासम पर यूनिकोड को लागू करने का कोई और अर्थ नहीं है। आप केवल कुछ संभावित ग्राहकों को मानक के इस बिट का उल्लंघन करने के लिए बाध्य करेंगे। क्या फायदा?

मैं 100% सहमत हूँ। यह मुद्दा यूनिकोड के बारे में नहीं है, हालांकि यह पूरी तरह से यूटीएफ -8 के बारे में है, पूर्णांक के लिए एक एन्कोडिंग , यह अनिवार्य किए बिना कि पूर्णांक को यूनिकोड के रूप में व्याख्या किया जाना चाहिए।

मुझे समझ में नहीं आता कि क्या हम उस पर सहमत हैं। क्या आप स्पष्ट कर सकते हैं: क्या आप यूटीएफ -8 के साथ ठीक हैं, और यदि नहीं तो क्यों?

@jfbastien , क्या सभी सी स्ट्रिंग

जैसा कि मैंने पहले उल्लेख किया है, मेरे लिए एन्कोडिंग को प्रतिबंधित करने का कोई मतलब नहीं है, लेकिन चरित्र सेट को नहीं। यह शब्दार्थ के बिना वाक्य रचना को परिभाषित करने जैसा है। आप ऐसा क्यों करेंगे? आप इंटरऑप के मामले में शून्य प्राप्त करते हैं लेकिन फिर भी उन वातावरणों के लिए कृत्रिम बाधाएं खड़ी करते हैं जो यूटीएफ -8 का उपयोग नहीं करते हैं (जो कि केवल यूनिकोड वातावरण ही करते हैं)।

@jfbastien , क्या सभी सी स्ट्रिंग

मुझे समझ में नहीं आया, क्या आप स्पष्ट कर सकते हैं?

जैसा कि मैंने पहले उल्लेख किया है, मेरे लिए एन्कोडिंग को प्रतिबंधित करने का कोई मतलब नहीं है, लेकिन चरित्र सेट को नहीं। यह शब्दार्थ के बिना वाक्य रचना को परिभाषित करने जैसा है। आप ऐसा क्यों करेंगे? आप इंटरऑप के मामले में शून्य प्राप्त करते हैं लेकिन फिर भी उन वातावरणों के लिए कृत्रिम बाधाएं खड़ी करते हैं जो यूटीएफ -8 का उपयोग नहीं करते हैं (जो कि केवल यूनिकोड वातावरण ही करते हैं)।

मुझे लगता है कि चर्चा की जड़ है।

@tabatkins ने

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

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

तो मैं सहमत हूं: यह प्रस्ताव, आपके शब्दों में, "शब्दार्थ के बिना वाक्य रचना को परिभाषित करना" है। ऐसा करना बहुत आम बात है। वास्तव में, WebAssembly की वर्तमान लंबाई + बाइट्स विनिर्देश पहले से ही ऐसा करता है!

मैं समझना चाहता हूं कि बाधा क्या है। मैं वास्तव में एक नहीं देखता।

यह महसूस करना महत्वपूर्ण है कि WebAssembly, अपने नाम के बावजूद, वेब तक ही सीमित नहीं है।

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

इस प्रकार, सी प्रोग्रामिंग भाषा में सभी स्ट्रिंग अक्षर पर यूनिकोड को लागू करने के लिए, कोर वासम पर यूनिकोड को लागू करने का कोई और अर्थ नहीं है। आप केवल कुछ संभावित ग्राहकों को मानक के इस बिट का उल्लंघन करने के लिए बाध्य करेंगे। क्या फायदा?

आप बिंदु क्या आप की दिशा में सोचना नहीं कर रहे हैं - सी है एक अंतर्निहित एन्कोडिंग, के रूप में स्ट्रिंग शाब्दिक ASCII एन्कोडिंग का उपयोग करें। (यदि आप कुछ और चाहते हैं तो आपको उचित बाइट अनुक्रमों से बचकर इसे हाथ से करना होगा।) अधिक वर्तमान सी ++ में आपके पास यूटीएफ -16 और यूटीएफ -8 स्ट्रिंग अक्षर हो सकते हैं, और जब भी आप स्ट्रिंग में मनमानी बाइट्स डाल सकते हैं \x बच निकलता है, \u बच निकलता है कम से कम सत्यापित करें कि मान एक वैध कोडपॉइंट है।

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

आप इंटरऑप के मामले में शून्य प्राप्त करते हैं लेकिन फिर भी उन वातावरणों के लिए कृत्रिम बाधाएं खड़ी करते हैं जो यूटीएफ -8 का उपयोग नहीं करते हैं (जो कि केवल यूनिकोड वातावरण ही करते हैं)।

क्या आप कृपया ऐसे अस्तित्व की ओर संकेत कर सकते हैं जो ऐसे वर्णों का उपयोग करता है जो यूनिकोड में शामिल नहीं हैं? आप सैद्धांतिक शुद्धता/पर्यावरण विविधता के दृष्टिकोण से इस स्थिति की रक्षा करने की कोशिश करते रहते हैं, लेकिन वस्तुतः यूनिकोड का संपूर्ण बिंदु सभी वर्णों को शामिल

आप किस विविधता की रक्षा करने का प्रयास कर रहे हैं? एक भी उदाहरण देखकर अच्छा लगेगा। :/

@tabatkins :

यह महसूस करना महत्वपूर्ण है कि WebAssembly, इसके नाम के बावजूद, नहीं है
वेब तक सीमित।

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

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

आप बिंदु आप आपको लगता है की दिशा नहीं कर रहे हैं - सी एक है

अंतर्निर्मित एन्कोडिंग, क्योंकि स्ट्रिंग अक्षर ASCII एन्कोडिंग का उपयोग करते हैं। (अगर आप चाहते हैं
उपयुक्त बाइट से बचकर आपको कुछ और हाथ से करना होगा
अनुक्रम।) अधिक वर्तमान सी ++ में आपके पास यूटीएफ -16 और यूटीएफ -8 स्ट्रिंग हो सकती है
शाब्दिक, और जब आप अभी भी मनमाने ढंग से बाइट्स को स्ट्रिंग में डाल सकते हैं
\x बच निकलता है, \u बच निकलता है कम से कम सत्यापित करें कि मान एक मान्य है
कोडप्वाइंट

नहीं, यह गलत है। सी स्पेक को एएससीआईआई की आवश्यकता नहीं है। यह भी नहीं
ASCII के साथ संगतता की आवश्यकता है। यह लगभग मनमाना "source ." की अनुमति देता है
कैरेक्टर सेट" और स्ट्रिंग लिटरल में फुल से कोई भी कैरेक्टर हो सकता है
सेट। एन्कोडिंग के संबंध में कोई बाधा नहीं है, यह पूरी तरह से है
कार्यान्वयन-परिभाषित। सी के कार्यान्वयन चल रहे हैं
EBCDIC प्लेटफॉर्म, और वह अभी भी वर्तमान मानक द्वारा समर्थित है। जीसीसी
किसी भी iconv एन्कोडिंग में स्रोतों को संसाधित कर सकते हैं (जिनमें से लगभग 140 . हैं)
UTF-8 के अलावा), जैसे UTF-16 जो एशिया में लोकप्रिय है। सी ++ अलग नहीं है।

(यह भी @jfbastien के प्रश्न का उत्तर देना चाहिए।)

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

पुन:: यह _will_ प्रति परिवेश उपयुक्त रूप से निर्दिष्ट किया जाएगा। जब कोई
उसी पारिस्थितिकी तंत्र में काम कर रहे किसी अन्य व्यक्ति से Wasm मॉड्यूल प्राप्त करता है
तब कोई समस्या नहीं है। किसी जेएस देव को कभी भी देखभाल करने की आवश्यकता नहीं होगी।

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

आप इंटरऑप के मामले में शून्य प्राप्त करते हैं लेकिन फिर भी इसके लिए कृत्रिम बाधाएं खड़ी करते हैं

वातावरण जो UTF-8 का उपयोग नहीं करते हैं (जो केवल यूनिकोड वातावरण करते हैं
वैसे भी)।

क्या आप कृपया किसी ऐसे अस्तित्व की ओर संकेत कर सकते हैं जो उपयोग करता है
वर्ण जो यूनिकोड में शामिल नहीं हैं? आप इसका बचाव करने की कोशिश करते रहें
सैद्धांतिक शुद्धता/पर्यावरण विविधता के दृष्टिकोण से स्थिति, लेकिन
वस्तुतः यूनिकोड का संपूर्ण बिंदु सभी को शामिल

ऐसा करने के लिए विश्वसनीय तर्क, और जब आप यूनिकोड वर्ण का उपयोग कर रहे हों
सेट, यूटीएफ -8 पसंदीदा सार्वभौमिक एन्कोडिंग है।

आप किस विविधता की रक्षा करने का प्रयास कर रहे हैं? यह देखना भी बहुत अच्छा होगा
एक एकल उदाहरण। :/

उदाहरण के लिए, यहाँ एम्बेडेड OSes की एक सूची है: https://en.wikipedia.org/wiki/
श्रेणी:एम्बेडेड_ऑपरेटिंग_सिस्टम्स
उनमें से कुछ संभवतः यूटीएफ -8 का उपयोग करते हैं, कुछ नहीं करेंगे। कुछ को Wasm का उपयोग मिल सकता है,
सबसे शायद नहीं होगा। लेकिन इसे कम करने से हमें कोई फायदा नहीं है
उनके लिए सुविधाजनक।

उस सूची में से एक प्रविष्टि जिसे आप शायद अभी भी परिचित हैं, वह है डॉस। जैसा
जितना हम सभी इसे मरना पसंद करते हैं, डॉस सिस्टम अभी भी जीवंत हैं, और वे उपयोग करते हैं
ओईएम।

@jfbastien :

तो मैं सहमत हूं: यह प्रस्ताव आपके शब्दों में है, "बिना वाक्य रचना को परिभाषित करना
शब्दार्थ"। ऐसा करना एक बहुत ही सामान्य बात है। वास्तव में, WebAssembly's
वर्तमान लंबाई + बाइट्स विनिर्देश पहले से ही ऐसा करता है!

इस तरह की दुर्लभ घटनाएँ जिनसे मैं सभी वाकिफ हूं, का संबंध है
कार्यान्वयन-विशिष्ट व्यवहार के लिए एस्केप हैच प्रदान करना। वह है
एकमात्र उचित उपयोग का मामला भी। हालांकि यहां इसका कोई मतलब नहीं है। अगर तुम
स्ट्रिंग्स के लिए ऐसी एस्केप हैच प्रदान करना चाहते हैं, तो परेशान करने की आवश्यकता क्यों है
UTF-8, किसी भी बाइट स्ट्रिंग "वाक्यविन्यास" की अनुमति देने के बजाय? बिना वाक्य रचना है
एक अक्षमकर्ता के रूप में शब्दार्थ, एक प्रवर्तक नहीं।

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

मुझे दूसरे तरीके से पूछने दें: (उनके इको सिस्टम में) क्या लाभ है?
मैं वास्तव में एक नहीं देखता।

@tabatkins
मैं यह सुनिश्चित करना चाहता हूं कि मैं समझता हूं कि विभाजन रेखा कहां है।
स्पष्ट होने के लिए आप कोड बिंदुओं के केवल utf-8 एन्कोडिंग का सुझाव दे रहे हैं, भले ही वे संयोजन में अमान्य हों (जो कोड की 10 पंक्तियों में किया जा सकता है)।
उदाहरण के लिए बोल्ड कैप का उपयोग यह इंगित करने के लिए किया जा सकता है: आप कुछ गलत कर रहे हैं यदि आपको लगता है कि आपको Wasm को लागू करने के लिए एक अंतर्राष्ट्रीयकरण पुस्तकालय की आवश्यकता है?

इसके लक्ष्य होंगे:

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

प्रशन?

• क्या कोई खतरा है कि यह अधिक सत्यापन के लिए एक रेंगने वाली आवश्यकता बन जाती है? मुझे लगता है कि इस जगह में मेरी मुख्य चिंता यह होगी कि आईसीयू को एक निर्भरता के रूप में निगलना हमेशा एक अनुचित बोझ होगा।

• मुझे लगता है कि इसका तात्पर्य लैटिन 1 जैसे एन्कोडिंग को सक्रिय रूप से प्रोत्साहित करने का लक्ष्य है जो यूटीएफ -8 के साथ संघर्ष करता है? यानी टूलचेन जो इसे उत्सर्जित करते हैं, वे गैर-अनुपालन होंगे, कार्यान्वयन जो इसे समान रूप से स्वीकार करते हैं।

• मुझे लगता है कि वेब को ऐतिहासिक रूप से उन क्षेत्रों से बिट्स के अतिव्यापी उपयोग के कारण इस स्थान को एकीकृत करने में परेशानी हुई है जो पहले द्वीपों को एन्कोडिंग कर रहे थे। दूसरी तरफ, मेरी धारणा यह है कि यूटीएफ -8 ऐसी चीजें सेट करता है जैसे संक्रमण की लागत गैर-एएससीआईआई लोगों द्वारा असमान रूप से पैदा होती है, और कुछ क्षेत्रों में अधिक सेंकना होता है। मुझे लगता है कि यूनिकोड संक्रमण एक व्यावहारिक अनिवार्यता है (और लगभग पूर्ण)। क्या कोई केंद्रीकृत दस्तावेज़/इकाई है जिसे हम उस पते पर इंगित कर सकते हैं कि वेब पर यूनिकोड के आसपास के कुछ राजनीतिक और क्षेत्रीय मुद्दों को कैसे हल किया गया है?

@ रॉसबर्ग-क्रोमियम

• मुझे एन्कोडिंग के कुछ पहलुओं को मान्य करने में तार्किक असंगति दिखाई देती है लेकिन अन्य नहीं। दूसरी ओर मेरी धारणा है कि utf8 इस बिंदु पर व्यापक है (और यह कि उपकरण में एक छोटी सी कुहनी से हलका धक्का + सत्यापन की लागत कम है)। क्या आपकी मुख्य असुविधा बेयर यूटीएफ -8 सत्यापन को असंगतता या कुछ और के लिए जोड़ रही है?

स्पष्ट होने के लिए आप कोड बिंदुओं के केवल utf-8 एन्कोडिंग का सुझाव दे रहे हैं, भले ही वे संयोजन में अमान्य हों (जो कोड की 10 पंक्तियों में किया जा सकता है)।

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

उदाहरण के लिए बोल्ड कैप का उपयोग यह इंगित करने के लिए किया जा सकता है: आप कुछ गलत कर रहे हैं यदि आपको लगता है कि आपको Wasm को लागू करने के लिए एक अंतर्राष्ट्रीयकरण पुस्तकालय की आवश्यकता है?

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

क्या कोई खतरा है कि यह अधिक सत्यापन के लिए एक रेंगने वाली आवश्यकता बन जाती है? मुझे लगता है कि इस जगह में मेरी मुख्य चिंता यह होगी कि आईसीयू को एक निर्भरता के रूप में निगलना हमेशा एक अनुचित बोझ होगा।

वेब प्लेटफॉर्म को अब तक नंगे नामों पर अतिरिक्त सत्यापन लागू करने की आवश्यकता नहीं है। मेरा अनुभव बताता है कि इसकी कभी आवश्यकता नहीं होगी।

मुझे लगता है कि यह लैटिन 1 जैसे सक्रिय रूप से [डिस-एड] साहसी एन्कोडिंग के लक्ष्य का तात्पर्य है जो यूटीएफ -8 के साथ संघर्ष करता है? यानी टूलचेन जो इसे उत्सर्जित करते हैं, वे गैर-अनुपालन होंगे, कार्यान्वयन जो इसे समान रूप से स्वीकार करते हैं।

हाँ, अपने शब्दों में करने के लिए "जिले couraging" परिवर्तन के साथ। ^_^ पूरी बात यह है कि निर्माता और उपभोक्ता दूसरे एंडपॉइंट क्या कर रहे हैं, इसका अनुमान लगाए बिना बाइट अनुक्रमों से/से स्ट्रिंग्स को मज़बूती से एन्कोड और डिकोड कर सकते हैं। यह हर उस वातावरण के लिए एक भयानक दर्द रहा है जिसने कभी इसका सामना किया है, और अब इसके लिए व्यापक रूप से अपनाया गया समाधान है।

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

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

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

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

"यूनिकोड संक्रमण" के लिए, जो पहले से ही बहुत सार्वभौमिक रूप से हो चुका है। एक टेक्स्ट प्रारूप जिसे इन दिनों यूटीएफ -8 के साथ एन्कोड करने की आवश्यकता नहीं है, एक भयानक, ऐतिहासिक गलती कर रहा है।

मैं किसी भी विशिष्ट दस्तावेज़ के बारे में निश्चित नहीं हूं जो इस सामान की रूपरेखा तैयार करता है, लेकिन मैं शर्त लगा सकता हूं कि वे कहीं मौजूद हैं। ^_^

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

इसके बजाय, JavaScript विनिर्देशन में एक अनिवार्य कस्टम अनुभाग जोड़ें जिसके लिए UTF-8 की आवश्यकता होती है। अन्य परिवेश, जैसे कि सोवियत-युग का मेनफ्रेम, जिसका @ रोसबर्ग-क्रोमियम संकेत कर रहा है, अपने स्वयं के कस्टम अनुभाग को परिभाषित कर सकते हैं। एक एकल WASM फ़ाइल दोनों कस्टम अनुभाग प्रदान करके दोनों प्लेटफार्मों का समर्थन कर सकती है। कस्टम टूलिंग के लिए यह अपेक्षाकृत सरल होगा कि एक अधिक लोकप्रिय एक को परिवर्तित करके एक अस्पष्ट प्लेटफॉर्म के लापता अनुभाग को उत्पन्न किया जाए।

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

यह एक पुनर्विक्रय है कि आयात/निर्यात कैसे काम करता है। यह मेज पर नहीं है और इसे इस मुद्दे से भिन्न मुद्दे में सुझाया जाना चाहिए।

@bradnelson , AFAICS, एक विशिष्ट एन्कोडिंग निर्धारित करता है लेकिन कोई वर्ण सेट नहीं है
दोनों दुनिया के सबसे बुरे को जोड़ती है: यह के संदर्भ में लागत लगाता है
प्रतिबंध, जटिलता, और ओवरहेड के संदर्भ में कोई वास्तविक लाभ नहीं है
इंटरऑप। मुझे लगता है कि मैं अभी भी उलझन में हूं कि बात क्या होगी।

@ रॉसबर्ग-क्रोमियम यहां प्राथमिक लाभ की मांग की जा रही है, अनुमान लगाने के बोझ से उपकरण और पुस्तकालयों को राहत देना।

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

@sunfishcode , कैसे? मैं अभी भी खो गया हूँ।

तो यहाँ एक ठोस परिदृश्य है। मान लीजिए कि हम अलग-अलग प्लेटफॉर्म पर हैं और मैं आपको एक मॉड्यूल पास करने की कोशिश कर रहा हूं। मान लीजिए कि तर्क के लिए मेरा मंच ईबीसीडीआईसी और आपके एएससीआईआई का उपयोग करता है। वर्तमान प्रस्ताव के तहत पूरी तरह से वैध। फिर भी, मेरा मॉड्यूल आपके और आपके टूल चेन के लिए पूरी तरह से बेकार होगा।

ये दोनों एन्कोडिंग 7 बिट हैं, इसलिए यूटीएफ -8 तस्वीर में भी प्रवेश नहीं करता है।

तो UTF-8 तालिका में क्या लाएगा? खैर, मैं किसी भी अज्ञात स्ट्रिंग को "डीकोड" कर सकता हूं जो मुझे मिलता है। लेकिन मुझे पता है कि सभी के लिए, परिणाम 31 बिट मानों का _just एक और अपारदर्शी बाइनरी ब्लॉब_ है। यह कोई जानकारी नहीं देता है। मुझे नहीं पता कि इसे अपने स्वयं के तारों से कैसे जोड़ा जाए।

तो, फिर, मैं एक अज्ञात स्ट्रिंग को डीकोड करने की जहमत क्यों उठाऊंगा? अच्छा, _मैं नहीं_! मैं 8 बिट मानों के मूल बाइनरी ब्लॉब के साथ भी काम कर सकता था और अंतरिक्ष और चक्रों को बचा सकता था। कल्पना को अभी भी मुझे एन्कोडिंग को खाली रूप से मान्य करने के लिए चक्र खर्च करने की आवश्यकता होगी, हालांकि।

इन सब बातों को ध्यान में रखते हुए, इस विशेष प्रस्ताव को अपनाने से (कोर) वासम या औजारों को क्या लाभ होगा?

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

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

तो यहाँ एक ठोस परिदृश्य है। मान लीजिए कि हम अलग-अलग प्लेटफॉर्म पर हैं और मैं आपको एक मॉड्यूल पास करने की कोशिश कर रहा हूं। मान लीजिए कि तर्क के लिए मेरा मंच ईबीसीडीआईसी और आपके एएससीआईआई का उपयोग करता है। वर्तमान प्रस्ताव के तहत पूरी तरह से वैध। फिर भी, मेरा मॉड्यूल आपके और आपके टूल चेन के लिए पूरी तरह से बेकार होगा।

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

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

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

@ रॉसबर्ग-क्रोमियम

तो यहाँ एक ठोस परिदृश्य है। मान लीजिए कि हम अलग-अलग प्लेटफॉर्म पर हैं और मैं आपको एक मॉड्यूल पास करने की कोशिश कर रहा हूं। मान लीजिए कि तर्क के लिए मेरा मंच ईबीसीडीआईसी और आपके एएससीआईआई का उपयोग करता है। वर्तमान प्रस्ताव के तहत पूरी तरह से वैध। फिर भी, मेरा मॉड्यूल आपके और आपके टूल चेन के लिए पूरी तरह से बेकार होगा।

तो UTF-8 तालिका में क्या लाएगा? खैर, मैं किसी भी अज्ञात स्ट्रिंग को "डीकोड" कर सकता हूं जो मुझे मिलता है। लेकिन मुझे पता है कि परिणाम 31 बिट मानों का एक और अपारदर्शी बाइनरी ब्लॉब है। यह कोई जानकारी नहीं देता है। मुझे नहीं पता कि इसे अपने स्वयं के तारों से कैसे जोड़ा जाए।

यूटीएफ -8 आपको बताएगा कि इसे अपने स्वयं के तारों से कैसे जोड़ा जाए। ठीक यही समस्या है जो हल करती है। (डब्ल्यूटीएफ -8 भी जब यह कर सकता है, और यह आपको स्पष्ट रूप से बताएगा कि यह कब नहीं हो सकता है।)

क्या आपका मतलब एक मनमाना डेटा संरचना है जो स्ट्रिंग फॉर्म में उलझा हुआ है और फिर यूटीएफ -8 के रूप में एन्कोड किया गया है? यह सच है कि आप इसे विघटित करने में सक्षम नहीं होंगे, लेकिन आप कम से कम स्पष्ट रूप से उलझे हुए नाम को एक स्ट्रिंग के रूप में प्रदर्शित कर सकते हैं, जो कि कुछ उपयोग के मामलों के लिए कुछ भी नहीं होने पर एक सुधार है।

क्या आपका मतलब यूटीएफ -8 को अपारदर्शी पूर्णांकों के एन्कोडिंग के रूप में उपयोग करने के बारे में है, न कि यूनिकोड? मुझे लगता है कि चर्चा कुछ भ्रमित हो गई है। यह एन्कोडिंग "वाक्यविन्यास" और अंतर्राष्ट्रीयकरण "शब्दार्थ" को कॉल करने के लिए आकर्षक है, लेकिन यह एक उपयोगी भेद को अस्पष्ट करता है: यूटीएफ -8 अभी भी कह सकता है कि एक निश्चित बाइट अनुक्रम का अर्थ "Ö" है, यह बताए बिना कि उपभोक्ताओं को उस जानकारी के साथ क्या करना है। इस तरह से उपयोग किया जाता है, यह यूनिकोड का एक एन्कोडिंग है, लेकिन इसके लिए उस तरह की लागत की आवश्यकता नहीं होती है जो ऊपर सुझाव देने के लिए "यूनिकोड सपोर्ट" का उपयोग किया गया है।

तो, फिर, मैं एक अज्ञात स्ट्रिंग को डीकोड करने की जहमत क्यों उठाऊंगा? अच्छा, मैं नहीं करूँगा! मैं 8 बिट मानों के मूल बाइनरी ब्लॉब के साथ भी काम कर सकता था और अंतरिक्ष और चक्रों को बचा सकता था। कल्पना को अभी भी मुझे एन्कोडिंग को खाली रूप से मान्य करने के लिए चक्र खर्च करने की आवश्यकता होगी, हालांकि।

मैंने अब एक स्पाइडरमोन्की बनाया है जिसमें वासम आयात/निर्यात पहचानकर्ताओं के पूर्ण यूटीएफ -8 सत्यापन के साथ ओवरलांग और सरोगेट्स शामिल हैं। मैं WebAssembly.validate में प्रदर्शन अंतर का पता लगाने में असमर्थ था, या तो एंग्रीबॉट्स पर, या एक छोटे से एमस्क्रिप्टन-संकलित टेस्टकेस पर, फिर भी 30 आयात हैं।

युक्ति कई चिंताओं के बीच एक समझौता है। मैं स्टार्टअप समय की चिंता की सराहना करता हूं, इसलिए मैंने अब कुछ प्रयोग किए हैं और इसे मापा है। मैं दूसरों को अपने स्वयं के प्रयोग करने के लिए प्रोत्साहित करता हूं।

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

कौन से पूर्णांक UTF-8 एन्कोड कर सकते हैं जो यूनिकोड का हिस्सा नहीं हैं (अर्थात, U+0000 से U+10FFFF की सीमा के बाहर)? वह कथन झूठा लगता है।

यदि आप अपने पात्रों को मान्य नहीं करते हैं, तो आप किसी भी 21-बिट पूर्णांक को एन्कोड कर सकते हैं।

निश्चित नहीं है कि हम पुष्टि क्यों नहीं करेंगे...

@flagxor https://encoding.spec.whatwg.org/ वेब पर प्रदर्शित विभिन्न एन्कोडिंग का वर्णन करता है। ध्यान दें कि उनमें से कोई भी यूनिकोड वर्ण सेट से बाहर नहीं जाता है, लेकिन वे स्पष्ट रूप से एक-दूसरे के साथ सभी बाइट-संगत नहीं हैं।

"सत्यापन" क्या करेगा? अपने वासम कार्यक्रम को अमान्य बनायें? मुझे नहीं लगता कि कोई वास्तविक परिणाम है जिसे उचित रूप से लगाया जा सकता है।

जैसे, CSS में एक अमान्य एस्केप का उपयोग करना आपकी स्टाइलशीट में केवल U+FFFD डालता है, यह कुछ भी अजीब नहीं करता है।

@anevk :

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

कौन से पूर्णांक UTF-8 एन्कोड कर सकते हैं जो यूनिकोड का हिस्सा नहीं हैं (अर्थात, U+0000 से U+10FFFF की सीमा के बाहर)? वह कथन झूठा लगता है।

कम से कम: यू+एफएफएफई और यू+एफएफएफएफ यूनिकोड में गैर-वर्ण हैं। यूनिकोड द्वारा वर्णों को एन्कोड करने के लिए कोडपॉइंट (पूर्णांक मान) का उपयोग कभी नहीं किया जाएगा, लेकिन उन्हें UTF-8 में एन्कोड किया जा सकता है।

हालांकि वे अभी भी यूनिकोड कोड पॉइंट हैं। मैं "पात्रों" पर ज्यादा ध्यान नहीं दूंगा।

@tabatkins U+FFFD को डिकोडिंग करना उचित है, लेकिन यह आपके द्वारा प्राप्त किए जा सकने वाले पूर्णांकों की संख्या को सीमित करता है।

इस प्रकार, सी प्रोग्रामिंग भाषा में सभी स्ट्रिंग अक्षर पर यूनिकोड को लागू करने के लिए, कोर वासम पर यूनिकोड को लागू करने का कोई और अर्थ नहीं है। आप केवल कुछ संभावित ग्राहकों को मानक के इस बिट का उल्लंघन करने के लिए बाध्य करेंगे। क्या फायदा?

आप ध्यान दें कि C11 ने char16_t और char32_t प्रकार के साथ-साथ UTF-16-एन्कोडेड स्ट्रिंग अक्षर के लिए u उपसर्ग जोड़ा है, इसके लिए U उपसर्ग UCS-4-एन्कोडेड स्ट्रिंग अक्षर, और UTF-8 एन्कोडेड स्ट्रिंग अक्षर के लिए u8 उपसर्ग। मैंने उन्हें जोड़ने के लिए उनके तर्क को खोजने के लिए काफी गहरी खुदाई नहीं की, लेकिन मुझे लगता है कि "मानक सी/सी ++ में यूनिकोड से निपटना एक दुःस्वप्न है" प्रेरणा का कम से कम हिस्सा है।

@tabatkins , @sunfishcode , ठीक है, तो आप एक ही चीज़ के बारे में बात नहीं कर रहे हैं। लेकिन AFAICT @jfbastien स्पष्ट रूप से और बार-बार कह रहा है कि उनका प्रस्ताव यूनिकोड वर्ण सेट के बिना UTF-8 को निर्दिष्ट करने के बारे में है।

यही एकमात्र व्याख्या है जिसके तहत कम लागत का दावा कायम है।

क्योंकि अगर हम वास्तव में _do_ मानते हैं कि यूटीएफ -8 यूनिकोड का तात्पर्य है तो यह आवश्यकता निश्चित रूप से किसी भी सिस्टम पर किसी भी उपकरण के लिए यूटीएफ -8 एन्कोडिंग/डिकोडिंग से कहीं अधिक महंगी है जो अभी तक बात करने के लिए नहीं हुई है (एक सबसेट) यूनिकोड - वे एक पूर्ण ट्रांसकोडिंग परत शामिल करने की आवश्यकता होगी।

@tabatkins , कोर

उन सभी पर यूनिकोड थोपने के लिए _trying_ का संभावित परिणाम यह होगा कि कुछ संभावित लोग विनिर्देश के उस हिस्से का उल्लंघन करेंगे, इसे पूरी तरह से विवादास्पद बना देंगे (या इससे भी बदतर, वे पूरी तरह से वासम की अवहेलना करेंगे)।

यदि ओटीओएच हम इसे पर्याप्त स्तर पर निर्दिष्ट करते हैं तो हम उस जोखिम को नहीं चलाते - अभ्यास में कुछ भी खोए बिना।

क्योंकि अगर हम वास्तव में यह मानते हैं कि यूटीएफ -8 यूनिकोड का तात्पर्य है तो यह आवश्यकता निश्चित रूप से किसी भी सिस्टम पर किसी भी उपकरण के लिए यूटीएफ -8 एन्कोडिंग/डिकोडिंग से कहीं अधिक महंगी है जो अभी तक बात करने के लिए नहीं हुई है (एक सबसेट) यूनिकोड - वे एक पूर्ण ट्रांसकोडिंग परत शामिल करने की आवश्यकता होगी।

ऐसे कौन से प्लेटफ़ॉर्म मौजूद हैं जो मूल वर्ण सेट का उपयोग करते हैं जो यूनिकोड नहीं है, ASCII नहीं है, उन वर्णों को यूनिकोड से/में परिवर्तित करने की कोई सुविधा नहीं है, और वासम में गैर-ASCII पहचानकर्ताओं का उपयोग करने की आवश्यकता होगी? (मेरा मतलब वास्तव में मौजूद है, न कि कुछ काल्पनिक रूसी संगठन जो डॉस में वासम का उपयोग करने का निर्णय लेते हैं।)

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

इसके अलावा, कड़ाई से बोलते हुए, ऐसे उपकरणों में अक्सर ऐसे हार्डवेयर शामिल होते हैं जिनमें गैर-मानक वर्ण सेट होते हैं जैसे:
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd?kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(जिसमें एक नासमझ मिश्रित ascii + latin1 + जापानी वर्ण सेट है)
लेकिन चिंता यह है कि आप किस चीज को मान्य करने के लिए बाध्य हैं, जो कि प्रासंगिक है।

@tabatkins हालांकि मैंने सोचा है कि संकेत दिया है कि इरादा है:

• मैंडेट यूटीएफ -8 + यूनिकोड बाइट्स की एकमात्र "सही" व्याख्या के रूप में
• स्पष्ट रूप से बताएं कि यूनिकोड को मॉड्यूल को मान्य करने के लिए मान्य करने की आवश्यकता नहीं है (लागत बचाने के लिए)

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

जैसा कि बार-बार कहा गया है, यह एक लाल हेरिंग है। आईसीयू से संबंधित कुछ भी दूरस्थ रूप से करने की आवश्यकता नहीं है; वेब निश्चित रूप से ऐसा नहीं करता है। कृपया इस गलत जानकारी को फैलाना बंद करें।

"पूर्ण सत्यापन" एक अत्यंत तुच्छ ऑपरेशन है, जो एक अनुरूप UTF-8 डिकोड ऑपरेशन के हिस्से के रूप में स्वचालित रूप से किया जाता है।

@tabatkins के साथ
एक अनुरूप यूनिकोड डिकोडर को संशोधक के मनमाने संयोजनों के लिए अनुमति देने की आवश्यकता होती है, असंबद्ध कोड बिंदु आदि। इसलिए संशोधक आदि का एक भटका हुआ मिश्रण, यहां तक ​​​​कि इसके माध्यम से कुछ समझदार को प्रस्तुत नहीं करता है, यूनिकोड द्वारा अनुमति देने की आवश्यकता है। एक डिकोडर जो बकवास संयोजनों को अस्वीकार करता है वह गैर-अनुपालक होगा।

तो यूटीएफ -8 डीकोड को ठीक से करने की आवश्यकता, कुछ हद तक कोड की कुछ पंक्तियों में आप कर सकते हैं, एक सटीक ऑपरेशन है, और अनिवार्य रूप से बाइट्स की एक यूनिकोड + यूटीएफ -8 व्याख्या निर्दिष्ट करने के बराबर है।

हां। यूटीएफ -8 को पार्स करना बेहद मामूली है; केवल जटिलताएं मुट्ठी भर कोडपॉइंट हैं जिन्हें आपको यूटीएफ -8 में एन्कोड करने की अनुमति नहीं है, जो एक अनुपालन डिकोडर इसके बजाय एक या अधिक यू + एफएफएफडी वर्णों के रूप में पार्स करेगा।

लेकिन यह समापन बिंदु के लिए एक ऑपरेशन है। Wasm को इसमें से किसी के साथ खुद को चिंतित करने की ज़रूरत नहीं है; आज्ञाकारी डिकोडर आपके द्वारा फेंके गए किसी भी मनमाने बिट-पैटर्न को संभाल सकते हैं। (वे बस तय करेंगे कि अधिकांश कचरा बिट-पैटर्न यू + एफएफएफडी वर्ण हैं।) मैं इस पूरे समय के लिए पूछ रहा हूं, लेखक-स्तर की अनुरूपता आवश्यकता के लिए है कि इन तारों को यूटीएफ -8 के साथ एन्कोड किया जाना चाहिए। यदि आप इसका उल्लंघन करते हैं, तो आपका टूलचैन इसे एक त्रुटि के रूप में चिह्नित कर सकता है, लेकिन ऐसा कुछ भी नहीं है जो वासम को स्वयं करने की आवश्यकता है।

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

इसके अलावा, कड़ाई से बोलते हुए, ऐसे उपकरणों में अक्सर ऐसे हार्डवेयर शामिल होते हैं जिनमें गैर-मानक वर्ण सेट होते हैं जैसे:

ऐसे कैरेक्टर सेट का अस्तित्व Wasm के लिए अप्रासंगिक है जब तक कि आप लोगों से Wasm आइडेंटिफ़ायर को (गैर-ASCII श्रेणियों) में लिखने की अपेक्षा नहीं करते।

ठीक है, सभी "यूटीएफ -8 का उपयोग करें" का अर्थ है https://encoding.spec.whatwg.org/#utf -8-decoder। आईसीयू एक आवश्यकता के करीब भी नहीं है।

25 फरवरी 2017 को 01:13 बजे, ब्रैड नेल्सन सूचनाएं @github.com ने लिखा:

@tabatkins https://github.com/tabatkins के साथ चैट करने में, एक बात
मुझे लगता है कि यहां पर स्पष्ट होना महत्वपूर्ण है:
मनमाने ढंग से अनुमति देने के लिए एक अनुरूप यूनिकोड डिकोडर की आवश्यकता होती है
संशोधक के संयोजन असंबद्ध कोड अंक आदि। तो का एक भटका हुआ मिश्रण
संशोधक आदि, इसके माध्यम से भी कुछ समझदार नहीं है, is
यूनिकोड द्वारा अनुमति की आवश्यकता है। एक डिकोडर जिसने बकवास को खारिज कर दिया
संयोजन गैर-अनुपालन होगा।

तो यूटीएफ -8 डीकोड को ठीक से करने की आवश्यकता, होने के लिए स्पष्ट रूप से गुंजाइश है
कोड की कुछ पंक्तियों में आप जो कुछ कर सकते हैं, वह एक सटीक ऑपरेशन है,
और अनिवार्य रूप से एक यूनिकोड + utf-8 . निर्दिष्ट करने के बराबर है
बाइट्स की व्याख्या

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

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

>

साथ ही, कड़ाई से बोलते हुए, ऐसे उपकरणों में अक्सर ऐसे हार्डवेयर शामिल होते हैं जिनमें होता है
गैर-मानक वर्ण सेट जैसे:

ऐसे चरित्र सेट का अस्तित्व वासम के लिए अप्रासंगिक है जब तक कि आप
लोगों से अपेक्षा करें कि वे (गैर-ASCII श्रेणियों) में Wasm पहचानकर्ता लिखें।

@rocallahan https://github.com/rocallahan , वे अभी भी सक्षम होना चाहिए
मनमाने ढंग से यूनिकोड में ले लो। लेकिन वे इसका क्या करेंगे? अगर एक Wasm
ऐसे मंच पर कार्यान्वयन ASCII तक सीमित है तो यह होगा
प्रस्तावित विनिर्देश का उल्लंघन। (मैं यह भी मानूंगा कि इसका मतलब है कि
किसी के गैर-ASCII वर्ण अप्रासंगिक हैं एक प्राथमिकता सांस्कृतिक रूप से हो सकती है
संदिग्ध। यह उनका निर्णय होना चाहिए।)

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

क्या यह सैद्धांतिक चिंता है?

और अगर यह एक उचित चिंता है, तो हमें एक बार फिर से इससे निपटने की (घटना * लागत) को दुनिया में लगभग हर दूसरे उपयोगकर्ता की लागत के मुकाबले तौलना चाहिए, जो एक एन्कोडिंग पर निर्भर नहीं है, और इससे निपटने में सक्षम नहीं है एक ही एन्कोडिंग-नरक वेब प्लेटफॉर्म के माध्यम से जाना था, और अंततः इसे जितना हो सके ठीक किया गया।

गैर-यूनिकोड प्लेटफार्मों को वास्तव में अपने तारों को संभालने के लिए ट्रांसकोडिंग करने के लिए मजबूर किया जाएगा।

हालांकि, किस मामले में वासम स्ट्रिंग्स को प्लेटफॉर्म स्ट्रिंग्स के साथ इंटरऑपरेट करने की आवश्यकता होती है? जहां तक ​​​​मैं बता सकता हूं कि हम केवल वासम मेटाडेटा में स्ट्रिंग्स के एन्कोडिंग के बारे में बात कर रहे हैं, न कि वास्तविक मॉड्यूल कोड द्वारा हेरफेर किए गए स्ट्रिंग्स के एन्कोडिंग के बारे में। (यदि यह गलत है, तो मैं क्षमा चाहता हूं...) तब मैं केवल कुछ संभावित मामलों के बारे में सोच सकता हूं जहां इंटरऑप/ट्रांसकोडिंग की आवश्यकता हो सकती है:

• एक Wasm मॉड्यूल एक प्लेटफ़ॉर्म पहचानकर्ता को आयात करता है
• प्लेटफ़ॉर्म एक Wasm पहचानकर्ता आयात करता है
• आपको Wasm नाम निकालने और उन्हें प्रिंट करने या प्लेटफ़ॉर्म स्ट्रिंग्स का उपयोग करके सहेजने के लिए, उदाहरण के लिए स्टैक ट्रेस को डंप करने के लिए।

सही?

काल्पनिक गैर-यूनिकोड एम्बेडेड सिस्टम के लिए, पहले दो मामलों के लिए, सलाह सरल है: प्लेटफ़ॉर्म सीमा के पार ASCII में आयात किए गए पहचानकर्ताओं को सीमित करें, फिर आवश्यक ट्रांसकोडिंग तुच्छ है। Wasm मॉड्यूल अभी भी आंतरिक रूप से और एक दूसरे से जोड़ने के लिए पूर्ण यूनिकोड नामों का उपयोग कर सकते हैं।

तीसरे अंक के लिए --- यदि आपके पास Wasm मॉड्यूल की एक बंद दुनिया है, तो आप उनके पहचानकर्ताओं को ASCII तक सीमित कर सकते हैं। यदि नहीं, तो व्यवहार में आप UTF8 पहचानकर्ताओं का सामना करेंगे और आप उन्हें बेहतर ढंग से ट्रांसकोड करने में सक्षम होंगे, और आपको खुशी होगी कि विशिष्ट UTF8!

इसका अर्थ यह है कि किसी के गैर-ASCII वर्ण अप्रासंगिक हैं एक प्राथमिकता

यह एक स्ट्रॉ-मैन तर्क है। यहां स्थिति यह है कि "यदि आप गैर-ASCII पहचानकर्ता चाहते हैं, तो यूनिकोड का उपयोग करें या यूनिकोड से/में ट्रांसकोडिंग लागू करें", और इसने अन्य चश्मे, AFAIK में "सांस्कृतिक रूप से संदिग्ध" के रूप में आलोचना को आकर्षित नहीं किया है।

>

और अगर यह एक उचित चिंता है, तो हमें एक बार फिर से (घटना) तौलना चाहिए

• लागत) लगभग हर दूसरे की लागत के खिलाफ उससे निपटने के लिएदुनिया में Wasm का उपयोगकर्ता एक एन्कोडिंग पर निर्भर नहीं हो पा रहा है, और
  उसी एन्कोडिंग-नरक से निपटने के लिए वेब प्लेटफॉर्म को जाना पड़ा,
  और अंत में जितना हो सके ठीक किया।

@tabatkins , नहीं, फिर से (और किसी तरह मुझे ऐसा लगता है कि मैंने इसे 100 दोहराया है)
बार पहले से ही): प्रत्येक एम्बेडिंग युक्ति _will_ एक एन्कोडिंग निर्दिष्ट करें और
अक्षरों का समूह। हर प्लेटफॉर्म पर आप इस पर भरोसा कर सकते हैं। आप केवल कभी दौड़ेंगे
एन्कोडिंग प्रश्नों में यदि आपने दो असंबंधित के बीच इंटरऑपरेट करने का प्रयास किया है
इको सिस्टम - जो पहले से ही गहरे कारणों से असंगत होगा
तार। और यह केवल उन प्लेटफार्मों के साथ इंटरऑप को प्रभावित करेगा जो आप अन्यथा करेंगे
पूरी तरह से बहिष्कृत करें। तो आप _कुछ भी नहीं खोते_ लेकिन उपयोग करने की क्षमता जीतते हैं
अधिक विविध प्लेटफार्मों पर वासम।

आप सॉफ्टवेयर इंजीनियर हैं। जैसे मुझे लगता है कि आप समझते हैं और सराहना करते हैं
मॉड्यूलरलाइजेशन और लेयरिंग का मूल्य, चिंताओं को अलग करने और अधिकतम करने के लिए
पुन: उपयोग। यह विनिर्देशों पर भी लागू होता है।

>

गैर-यूनिकोड प्लेटफॉर्म वास्तव में ट्रांसकोडिंग करने के लिए मजबूर होंगे
उनके तार संभालो।

किन मामलों में वासम स्ट्रिंग्स को प्लेटफॉर्म स्ट्रिंग्स के साथ इंटरऑपरेट करने की आवश्यकता होती है,
हालांकि? जहाँ तक मैं बता सकता हूँ हम केवल के एन्कोडिंग के बारे में बात कर रहे हैं
वासम मेटाडेटा में स्ट्रिंग्स, स्ट्रिंग्स के एन्कोडिंग द्वारा हेरफेर नहीं किया गया
वास्तविक मॉड्यूल कोड। (यदि यह गलत है, तो मैं क्षमा चाहता हूँ...) तब मैं केवल सोच सकता हूँ
कुछ संभावित मामलों में जहां इंटरऑप/ट्रांसकोडिंग की आवश्यकता हो सकती है:

• एक Wasm मॉड्यूल एक प्लेटफ़ॉर्म पहचानकर्ता को आयात करता है
• प्लेटफ़ॉर्म एक Wasm पहचानकर्ता आयात करता है
• आप वासम के नाम निकालने और उन्हें प्रिंट करने या प्लेटफॉर्म का उपयोग करके सहेज सकते हैं
  तार, उदाहरण के लिए एक स्टैक ट्रेस डंप करने के लिए।

सही?

हां। दूसरे शब्दों में, हर बार आपको वास्तव में एक स्ट्रिंग को _use_ करने की आवश्यकता होती है।

काल्पनिक गैर-यूनिकोड एम्बेडेड सिस्टम के लिए, पहले दो मामलों के लिए,
सलाह सरल है: प्लेटफॉर्म पर आयात किए गए पहचानकर्ताओं को सीमित करें
ASCII की सीमा, तो आवश्यक ट्रांसकोडिंग तुच्छ है। वासम मॉड्यूल
आंतरिक रूप से और एक दूसरे से जोड़ने के लिए अभी भी पूर्ण यूनिकोड नामों का उपयोग कर सकते हैं।

तीसरे अंक के लिए --- यदि आपके पास Wasm मॉड्यूल की एक बंद दुनिया है, तो आप
अपने पहचानकर्ताओं को ASCII तक सीमित कर सकते हैं। यदि नहीं, तो व्यवहार में आप
UTF8 पहचानकर्ताओं का सामना करें और आप उन्हें बेहतर ढंग से ट्रांसकोड करने में सक्षम होंगे, और
आपको खुशी होगी कि विशिष्ट अनिवार्य UTF8!

प्रस्ताव के तहत आपको कुछ भी ASCII तक सीमित करने की अनुमति नहीं दी जाएगी! प्रति
अनुमति दें कि कोर स्पेक को अधिक अनुमति देने की आवश्यकता होगी। तो आप बना रहे हैं
मेरी बात का।

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

वासम प्रोसेसिंग टूल्स जैसे डिस्सेबलर के बारे में क्या? क्या "एम्बेडिंग स्पेक" वेरिएंट की परवाह किए बिना किसी भी वासम मॉड्यूल के साथ काम करने वाले डिस्सेबलर को लिखने में सक्षम होना मूल्यवान नहीं होगा?

प्रस्ताव के तहत आपको कुछ भी ASCII तक सीमित करने की अनुमति नहीं दी जाएगी!

प्रस्ताव के तहत, Wasm मॉड्यूल ASCII तक सीमित नहीं होंगे, लेकिन यदि कोई कार्यान्वयनकर्ता अपने सभी पहचानकर्ताओं को Wasm मॉड्यूल ASCII के बाहर परिभाषित करने के लिए चुना है (उदाहरण के लिए सभी सिस्टम लाइब्रेरी वास्तव में करते हैं!), तो यह Wasm के दायरे से बाहर होगा। कल्पना

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

यह सब कहने के बाद, Wasm के एक उपसमुच्चय को परिभाषित करना जिसमें सभी Wasm नाम ASCII हैं, काफी हानिरहित होगा क्योंकि ऐसे Wasm मॉड्यूल्स को Wasm नामों को UTF8 के रूप में मानने वाले टूल द्वारा सही ढंग से संसाधित किया जाएगा।

आप सॉफ्टवेयर इंजीनियर हैं। इस प्रकार मुझे लगता है कि आप चिंताओं को अलग करने और पुन: उपयोग को अधिकतम करने के लिए मॉड्यूलरलाइजेशन और लेयरिंग के मूल्य को समझते हैं और सराहना करते हैं। यह विनिर्देशों पर भी लागू होता है।

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

इस पूरे (लंबे) सूत्र को पढ़ने के बाद, मुझे लगता है कि इस चर्चा को हल करने का एकमात्र तरीका स्पष्ट रूप से निर्दिष्ट करना है कि नाम अनुभाग जिसका हम द्विआधारी प्रारूप में वर्णन कर रहे हैं और https://github.com/WebAssembly/design/pull में बढ़ा रहे हैं। एक यूटीएफ -8 एन्कोडिंग है , और मैं प्रस्तावित करता हूं कि हम बस उस अनुभाग को "utf8-names" कहते हैं । इससे एन्कोडिंग स्पष्ट हो जाती है, और लगभग निश्चित रूप से सभी उपकरण जो सभी प्रासंगिक प्लेटफॉर्म पर WASM बाइनरी में हेरफेर करना चाहते हैं, वैसे भी यूटीएफ -8 बोलना चाहते हैं। उन्हें केवल UTF-8 बोलने के लिए माफ किया जा सकता था।

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

(वैसे, यह एक ऐसी प्रणाली के बारे में युद्ध की कहानियों से सूचित किया जाता है जो गलती से उपयोगकर्ता द्वारा अपलोड की गई सामग्री के लिए स्ट्रिंग्स के एन्कोडिंग को खो देती है, और उन्हें कभी भी पुनर्प्राप्त नहीं कर सकती है। सिस्टम एक भयानक, स्पस्मिक मौत मर गया। सचमुच, लाखों डॉलर खो गए थे ।)

हम नाम अनुभागों (हे) के लिए नामकरण मानक भी अपना सकते हैं, ताकि वे सभी "\

@titzer हाँ, कस्टम सेक्शन विदेशी या विशेष प्लेटफ़ॉर्म के लिए यहाँ समाधान हैं जो UTF8 से कोई लेना-देना नहीं चाहते हैं। मुझे कल्पना में लिखने में संकोच होगा, हालांकि: यदि कोई प्लेटफ़ॉर्म संचालन के अपने तरीके में इतना विशिष्ट है कि उसे यूटीएफ -8 कोड बिंदुओं को उनकी मूल वरीयता में मैप करने के लिए भी परेशान नहीं किया जा सकता है, तो वे करना चाहते हैं कस्टम अनुभागों के साथ उनके पसंदीदा एन्कोडिंग में केवल नामों की आपूर्ति करने की तुलना में बहुत अधिक।

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

@titzer utf8-names स्विच करना ठीक लगता है। एक बोनस के रूप में, यह संक्रमण को सुचारू करेगा क्योंकि ब्राउज़र आसानी से "नाम" (पुराने प्रारूप में) और "utf8-names" (# 984 प्रारूप में) दोनों को "नाम" छोड़ने से पहले रिलीज़ या दो का समर्थन कर सकते हैं, जो बदले में इसे तैनात करने के लिए बहुत सारी तात्कालिकता को हटा देता है।

क्षमा करें यदि यह पहले से ही ऊपर पर तय किया गया था, लेकिन स्पष्ट होने के लिए: क्या अब बाइनरीएन्कोडिंग.एमडी में आयात/निर्यात नामों में कोई प्रस्तावित परिवर्तन है?

utf8-names ठीक लगता है।

आयात/निर्यात पर @lukewagner के समान प्रश्न।

@lukewagner @jfbastien अच्छा सवाल है। मैंने ऊपर कोई निर्णय नहीं देखा। मुझे लगता है कि सबसे ऊपर हम बाइनरी प्रारूप को अब हमारे पास से बदलना नहीं चाहते हैं। तो यह वास्तव में सिर्फ मानसिक गर्भपात है जो हमें खुद को समझाने के लिए करना है कि हमने जो किया वह तर्कसंगत है :-)

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

लघु संस्करण: आयात/निर्यात घोषणाओं में नामों की एन्कोडिंग एम्बेडिंग वातावरण की एक संपत्ति है, नाम अनुभाग में नामों की एन्कोडिंग उपयोगकर्ता अनुभाग (जैसे "utf8-names") की पहचान करने के लिए उपयोग की जाने वाली स्ट्रिंग द्वारा स्पष्ट है।

डब्ल्यूडीवाईटी?

यह मेरे साथ ठीक है और जो हमारे पास #984 विलय से पहले था (मॉड्यूलो names => utf8-names ) से मेल खाता है।

मुझे लगता है कि नाम अनुभाग आयात/निर्यात जितना महत्वपूर्ण नहीं है, जहां वास्तविक संगतता समस्याएं होती हैं:

• एक mojibaked नाम अनुभाग लोड करें और आपको फंकी Error.stack और डिबगिंग मिलती है।
• एक mojibaked आयात/निर्यात लोड करें और कुछ भी काम नहीं करता है।

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

मैं बंद करने से पहले इस विषय के बारे में मुझसे बेहतर जानने वाले लोगों की सिफारिश पर निर्भर हूं।

आपको यह तय करना होगा कि आप UTF-8 को कैसे डीकोड करते हैं। क्या आप गलत अनुक्रमों को U+FFFD से बदलते हैं या पहली त्रुटि पर रोक लगाते हैं? यानी आप या तो https://encoding.spec.whatwg.org/#utf -8-decode-without-bom चाहते हैं या https://encoding.spec.whatwg.org/#utf -8-decode-without- बम-या-असफल। किसी भी तरह से लोड होने की संभावना विफल हो जाएगी, जब तक कि संसाधन अपने नाम पर यू + एफएफएफडी का उपयोग नहीं करता।

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

मेरी समझ की जांच करने के लिए, अगर हमने https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-fail किया, तो क्या इसका मतलब यह होगा कि, सफल सत्यापन के बाद, कोडपॉइंट-सीक्वेंस समानता की जांच करना बाइट-अनुक्रम समानता की जांच के बराबर होगा?

हां।

ऊपर की चर्चा के बाद, मैं कोर स्पेक में आयात/निर्यात नामों के लिए यूटीएफ -8 को मान्य करने का समर्थन करता हूं।

विशेष रूप से, यह utf-8-decode-with-bom-or-fail होगा , और कोडपॉइंट-अनुक्रम समानता (इसलिए इंजन बाइट-अनुक्रम समानता कर सकते हैं ), इसलिए इंजन यूनिकोड और अंतर्राष्ट्रीयकरण के डरावने और महंगे हिस्सों से बचेंगे। और, यह वेब एम्बेडिंग के अनुरूप है। मैंने इसके साथ प्रयोग किया है और मुख्य ओवरहेड को नगण्य पाया है।

• पुन:: हार्डवेयर ISAs एन्कोडिंग के लिए अज्ञेयवादी हैं: जिस हार्डवेयर के बारे में हम यहां बात कर रहे हैं उसका आयात/निर्यात नहीं है, इसलिए सादृश्य सीधे लागू नहीं होता है। एक जगह जहां मैं जानता हूं कि ऐसा हार्डवेयर किसी भी प्रकार के बाइट-अनुक्रम पहचानकर्ताओं का उपयोग करता है, x86 का सीपीयू, एक विशिष्ट वर्ण एन्कोडिंग निर्दिष्ट करता है: यूटीएफ -8।

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

• पुन: "एम्बेडेड सिस्टम": दिया गया एक उदाहरण डॉस है, लेकिन कुछ का उदाहरण क्या होगा कि आयात/निर्यात नामों के लिए यूटीएफ -8 की आवश्यकता के लिए एक डॉस सिस्टम की आवश्यकता होगी जो इसके लिए महंगा या अव्यवहारिक होगा?

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

• पुन: आयात/निर्यात नामों में मनमाना डेटा संरचनाएं: यह सैद्धांतिक रूप से उपयोगी है, लेकिन यह डेटा को स्ट्रिंग में जोड़कर भी किया जा सकता है। मैंगलिंग कम सुविधाजनक है, लेकिन मुश्किल नहीं है। तो वहाँ एक ट्रेडऑफ़ है, लेकिन एक बड़ा नहीं है (और यकीनन, अगर आयात/निर्यात में मेटाडेटा संलग्न करने की सामान्य आवश्यकता है, तो अतिरिक्त उद्देश्यों के साथ पहचानकर्ताओं को जोड़ने की तुलना में एक स्पष्ट तंत्र होना अच्छा होगा।)

• पुन: बाइनरी संगतता: मैं जेएफ से भी सहमत हूं कि यह परिवर्तन अभी भी संभव है। utf-8-decode-बिना बम-या-असफल होने का मतलब कोई मूक व्यवहार परिवर्तन नहीं होगा, और इस समय, सभी ज्ञात wasm निर्माता अपने आउटपुट को वेब एम्बेडिंग के साथ संगत रखते हैं (भले ही वे अन्य एम्बेडिंग का भी समर्थन करते हों), इसलिए वे ' पहले से ही UTF-8 में रह रहे हैं।

यूटीएफ -8 नामों के लिए एक विशिष्ट प्रस्ताव बनाने वाला पीआर अब https://github.com/WebAssembly/design/issues/1016 के रूप में पोस्ट किया गया है

#1016 के साथ, यह अब ठीक हो गया है।