Pegjs: पूर्ण यूनिकोड समर्थन, अर्थात् बीएमपी के बाहर कोडपॉइंट के लिए

पूरी तरह से ईमानदार होने के लिए, पीईजी.जेएस व्याकरण पार्सर और जावास्क्रिप्ट उदाहरण के लिए यूनिकोड समर्थन को अपडेट करने के अलावा, मुझे यूनिकोड के बारे में बहुत कम या कोई जानकारी नहीं है, इसलिए मैं वर्तमान में इस समस्या को ठीक करने में असमर्थ हूं (यह दोनों व्याकरणों में स्पष्ट रूप से कहा गया है: _Non -बीएमपी वर्णों को पूरी तरह से अनदेखा किया जाता है_)।

अभी के लिए, अधिक जरूरी व्यक्तिगत और काम से संबंधित परियोजनाओं (_PEG.js 0.x_ सहित) पर काम करते हुए, मैं किसी ऐसे व्यक्ति की प्रतीक्षा करना जारी रखूंगा जो यूनिकोड को कुछ पीआर के की पेशकश करने के लिए बेहतर समझता है, या अंततः _PEG के बाद इसके आसपास पहुंच जाता है। जेएस v1_, क्षमा करें दोस्त।

FYI करें, सरोगेट जोड़े काम करने लगते हैं। व्याकरण
start = result:[\uD83D\uDCA9]+ {return result.join('')}
पार्स जो u+1F4A9 है। परिणाम पर ध्यान दें। शामिल हों ('') सरोगेट जोड़ी को वापस एक साथ रखता है, अन्यथा आपको हैंकी के बजाय ['\uD83D','\uDCA9'] मिलता है। रेंज समस्याग्रस्त होगी।
सरोगेट जोड़े पर अधिक: https://en.wikipedia.org/wiki/UTF-16#U +010000_to_U+10FFFF

यह किसी भी तरह से ओपी ने जो मांगा है उसे प्रतिस्थापित नहीं करता है।

@drewnolan सिर ऊपर करने के लिए धन्यवाद

दुर्भाग्य से वह व्याकरण \uD83D\uD83D भी पार्स करता है।

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

यह समाधान स्पष्ट रूप से सामान्य मामले में समस्याओं से भरा है, लेकिन यह मेरे समस्या क्षेत्र में अच्छी तरह से काम करता है।

@futagoza - मैं समझाने की पूरी कोशिश करूंगा। आपको यहां कई समस्याओं का सामना करना पड़ रहा है।

1. यूनिकोड में एन्कोडिंग, नोटेशन और रेंज हैं
   
   
   
   1. यहां, जो चीजें मायने रखती हैं वे हैं "रेंज" - कौन से अक्षर समर्थित हैं - और "नोटेशन" - वे कैसे लिखे जाते हैं
   
   
   2. ये समय के साथ बदलते हैं। यूनिकोड समय-समय पर नए अक्षर जोड़ता है, जैसे कि जब उन्होंने इमोजी या संगीत नोट्स जोड़े थे
   
   
2. यूनिकोड में "नोटेशन" हैं। ये utf-16 , ucs4 , वगैरह जैसी चीजें हैं। इस तरह से codepoints , जो कि इच्छित डेटा हैं, बाइट्स के रूप में एन्कोड किए गए हैं। उदाहरण के लिए utf-16-le से आप अधिकांश अक्षरों को दो-बाइट जोड़े के रूप में एन्कोड कर सकते हैं जिन्हें code units कहा जाता है, लेकिन 0x10ffff तक के उच्च मूल्य वर्णों को व्यक्त करने के लिए कोड इकाइयों के समूहों का उपयोग करें।
   
   
   
   1. मुख्य समझ: यह वास्तव में काफी अधिक नहीं है। बहुत सारी दिलचस्प चीजें, जैसे इमोजी, ऐतिहासिक चीनी के बड़े हिस्से, और इस पोस्ट का मूल प्रश्न (ब्लैकबोर्ड गणित वर्ण) उस पंक्ति से ऊपर हैं
      
      
      
      
      
      1. आईएसओ और यूनिकोड कंसोर्टियम स्पष्ट हैं: वे इसे कभी ठीक नहीं कर रहे हैं । यदि आप उच्च वर्ण चाहते हैं, तो utf-16 से बड़े एन्कोडिंग का उपयोग करें।
      
      
      
   
   
   2. मुख्य समझ #2: कमबख्त जावास्क्रिप्ट औपचारिक रूप से utf16 है
      
      
      
      
      
      1. इसका मतलब है कि यूनिकोड वर्ण मौजूद हैं (उनमें से बहुत से) जो जावास्क्रिप्ट स्ट्रिंग प्रकार का प्रतिनिधित्व नहीं कर सकते हैं
      
      
      
      2. ओपी आपसे इसे ठीक करने के लिए कह रहा है
      
      
      
      3. यह संभव है लेकिन आसान नहीं है - आपको यूनिकोड पार्सिंग एल्गोरिथम को लागू करना होगा, जो प्रसिद्ध रूप से चूहे का घोंसला है
      
      
      
   
   

मुझे भी यही चाहिए, लेकिन हकीकत में ऐसा होने वाला नहीं है

पवित्र बकवास, किसी ने लगभग एक साल पहले एक पूर्ण स्ट्रिंग पार्सर प्रतिस्थापन किया था , और उन्होंने ओवरहेड को पहचान लिया, इसलिए उन्होंने हमें आमतौर पर मानक जेएस स्ट्रिंग्स का उपयोग करने दिया

यह विलय क्यों नहीं है

@StoneCypher मुझे तुम्हारे दिल की आग बहुत पसंद है! लेकिन वर्तमान अनुरक्षक को कठिन समय क्यों दें? किसी का कुछ बकाया नहीं है। अपना कांटा क्यों नहीं बनाए रखते?

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

टूल ने अपना आधा उपयोगकर्ता आधार खो दिया है, इस आदमी पर एक-पंक्ति सुधार करने के लिए तीन साल की प्रतीक्षा कर रहा है, जो अन्य लोगों ने लिखा है, जैसे es6 मॉड्यूल समर्थन, टाइपस्क्रिप्ट समर्थन, तीर समर्थन, विस्तारित यूनिकोड, वगैरह।

एक दर्जन लोग उसे मर्ज करने के लिए कह रहे हैं और वह कहता रहता है "नहीं, यह अब मेरा शौक प्रोजेक्ट है और मुझे यह पसंद नहीं है"

बहुत से लोगों के पास इस पार्सर पर आधारित कंपनियां हैं। वे पूरी तरह से खराब हो चुके हैं।

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

अपना कांटा क्यों नहीं बनाए रखते?

मेरे पास अब तीन साल के लिए है। मेरे peg में समस्या ट्रैकर का लगभग एक तिहाई हिस्सा ठीक हो गया है।

मुझे इसे क्लोन करना था, इसका नाम बदलना था, और आकार की समस्या को ठीक करने के लिए एक नया कांटा बनाना था, क्योंकि मेरा बहुत ज्यादा बह गया है

बाकी सभी के लिए इन सुधारों को प्राप्त करने का समय आ गया है, साथ ही साथ जो 2017 से ट्रैकर में बैठे हैं।

यह आदमी खूंटी का रखरखाव नहीं कर रहा है; वह इसे मरने दे रहा है।

बदलाव का समय है।

@drewnolan - तो, ​​मुझे यकीन नहीं है कि यह दिलचस्प है या नहीं, लेकिन, सरोगेट जोड़े वास्तव में काम नहीं करते हैं। बस, संयोग से, वे आमतौर पर ऐसा करते हैं।

अंतर्निहित समस्या को समझने के लिए आपको एन्कोडिंग स्तर बिट पैटर्न के बारे में सोचना होगा, न कि प्रतिनिधित्व स्तर एक के बारे में।

यानी, यदि आपके पास 240 का यूनिकोड मान है, तो अधिकांश लोग सोचेंगे "ओह, उसका मतलब है 0b1111 0000 ।" लेकिन वास्तव में, यूनिकोड 240 का प्रतिनिधित्व नहीं करता है; 127 से अधिक को दो बाइट्स द्वारा दर्शाया जाता है, क्योंकि शीर्ष बिट एक ध्वज है, न कि मान बिट। तो यूनिकोड में 240 वास्तव में भंडारण में 0b0000 0001 0111 0000 है (यूटीएफ -7 को छोड़कर, जो वास्तविक है और टाइपो नहीं है, जहां चीजें बहुत अजीब होती हैं। और हां, मुझे पता है कि विकिपीडिया कहता है कि यह उपयोग में नहीं है। विकिपीडिया गलत है . यह वही है जिस पर एसएमएस भेजा जाता है; यह कुल ट्रैफ़िक द्वारा सबसे सामान्य वर्ण एन्कोडिंग हो सकता है।)

तो यहाँ समस्या है।

यदि आप एक बाइट STUV WXYZ लिखते हैं, तो utf16 में, ucs4 डेटा से, यदि आपकी चीज़ आधी हो जाती है, तो अक्सर आप इसे वापस एक साथ स्टेपल कर सकते हैं।

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

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

ऐसा होता है कि ज्यादातर इमोजी इस रेंज से बाहर होते हैं। हालांकि, कई भाषाओं के बड़े हिस्से दुर्लभ चीनी, अधिकांश गणित और संगीत प्रतीकों सहित नहीं हैं।

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

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

ऐसा लगता है कि . (dot character) अभिव्यक्ति को भी यूनिकोड मोड की आवश्यकता है। तुलना करना:

const string = '-🐎-👱-';

const symbols = (string.match(/./gu));
console.log(JSON.stringify(symbols, null, '  '));

const pegResult = require('pegjs/')
                 .generate('root = .+')
                 .parse(string);
console.log(JSON.stringify(pegResult, null, '  '));

आउटपुट:

[
  "-",
  "🐎",
  "-",
  "👱",
  "-"
]

[
  "-",
  "\ud83d",
  "\udc0e",
  "-",
  "\ud83d",
  "\udc71",
  "-"
]

मैंने हाल ही में इस पर काम किया, आधार के रूप में #616 का उपयोग करके और इसे ES6 सिंटैक्स का उपयोग करने के लिए संशोधित किया \u{hhhhhhh} , मैं कुछ घंटों में एक पीआर बनाऊंगा।

सरोगेट्स द्वारा विभाजित यूटीएफ -16 रेगेक्स श्रेणियों की गणना करना थोड़ा जटिल है और मैंने इसके लिए https://github.com/mathiasbynens/regenerate का उपयोग किया; यह पैकेज pegjs की पहली निर्भरता होगी, मुझे आशा है कि यह संभव है (यूनिकोड गुणों के लिए पॉलीफिल भी हैं जिन्हें निर्भरता के रूप में जोड़ा जा सकता है, # 648 देखें)। यदि आप UTF-16 सरोगेट को नहीं जानते हैं तो विकिपीडिया देखें ।

PEG.js को संपूर्ण यूनिकोड के साथ संगत बनाने के लिए, विभिन्न स्तर हैं:

1. #616 या मेरे ES6-वाक्यविन्यास संस्करण द्वारा तय BMP के ऊपर यूनिकोड वर्णों को एन्कोड करने के लिए एक सिंटैक्स जोड़ें,
2. पिछले बिंदु द्वारा सीधे प्रदान किए गए निरंतर तारों को पहचानें,
3. वास्तविक यूनिकोड वर्ण प्रदर्शित करने के लिए संभवतः 1 या 2 कोड इकाइयों को प्रदर्शित करने के लिए SyntaxError रिपोर्टिंग को ठीक करें,
4. बीएमपी और/या सूक्ष्म कोड बिंदुओं के लिए रेगेक्स वर्ग की सटीक गणना करें - यह अकेला काम नहीं कर रहा है, अगला बिंदु देखें,
5. कर्सर वृद्धि को प्रबंधित करें क्योंकि एक रेगेक्स वर्ग अब (1), (2), या (रनटाइम के आधार पर 1 या 2) हो सकता है, नीचे विवरण देखें,
6. 1 या 2 कोड इकाइयों को पकड़ने के लिए नियम डॉट . लागू करें।

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

1. डॉट नियम केवल बीएमपी कोड इकाई को कैप्चर करता है,
2. डॉट नियम एक यूनिकोड कोड बिंदु (1 या 2 कोड इकाइयाँ) को कैप्चर करता है,
3. डॉट नियम एक यूनिकोड कोड बिंदु या एक अकेला सरोगेट कैप्चर करता है।

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

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

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

सूक्ष्म यूनिकोड वर्ण के लिए ES6 सिंटैक्स के लिए PR #616 पर आधारित #651 है और कक्षाओं के लिए विकास https://github.com/Seb35/pegjs/commit/0d33a7a4e13b0ac7c55a9cfaadc16fc0a5dd5f0c ऊपर मेरी टिप्पणी में अंक 2 और 3 को लागू करना है, और केवल कर्सर वृद्धि के लिए एक त्वरित हैक (बिंदु 4) और नियम डॉट . (बिंदु 5) के लिए अभी के लिए कुछ भी नहीं।

इस मुद्दे के बारे में मेरा वर्तमान विकास ज्यादातर समाप्त हो गया है, अधिक उन्नत कार्य https://github.com/Seb35/pegjs/tree/dev-astral-classes-final में है। ऊपर वर्णित सभी पांच बिंदुओं का इलाज किया जाता है और वैश्विक व्यवहार किनारे के मामलों के बारे में जेएस रेगेक्स की नकल करने की कोशिश करता है (और उनमें से बहुत सारे हैं)।

वैश्विक व्यवहार जेएस रेगेक्स में ध्वज unicode unicode समान विकल्प [^a] पाठ "💯" से मेल खाता है और कर्सर 2 कोड इकाइयों से बढ़ा हुआ है)। जब विकल्प unicode गलत होता है तो कर्सर को हमेशा 1 कोड इकाई से बढ़ाया जाता है।

इनपुट के बारे में मुझे यकीन नहीं है कि क्या हम पीईजी.जेएस को उसी तरह डिजाइन करते हैं जैसे जेएस रेगेक्स: क्या हमें गैर-यूनिकोड मोड में व्याकरण में [\u{1F4AD}-\u{1F4AF}] ( [\uD83D\uDCAD-\uD83D\uDCAF] बराबर) को अधिकृत करना चाहिए ? हम "इनपुट यूनिकोड" और "आउटपुट यूनिकोड" के बीच अंतर कर सकते हैं:

• इनपुट यूनिकोड वर्ण वर्गों में सभी यूनिकोड वर्णों को अधिकृत करने के बारे में है (जिसे आंतरिक रूप से एक निश्चित 2-कोड-इकाइयों या एक निश्चित 1-कोड-इकाई के रूप में गणना की जाती है)
• आउटपुट यूनिकोड परिणामी पार्सर की कर्सर वृद्धि है: 1 कोड इकाई या 1 यूनिकोड वर्ण 'डॉट' और 'उलटा वर्ण वर्ग' के लिए - एकमात्र नियम जहां वर्ण स्पष्ट रूप से सूचीबद्ध नहीं हैं और जहां हमें व्याकरण से निर्णय की आवश्यकता है लेखक

व्यक्तिगत रूप से मुझे लगता है कि मैं पसंद करूंगा कि हम इनपुट यूनिकोड को स्थायी रूप से या डिफ़ॉल्ट true साथ एक विकल्प के साथ अधिकृत करें क्योंकि कोई महत्वपूर्ण ओवरहेड नहीं है और यह डिफ़ॉल्ट रूप से सभी के लिए इस संभावना को सक्षम करेगा, लेकिन आउटपुट यूनिकोड false रहना चाहिए

इस मुद्दे के बारे में सामान्य रूप से (और आउटपुट यूनिकोड के बारे में false डिफ़ॉल्ट रूप से), हमें यह ध्यान रखना चाहिए कि यूटीएफ -16 के कामकाज को समझने की कीमत पर हमारे व्याकरण यूनिकोड वर्णों में एन्कोड करना पहले से ही संभव है। :

// rule matching [\u{1F4AD}-\u{1F4AF}]
my_class = "\uD83D" [\uDCAD-\uDCAF]

// rule matching any Unicode character
my_strict_unicode_dot_rule = $( [\u0000-\uD7FF\uE000-\uFFFF] / [\uD800-\uDBFF] [\uDC00-\uDFFF] )

// rule matching any Unicode character or a lone surrogate
my_loose_unicode_dot_rule = $( [\uD800-\uDBFF] [\uDC00-\uDFFF]? / [\u0000-\uFFFF] )

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

कार्यान्वयन के बारे में, मैंने अपने पहले प्रयास में माना कि व्याकरण पाठ यूनिकोड वर्णों में एन्कोड किया गया था और पीईजी.जेएस पार्सर के 'डॉट' नियम ने यूनिकोड वर्णों को मान्यता दी थी। दूसरे और अंतिम प्रयास ने इसे वापस कर दिया (त्वरित पार्सिंग के लिए डॉट नियम हमेशा 1 कोड इकाई है) और वर्ण वर्गों में विभाजित यूनिकोड वर्णों को फिर से संगठित करने के लिए विज़िटर तैयार-यूनिकोड-क्लासेज में एक छोटा एल्गोरिदम है (उदाहरण [\uD83D\uDCAD-\uD83D\uDCAF] को वाक्यात्मक रूप से [ "\uD83D", [ "\uDCAD", "\uD83D" ], "\uDCAF" ] रूप में पहचाना जाता है और यह एल्गोरिदम इसे [ [ "\uD83D\uDCAD", "\uD83D\uDCAF" ] ] )। मैंने इसे व्याकरण में ही लिखने की परिकल्पना की थी, लेकिन यह लंबा होता और अधिक महत्वपूर्ण बात यह है कि वर्णों ("💯", "uD83DuDCAF", "u{1F4AF}") को एन्कोड करने के कई तरीके हैं, इसलिए इसे लिखना आसान है। एक आगंतुक में।

मैंने दूसरे प्रयास में दो ऑपकोड जोड़े:

• MATCH_ASTRAL MATCH_ANY के समान लेकिन यूनिकोड वर्ण से मेल खाता है (input.charCodeAt(currPos) & 0xFC00) === 0xD800 && input.length > currPos + 1 && (input.charCodeAt(currPos+1) & 0xFC00) === 0xDC00
• MATCH_CLASS2 बहुत MATCH_CLASS के समान है लेकिन केवल एक classes[c].test(input.substring(currPos, currPos+2) बजाय अगली दो कोड इकाइयों से मेल खाता है
  फिर, यदि हम 2-कोड-इकाई वर्ण या 1-कोड-इकाई वर्ण से मेल खाते हैं, तो कर्सर को opcode ACCEPT_N साथ 1 या 2 कोड इकाइयों से बढ़ाया जाता है, और वर्ण वर्ग दो में विभाजित होते हैं निश्चित लंबाई (1 या 2 कोड इकाइयों) के रेगेक्स।

मैंने "मैच" सुविधा के साथ कुछ अनुकूलन किए, पीढ़ी के दौरान मोड (यूनिकोड या नहीं) और वर्ण वर्ग के आधार पर "मृत कोड" पथ को समाप्त कर दिया।

ध्यान दें कि इस कार्यान्वयन में रेगेक्स हमेशा सकारात्मक होते हैं: उलटा रेगेक्स विपरीत परिणाम देता है जिसके परिणामस्वरूप बाइटकोड होता है। सरोगेट के आसपास के मामलों से बचना आसान था।

मैंने कुछ दस्तावेज लिखे हैं लेकिन मैं शायद कुछ और जोड़ूंगा (शायद विकल्प (विकल्पों) यूनिकोड के विवरण और घर-निर्मित यूनिकोड डॉट नियम के साथ स्निपेट्स को जल्दी से समझाने के लिए एक गाइड)। मैं इसे पीआर के रूप में जमा करने से पहले परीक्षण जोड़ूंगा।