अर्को बाइक: हामी युनिकोड स्ट्रिङहरू UTF-30 भन्दा 60-8% बढी कम्प्याक्ट भण्डार गर्छौं

यदि तपाइँ एक विकासकर्ता हुनुहुन्छ र तपाइँ एन्कोडिङ छनौट गर्ने कार्यको सामना गर्दै हुनुहुन्छ भने, युनिकोड लगभग सधैं सही समाधान हुनेछ। विशिष्ट प्रतिनिधित्व विधि सन्दर्भमा निर्भर गर्दछ, तर प्राय: यहाँ पनि विश्वव्यापी जवाफ छ - UTF-8। यसको बारेमा राम्रो कुरा यो हो कि यसले तपाईंलाई खर्च नगरी सबै युनिकोड क्यारेक्टरहरू प्रयोग गर्न अनुमति दिन्छ पनि धेरै जसो केसहरूमा धेरै बाइटहरू। साँचो, ल्याटिन वर्णमाला भन्दा बढी प्रयोग गर्ने भाषाहरूको लागि, "धेरै होइन" कम्तिमा प्रति वर्ण दुई बाइट। के हामी प्रागैतिहासिक एन्कोडिङहरूमा फर्किनु बिना राम्रो गर्न सक्छौं जसले हामीलाई केवल 256 उपलब्ध क्यारेक्टरहरूमा सीमित गर्न सक्छ?

तल म यस प्रश्नको जवाफ दिन र अपेक्षाकृत सरल एल्गोरिथ्म लागू गर्ने मेरो प्रयाससँग परिचित हुन प्रस्ताव गर्दछु जसले तपाईंलाई UTF-8 मा रहेको अनावश्यकता थप नगरी संसारका धेरै भाषाहरूमा लाइनहरू भण्डारण गर्न अनुमति दिन्छ।

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

युनिकोड र UTF-8 को बारेमा

सुरु गर्न को लागी, यो के बारे केहि शब्दहरु युनिकोड и UTF-8.

तपाईलाई थाहा छ, 8-बिट एन्कोडिङहरू लोकप्रिय हुन्थ्यो। तिनीहरूसँग, सबै कुरा सरल थियो: 256 क्यारेक्टरहरू 0 देखि 255 सम्मका संख्याहरूसँग अंकित गर्न सकिन्छ, र 0 देखि 255 सम्मका संख्याहरू स्पष्ट रूपमा एक बाइटको रूपमा प्रतिनिधित्व गर्न सकिन्छ। यदि हामी धेरै सुरुमा फर्कियौं भने, ASCII एन्कोडिङ पूर्ण रूपमा 7 बिटहरूमा सीमित छ, त्यसैले यसको बाइट प्रतिनिधित्वमा सबैभन्दा महत्त्वपूर्ण बिट शून्य हो, र धेरै जसो 8-बिट एन्कोडिङहरू यससँग उपयुक्त छन् (तिनीहरू "माथिल्लो" मा मात्र फरक हुन्छन्। भाग, जहाँ सबैभन्दा महत्त्वपूर्ण बिट एक हो)।

युनिकोड ती सङ्केतनहरूबाट कसरी फरक छ र किन धेरै विशिष्ट प्रतिनिधित्वहरू यससँग सम्बन्धित छन् - UTF-8, UTF-16 (BE र LE), UTF-32? यसलाई क्रमबद्ध गरौं।

आधारभूत युनिकोड मानकले वर्णहरू (र केही अवस्थामा, क्यारेक्टरहरूको व्यक्तिगत घटकहरू) र तिनीहरूको संख्याहरू बीचको पत्राचारलाई मात्र वर्णन गर्दछ। र यस मानकमा धेरै सम्भावित संख्याहरू छन् - बाट 0x00 गर्न 0x10FFFF (1 टुक्रा)। यदि हामीले यस्तो दायरामा एउटा संख्यालाई चरमा राख्न चाहन्छौं भने, हाम्रो लागि 114 वा 112 बाइटहरू पर्याप्त हुनेछैन। र हाम्रा प्रोसेसरहरू तीन-बाइट नम्बरहरूसँग काम गर्नको लागि धेरै डिजाइन गरिएका छैनन्, हामी प्रति क्यारेक्टर 1 बाइटहरू प्रयोग गर्न बाध्य हुनेछौं! यो UTF-2 हो, तर यो "अपशिष्टता" को कारणले गर्दा यो ढाँचा लोकप्रिय छैन।

सौभाग्य देखि, युनिकोड भित्र क्यारेक्टरहरूको क्रम अनियमित छैन। तिनीहरूको सम्पूर्ण सेट 17 मा विभाजित छ "विमानहरू", जसमा प्रत्येकमा 65536 (0x10000) «कोड अंक" यहाँ "कोड पोइन्ट" को अवधारणा सरल छ वर्ण संख्या, युनिकोड द्वारा यसलाई तोकिएको। तर, माथि उल्लेख गरिएझैं, युनिकोडमा व्यक्तिगत क्यारेक्टरहरू मात्र संख्यामा छैनन्, तर तिनीहरूका कम्पोनेन्टहरू र सेवा चिन्हहरू पनि (र कहिलेकाहीँ केहि पनि संख्यासँग मेल खाँदैन - सायद समयको लागि, तर हाम्रो लागि यो त्यति महत्त्वपूर्ण छैन), त्यसैले। यो अधिक सही छ सधैं विशेष गरी संख्या को संख्या को बारे मा कुरा गर्नुहोस्, र प्रतीकहरु को लागी होइन। जे होस्, निम्नमा, संक्षिप्तताको खातिर, म प्रायः "कोड पोइन्ट" शब्दलाई संकेत गर्दै "प्रतीक" शब्द प्रयोग गर्नेछु।

युनिकोड विमानहरू। तपाईले देख्न सक्नुहुने रूपमा, यसको धेरैजसो (विमान 4 देखि 13) अझै प्रयोग नगरिएको छ।

सबैभन्दा उल्लेखनीय कुरा के हो भने सबै मुख्य "पल्प" शून्य समतलमा हुन्छ, यसलाई भनिन्छ "आधारभूत बहुभाषी विमान"। यदि कुनै पङ्क्तिमा कुनै एक आधुनिक भाषा (चिनियाँ सहित) मा पाठ समावेश छ भने, तपाईं यो प्लेनभन्दा बाहिर जान सक्नुहुन्न। तर तपाईंले बाँकी युनिकोडलाई पनि काट्न सक्नुहुन्न - उदाहरणका लागि, इमोजी मुख्य रूपमा यसको अन्त्यमा अवस्थित हुन्छन्। अर्को विमान"पूरक बहुभाषी विमान"(यो बाट फैलिएको छ 0x10000 गर्न 0x1FFFF)। त्यसैले UTF-16 ले यो गर्छ: सबै क्यारेक्टरहरू भित्र पर्छन् आधारभूत बहुभाषी विमान, संगत दुई-बाइट संख्या संग "जस्तै छ" इन्कोड गरिएको छ। जे होस्, यस दायराका केही संख्याहरूले खास क्यारेक्टरहरू संकेत गर्दैनन्, तर बाइटहरूको यो जोडी पछि हामीले अर्को एकलाई विचार गर्न आवश्यक छ भनेर संकेत गर्दछ - यी चार बाइटहरूको मानहरू एकसाथ जोडेर, हामीले कभर गर्ने संख्या पाउँछौं। सम्पूर्ण वैध युनिकोड दायरा। यो विचारलाई "सरोगेट जोडीहरू" भनिन्छ - तपाईंले तिनीहरूको बारेमा सुन्नु भएको होला।

त्यसैले UTF-16 लाई दुई वा (धेरै दुर्लभ अवस्थामा) प्रति "कोड पोइन्ट" चार बाइट चाहिन्छ। यो चार बाइटहरू सबै समय प्रयोग गर्नु भन्दा राम्रो छ, तर ल्याटिन (र अन्य ASCII क्यारेक्टरहरू) जब यस तरिकाले इन्कोड गरिएको छ भने शून्यमा आधा ठाउँ बर्बाद गर्दछ। UTF-8 यसलाई सुधार गर्न डिजाइन गरिएको छ: ASCII मा पहिले जस्तै, केवल एक बाइट ओगटेको छ; बाट कोडहरू 0x80 गर्न 0x7FF - दुई बाइट्स; बाट 0x800 गर्न 0xFFFF - तीन, र बाट 0x10000 गर्न 0x10FFFF - चार। एकातिर, ल्याटिन वर्णमाला राम्रो भएको छ: ASCII संग अनुकूलता फिर्ता भएको छ, र वितरण 1 देखि 4 बाइट सम्म "फैलिएको" भन्दा बढी छ। तर ल्याटिन बाहेक अन्य अक्षरहरू UTF-16 को तुलनामा कुनै पनि हिसाबले फाइदा गर्दैनन्, र धेरैलाई अब दुईको सट्टा तीन बाइटहरू चाहिन्छ - दुई-बाइट रेकर्डले कभर गरेको दायरा 32 गुणाले संकुचित भएको छ। 0xFFFF गर्न 0x7FF, र न त चिनियाँ वा, उदाहरणका लागि, जर्जियाली यसमा समावेश गरिएको छ। सिरिलिक र पाँच अन्य अक्षरहरू - हुर्रे - भाग्यशाली, 2 बाइट प्रति वर्ण।

यो किन हुन्छ? UTF-8 ले अक्षर कोडहरूलाई कसरी प्रतिनिधित्व गर्छ हेरौं:

सिधै संख्याहरू प्रतिनिधित्व गर्न, प्रतीक चिन्हित बिटहरू यहाँ प्रयोग गरिन्छ x। यो देख्न सकिन्छ कि दुई-बाइट रेकर्डमा त्यहाँ केवल 11 त्यस्ता बिटहरू छन् (१६ मध्ये)। यहाँ प्रमुख बिट्ससँग केवल सहायक प्रकार्य छ। चार-बाइट रेकर्डको मामलामा, 16 बिट्स मध्ये 21 कोड पोइन्ट नम्बरको लागि आवंटित गरिएको छ - यस्तो देखिन्छ कि तीन बाइटहरू (जसले कुल 32 बिट दिन्छ) पर्याप्त हुनेछ, तर सेवा मार्करहरूले धेरै खान्छ।

के यो खराब छ? साँच्चै होइन। एकातिर, यदि हामी ठाउँको बारेमा धेरै ख्याल राख्छौं भने, हामीसँग कम्प्रेसन एल्गोरिदमहरू छन् जसले सजिलैसँग सबै अतिरिक्त एन्ट्रोपी र रिडन्डन्सी हटाउन सक्छ। अर्कोतर्फ, युनिकोडको लक्ष्य सबैभन्दा विश्वव्यापी कोडिङ उपलब्ध गराउनु थियो। उदाहरणका लागि, हामी UTF-8 मा एन्कोड गरिएको लाइनलाई कोडमा सुम्पन सक्छौं जुन पहिले ASCII सँग मात्र काम गर्‍यो, र यसले ASCII दायराबाट एउटा क्यारेक्टर देख्नेछ जुन वास्तवमा त्यहाँ छैन (आखिरमा, UTF-8 मा सबै शून्य बिटबाट सुरु हुने बाइटहरू - यो वास्तवमा ASCII हो)। र यदि हामी अचानक सुरुबाट डिकोड नगरी ठूलो स्ट्रिङबाट सानो पुच्छर काट्न चाहन्छौं (वा क्षतिग्रस्त खण्ड पछि जानकारीको अंश पुनर्स्थापना गर्नुहोस्), हामीलाई अफसेट पत्ता लगाउन सजिलो छ जहाँ एक क्यारेक्टर सुरु हुन्छ (यो पर्याप्त छ। थोरै उपसर्ग भएका बाइटहरू छोड्न 10).

त्यसो भए किन नयाँ आविष्कार गर्ने ?

एकै समयमा, त्यहाँ कहिलेकाहीं अवस्थाहरू छन् जब डिफ्लेट जस्ता कम्प्रेसन एल्गोरिदमहरू कमजोर रूपमा लागू हुन्छन्, तर तपाईं स्ट्रिङहरूको कम्प्याक्ट भण्डारण प्राप्त गर्न चाहनुहुन्छ। व्यक्तिगत रूपमा, मैले निर्माणको बारेमा सोच्दा यो समस्याको सामना गरें संकुचित उपसर्ग रूख स्वैच्छिक भाषाहरूमा शब्दहरू सहित ठूलो शब्दकोशको लागि। एकातिर, प्रत्येक शब्द धेरै छोटो छ, त्यसैले यसलाई कम्प्रेस गर्न प्रभावकारी हुनेछ। अर्कोतर्फ, मैले विचार गरेको रूख कार्यान्वयन डिजाइन गरिएको थियो ताकि भण्डारण गरिएको स्ट्रिङको प्रत्येक बाइटले छुट्टै रूख भेर्टेक्स उत्पन्न गर्‍यो, त्यसैले तिनीहरूको संख्या कम गर्नु धेरै उपयोगी थियो। मेरो पुस्तकालयमा Az.js (जस्तै pymorphy2, जसमा यो आधारित छ) समान समस्या सरल रूपमा हल गर्न सकिन्छ - स्ट्रिङहरूमा प्याक गरिएको DAWG- शब्दकोश, त्यहाँ भण्डारण राम्रो पुरानो CP1251। तर, बुझ्न सजिलो छ, यसले सीमित वर्णमालाको लागि मात्र राम्रो काम गर्दछ - चिनियाँ भाषामा रेखा यस्तो शब्दकोशमा थप्न सकिँदैन।

अलग रूपमा, म यस्तो डेटा संरचनामा UTF-8 प्रयोग गर्दा उत्पन्न हुने एउटा थप अप्रिय nuance नोट गर्न चाहन्छु। माथिको चित्रले देखाउँछ कि जब एक क्यारेक्टरलाई दुई बाइटको रूपमा लेखिएको छ, त्यसको संख्यासँग सम्बन्धित बिटहरू पङ्क्तिमा आउँदैनन्, तर बिटहरूको जोडीद्वारा छुट्याइन्छ। 10 बिचमा: 110xxxxx 10xxxxxx। यसको कारणले गर्दा, क्यारेक्टर कोडमा दोस्रो बाइट ओभरफ्लोको तल्लो 6 बिटहरू (अर्थात, एक संक्रमण हुन्छ। 10111111 → 10000000), त्यसपछि पहिलो बाइट पनि परिवर्तन हुन्छ। यो बाहिर जान्छ कि अक्षर "p" बाइट्स द्वारा जनाइएको छ 0xD0 0xBF, र अर्को "r" पहिले नै छ 0xD1 0x80। एउटा उपसर्ग रूखमा, यसले अभिभावक नोडलाई दुई भागमा विभाजन गर्छ - एक उपसर्गको लागि 0xD0, र अर्को को लागी 0xD1 (यद्यपि सम्पूर्ण सिरिलिक वर्णमाला मात्र दोस्रो बाइट द्वारा इन्कोड गर्न सकिन्छ)।

मैले के पाए

यस समस्याको सामना गर्दै, मैले बिटहरूसँग खेल खेल्ने अभ्यास गर्ने निर्णय गरें, र एकै समयमा समग्र रूपमा युनिकोडको संरचनासँग अलि राम्रोसँग परिचित हुनुहोस्। परिणाम UTF-C एन्कोडिङ ढाँचा ("C" को लागि संकुचित), जसले प्रति कोड बिन्दु 3 बाइट्स भन्दा बढी खर्च गर्दैन, र प्राय: तपाईंलाई मात्र खर्च गर्न अनुमति दिन्छ सम्पूर्ण एन्कोड गरिएको लाइनको लागि एक अतिरिक्त बाइट। यसले यस तथ्यलाई निम्त्याउँछ कि धेरै गैर-ASCII अक्षरहरूमा यस्तो एन्कोडिङ बाहिर निस्कन्छ UTF-30 भन्दा 60-8% बढी कम्प्याक्ट.

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

परीक्षण परिणामहरू र UTF-8 सँग तुलना

मैले पनि गरेँ डेमो पृष्ठ, जहाँ तपाइँ एल्गोरिथ्मको प्रदर्शनको मूल्याङ्कन गर्न सक्नुहुन्छ, र त्यसपछि म तपाइँलाई यसको सिद्धान्त र विकास प्रक्रियाको बारेमा थप बताउनेछु।

अनावश्यक बिटहरू हटाउँदै

मैले UTF-8 लाई आधारको रूपमा लिएको छु। यसमा परिवर्तन गर्न सकिने पहिलो र सबैभन्दा स्पष्ट कुरा भनेको प्रत्येक बाइटमा सेवा बिट्सको संख्या घटाउनु हो। उदाहरण को लागी, UTF-8 मा पहिलो बाइट सधैं या त संग सुरु हुन्छ 0, वा संग 11 - एक उपसर्ग 10 केवल निम्न बाइटहरूमा यो छ। उपसर्ग प्रतिस्थापन गरौं 11 मा 1, र अर्को बाइटहरूको लागि हामी उपसर्गहरू पूर्ण रूपमा हटाउनेछौं। के हुनेछ?

0xxxxxxx - 1 बाइट
10xxxxxx xxxxxxxx - 2 बाइट्स
110xxxxx xxxxxxxx xxxxxxxx - 3 बाइट्स

पर्खनुहोस्, चार-बाइट रेकर्ड कहाँ छ? तर यो अब आवश्यक छैन - तीन बाइटहरूमा लेख्दा, हामीसँग अब 21 बिटहरू उपलब्ध छन् र यो सबै नम्बरहरूका लागि पर्याप्त छ। 0x10FFFF.

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

2 बाइटहरू सहित भाषाहरू कभर गर्ने अवस्था पनि राम्रो भएको छ: अब दुई-बाइट ढाँचाले 14 बिटहरूको दायरा दिन्छ, र यी कोडहरू छन्। 0x3FFF। चिनियाँहरू अशुभ छन् (तिनीहरूका क्यारेक्टरहरू प्रायः बाट 0x4E00 गर्न 0x9FFF), तर जर्जियनहरू र धेरै अन्य मानिसहरूसँग बढी रमाइलो छ - तिनीहरूका भाषाहरू पनि प्रति क्यारेक्टर २ बाइटहरूमा फिट हुन्छन्।

एन्कोडर स्थिति प्रविष्ट गर्नुहोस्

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

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

बंगाली वर्णमालाका वर्णहरू समावेश भएको ब्लक। दुर्भाग्यवश, ऐतिहासिक कारणहरूका लागि, यो धेरै घना प्याकेजिङको उदाहरण हो - 96 वर्णहरू 128 ब्लक कोड बिन्दुहरूमा अराजक रूपमा छरिएका छन्।

ब्लकहरूको सुरुवात र तिनीहरूको साइजहरू सधैं 16 को गुणन हुन्छन् - यो सुविधाको लागि मात्र गरिन्छ। थप रूपमा, धेरै ब्लकहरू 128 वा 256 को गुणन मानहरूमा सुरु र अन्त्य हुन्छन् - उदाहरणका लागि, आधारभूत सिरिलिक वर्णमालाले 256 बाइटहरू लिन्छ। 0x0400 गर्न 0x04FF। यो एकदम सुविधाजनक छ: यदि हामीले एक पटक उपसर्ग बचत गर्छौं 0x04, त्यसपछि कुनै पनि सिरिलिक वर्ण एक बाइट मा लेख्न सकिन्छ। साँचो, यस तरिकाले हामीले ASCII (र सामान्य रूपमा कुनै पनि अन्य क्यारेक्टरहरूमा) फर्कने अवसर गुमाउनेछौं। त्यसैले हामी यो गर्छौं:

1. दुई बाइट्स 10yyyyyy yxxxxxxx संख्याको साथ प्रतीक मात्र होइन yyyyyy yxxxxxxx, तर पनि परिवर्तन वर्तमान वर्णमाला मा yyyyyy y0000000 (अर्थात् हामीले थोरै महत्वपूर्ण बाहेक सबै बिट्स सम्झन्छौं 7 बिट);
2. एक बाइट 0xxxxxxx यो वर्तमान वर्णमाला को वर्ण हो। यो केवल अफसेटमा थप्न आवश्यक छ जुन हामीले चरण 1 मा सम्झेका छौं। हामीले वर्णमाला परिवर्तन गरेनौं, अफसेट शून्य छ, त्यसैले हामीले ASCII सँग अनुकूलता कायम राख्यौं।

त्यस्तै गरी 3 बाइटहरू आवश्यक पर्ने कोडहरूको लागि:

1. तीन बाइट्स 110yyyyy yxxxxxxx xxxxxxxx संख्याको साथ प्रतीक संकेत गर्नुहोस् yyyyyy yxxxxxxx xxxxxxxx, परिवर्तन वर्तमान वर्णमाला मा yyyyyy y0000000 00000000 (साना बाहेक सबै याद आयो 15 बिट), र बक्स जाँच गर्नुहोस् जुन हामी अहिले छौं लामो मोड (अक्षरलाई डबल-बाइटमा परिवर्तन गर्दा, हामी यो झण्डा रिसेट गर्नेछौं);
2. दुई बाइट्स 0xxxxxxx xxxxxxxx लामो मोडमा यो हालको वर्णमालाको वर्ण हो। त्यसै गरी, हामी यसलाई चरण 1 बाट अफसेटसँग थप्छौं। फरक यति हो कि अब हामी दुई बाइटहरू पढ्छौं (किनकि हामीले यो मोडमा स्विच गर्यौं)।

राम्रो लाग्दछ: अब हामीले एउटै 7-बिट युनिकोड दायराबाट क्यारेक्टरहरू इन्कोड गर्न आवश्यक छ, हामी सुरुमा 1 अतिरिक्त बाइट र प्रति क्यारेक्टर कुल एक बाइट खर्च गर्छौं।

अघिल्लो संस्करणहरू मध्ये एकबाट काम गर्दै। यसले पहिले नै UTF-8 लाई पहिले नै हराउँछ, तर अझै पनि सुधारको लागि ठाउँ छ।

के खराब छ? पहिलो, हामीसँग एउटा शर्त छ, अर्थात् वर्तमान वर्णमाला अफसेट र चेकबक्स लामो मोड। यसले हामीलाई थप सीमित गर्दछ: अब एउटै क्यारेक्टरहरू विभिन्न सन्दर्भहरूमा फरक इन्कोड गर्न सकिन्छ। उदाहरणका लागि, सबस्ट्रिङहरूको खोजी गर्दा यसलाई ध्यानमा राखेर गर्नुपर्छ, बाइटहरू तुलना गरेर मात्र होइन। दोस्रो, हामीले वर्णमाला परिवर्तन गर्ने बित्तिकै, यो ASCII क्यारेक्टरहरूको एन्कोडिङको साथ खराब भयो (र यो ल्याटिन वर्णमाला मात्र होइन, आधारभूत विराम चिह्नहरू पनि हो, खाली ठाउँहरू सहित) - तिनीहरूले वर्णमाला फेरि ० मा परिवर्तन गर्न आवश्यक छ, अर्थात्, फेरि एक अतिरिक्त बाइट (र त्यसपछि अर्को हाम्रो मुख्य बिन्दुमा फर्कन)।

एउटा वर्णमाला राम्रो छ, दुई राम्रो छ

हाम्रो बिट उपसर्गहरू थोरै परिवर्तन गर्ने प्रयास गरौं, माथि वर्णन गरिएका तीनहरूमा थप एकमा निचोड गर्दै:

0xxxxxxx - सामान्य मोडमा 1 बाइट, लामो मोडमा 2
11xxxxxx - 1 बाइट
100xxxxx xxxxxxxx - 2 बाइट्स
101xxxxx xxxxxxxx xxxxxxxx - 3 बाइट्स

अब दुई-बाइट रेकर्डमा त्यहाँ एक कम उपलब्ध बिट छ - कोड अंकहरू सम्म 0x1FFFर होइन 0x3FFF। जे होस्, यो अझै पनि डबल-बाइट UTF-8 कोडहरू भन्दा उल्लेखनीय रूपमा ठूलो छ, धेरै सामान्य भाषाहरू अझै पनि फिट छन्, सबैभन्दा उल्लेखनीय हानि झरेको छ। हिरागाना и काताकानाजापानीहरू दुःखी छन्।

यो नयाँ कोड के हो? 11xxxxxx? यो आकारमा 64 वर्णहरूको सानो "स्ट्याश" हो, यसले हाम्रो मुख्य वर्णमालालाई पूरक बनाउँछ, त्यसैले मैले यसलाई सहायक भनिन्छ (सहायक) वर्णमाला। जब हामी हालको वर्णमाला स्विच गर्छौं, पुरानो वर्णमालाको एक टुक्रा सहायक हुन्छ। उदाहरणका लागि, हामीले ASCII बाट सिरिलिकमा स्विच गर्यौं - स्ट्यासमा अब 64 वर्णहरू समावेश छन्। ल्याटिन वर्णमाला, संख्या, स्पेस र अल्पविराम (गैर-ASCII पाठहरूमा धेरै पटक सम्मिलितहरू)। ASCII मा फर्कनुहोस् - र सिरिलिक वर्णमालाको मुख्य भाग सहायक वर्णमाला हुनेछ।

दुई अक्षरहरूमा पहुँचको लागि धन्यवाद, हामी अक्षरहरू स्विच गर्नको लागि न्यूनतम लागतमा ठूलो संख्यामा पाठहरू ह्यान्डल गर्न सक्छौं (विराम चिन्हले प्राय: ASCII मा फर्किनेछ, तर त्यस पछि हामीले अतिरिक्त वर्णमालाबाट धेरै गैर-ASCII वर्णहरू प्राप्त गर्नेछौं, बिना। फेरि स्विच गर्दै)।

बोनस: उप-वर्णमाला उपसर्ग गर्दै 11xxxxxx र यसको प्रारम्भिक अफसेट हुन छनौट गर्दै 0xC0, हामीले CP1252 सँग आंशिक अनुकूलता पाउँछौं। अर्को शब्दमा, CP1252 मा इन्कोड गरिएका धेरै (तर सबै होइन) पश्चिमी युरोपेली पाठहरू UTF-C मा उस्तै देखिनेछन्।

यहाँ, तथापि, एक कठिनाई उत्पन्न हुन्छ: कसरी मुख्य वर्णमालाबाट सहायक प्राप्त गर्ने? तपाइँ उही अफसेट छोड्न सक्नुहुन्छ, तर - अफसोस - यहाँ युनिकोड संरचना पहिले नै हाम्रो विरुद्ध खेलिरहेको छ। प्रायः वर्णमालाको मुख्य भाग ब्लकको सुरुमा हुँदैन (उदाहरणका लागि, रूसी राजधानी "ए" कोड छ। 0x0410, यद्यपि सिरिलिक ब्लक बाट सुरु हुन्छ 0x0400)। यसरी, स्ट्यासमा पहिलो 64 क्यारेक्टरहरू लिएर, हामीले वर्णमालाको पुच्छरमा पहुँच गुमाउन सक्छौं।

यो समस्या समाधान गर्न, मैले विभिन्न भाषाहरूसँग सम्बन्धित केही ब्लकहरू म्यानुअल रूपमा गएँ, र तिनीहरूका लागि मुख्य एक भित्र सहायक वर्णमालाको अफसेट निर्दिष्ट गरें। ल्याटिन वर्णमाला, एक अपवादको रूपमा, सामान्यतया base64 जस्तै पुन: क्रमबद्ध गरिएको थियो।

अन्तिम स्पर्श

अन्तमा हामी कहाँ केहि सुधार गर्न सक्छौं भनेर सोचौं।

नोट गर्नुहोस् कि ढाँचा 101xxxxx xxxxxxxx xxxxxxxx सम्म नम्बरहरू इन्कोड गर्न अनुमति दिन्छ 0x1FFFFF, र युनिकोड पहिले समाप्त हुन्छ, मा 0x10FFFF। अर्को शब्दमा, अन्तिम कोड बिन्दु को रूपमा प्रतिनिधित्व गरिनेछ 10110000 11111111 11111111। त्यसकारण, हामी भन्न सक्छौं कि यदि पहिलो बाइट फारमको हो 1011xxxx (कहाँ xxxx ० भन्दा ठुलो), तब यसको अर्थ केहि अर्कै हुन्छ। उदाहरण को लागी, तपाइँ त्यहाँ अर्को 0 क्यारेक्टरहरू थप्न सक्नुहुन्छ जुन एक बाइटमा इन्कोडिङको लागि निरन्तर उपलब्ध छन्, तर मैले यसलाई फरक तरिकाले गर्ने निर्णय गरे।

ती युनिकोड ब्लकहरू हेरौं जसलाई अब तीन बाइटहरू चाहिन्छ। मूलतया, पहिले नै उल्लेख गरिए अनुसार, यी चिनियाँ क्यारेक्टरहरू हुन् - तर तिनीहरूसँग केहि गर्न गाह्रो छ, त्यहाँ 21 हजार छन्। तर हिरागाना र काताकाना पनि त्यहाँ उडे - र त्यहाँ ती मध्ये धेरै छैनन्, दुई सय भन्दा कम। र, हामीले जापानी सम्झनामा, त्यहाँ इमोजीहरू पनि छन् (वास्तवमा, तिनीहरू युनिकोडमा धेरै ठाउँहरूमा छरिएका छन्, तर मुख्य ब्लकहरू दायरामा छन्। 0x1F300 - 0x1FBFF)। यदि तपाइँ यस तथ्यको बारेमा सोच्नुहुन्छ कि अब त्यहाँ इमोजीहरू छन् जुन एकै पटक धेरै कोड बिन्दुहरूबाट भेला हुन्छन् (उदाहरणका लागि, इमोजी ‍‍‍ 7 कोडहरू सम्मिलित हुन्छन्!), त्यसपछि प्रत्येकमा तीन बाइटहरू खर्च गर्न पूर्ण शर्मको कुरा हुन्छ (7 × 3 = 21 बाइटहरू एउटा प्रतिमाको लागि, एउटा दुःस्वप्न)।

तसर्थ, हामी इमोजी, हिरागाना र काताकानासँग सम्बन्धित केही चयन गरिएका दायराहरू चयन गर्छौं, तिनीहरूलाई एउटा निरन्तर सूचीमा पुन: सङ्ख्या गर्छौं र तिनीहरूलाई तीनको सट्टा दुई बाइटको रूपमा सङ्केत गर्छौं:

1011xxxx xxxxxxxx

उत्कृष्ट: माथि उल्लिखित इमोजी, 7 कोड बिन्दुहरू मिलेर, UTF-8 मा 25 बाइटहरू लिन्छ, र हामी यसलाई फिट गर्छौं 14 (प्रत्येक कोड बिन्दुको लागि ठ्याक्कै दुई बाइट्स)। वैसे, Habr ले यसलाई पचाउन अस्वीकार गर्‍यो (पुरानो र नयाँ सम्पादक दुबैमा), त्यसैले मैले यसलाई तस्वीरको साथ सम्मिलित गर्नुपर्‍यो।

अर्को समस्या समाधान गर्ने प्रयास गरौं। हामी सम्झन्छौं, आधारभूत वर्णमाला अनिवार्य रूपमा हो उच्च 6 बिट, जुन हामी दिमागमा राख्छौं र प्रत्येक अर्को डिकोड गरिएको प्रतीकको कोडमा टाँस्छौं। चिनियाँ क्यारेक्टरहरूको मामलामा जुन ब्लकमा छन् 0x4E00 - 0x9FFF, यो या त बिट ० वा १ हो। यो धेरै सुविधाजनक छैन: हामीले यी दुई मानहरू (अर्थात् तीन बाइटहरू खर्च गर्नुहोस्) बीचको वर्णमालालाई निरन्तर रूपमा स्विच गर्न आवश्यक छ। तर नोट गर्नुहोस् कि लामो मोडमा, कोडबाट नै हामीले छोटो मोड प्रयोग गरेर सङ्केत गर्ने क्यारेक्टरहरूको संख्या घटाउन सक्छौं (माथि वर्णन गरिएका सबै चालहरू पछि, यो 0 हो) - त्यसपछि हाइरोग्लिफहरूको दायरा परिवर्तन हुनेछ। 0x2600 - 0x77FF, र यस अवस्थामा, यस सम्पूर्ण दायरामा, सबैभन्दा महत्त्वपूर्ण 6 बिट्स (२१ मध्ये) ० को बराबर हुनेछ। यसरी, हाइरोग्लिफको अनुक्रमले दुई बाइटहरू प्रति हाइरोग्लिफ (जुन यति ठूलो दायराको लागि इष्टतम छ) प्रयोग गर्नेछ। वर्णमाला स्विचको कारण।

वैकल्पिक समाधान: SCSU, BOCU-1

युनिकोड विशेषज्ञहरू, लेखको शीर्षक पढिसकेपछि, सम्भवतः तपाईंलाई सम्झाउन हतार हुनेछ कि युनिकोड मापदण्डहरू बीच सीधा छ। युनिकोडका लागि मानक सङ्कुचन योजना (SCSU), जसले लेखमा वर्णन गरिएकोसँग मिल्दोजुल्दो एन्कोडिङ विधिको वर्णन गर्दछ।

म इमानदारीपूर्वक स्वीकार गर्छु: मैले मेरो निर्णय लेख्न गहिरो डुबे पछि मात्र यसको अस्तित्वको बारेमा थाहा पाएँ। यदि मलाई यसको बारेमा सुरुदेखि नै थाहा भएको भए, मैले आफ्नै दृष्टिकोणको साथ आउनुको सट्टा कार्यान्वयन लेख्ने प्रयास गरेको थिएँ।

चाखलाग्दो कुरा के छ भने SCSU ले आफूले आफैले लिएका विचारहरूसँग मिल्दोजुल्दो विचारहरू प्रयोग गर्दछ ("अक्षरहरू" को अवधारणाको सट्टा तिनीहरूले "विन्डोज" प्रयोग गर्छन्, र त्यहाँ मसँग भन्दा धेरै उपलब्ध छन्)। एकै समयमा, यो ढाँचामा पनि बेफाइदाहरू छन्: यो एन्कोडिङ भन्दा कम्प्रेसन एल्गोरिदमको अलि नजिक छ। विशेष गरी, मानकले धेरै प्रतिनिधित्व विधिहरू दिन्छ, तर इष्टतम कसरी छनौट गर्ने भनेर बताउँदैन - यसको लागि, एन्कोडरले केही प्रकारको हेरिस्टिक्स प्रयोग गर्नुपर्छ। यसैले, राम्रो प्याकेजिङ्ग उत्पादन गर्ने SCSU एन्कोडर मेरो एल्गोरिथ्म भन्दा बढी जटिल र थप बोझिल हुनेछ।

तुलनाको लागि, मैले SCSU को तुलनात्मक रूपमा सरल कार्यान्वयन JavaScript मा स्थानान्तरण गरें - कोड भोल्युमको हिसाबले यो मेरो UTF-C सँग तुलना गर्न मिल्ने भयो, तर केही अवस्थामा नतिजा दशौं प्रतिशत खराब थियो (कहिलेकाहीँ यो यो भन्दा बढी हुन सक्छ, तर धेरै होइन)। उदाहरणका लागि, हिब्रू र ग्रीक भाषाका पाठहरू UTF-C द्वारा इन्कोड गरिएको थियो SCSU भन्दा ६०% राम्रो (सम्भवतः तिनीहरूको संकुचित अक्षरहरूको कारणले)।

अलग रूपमा, म थप्छु कि SCSU बाहेक युनिकोडलाई सघन रूपमा प्रतिनिधित्व गर्ने अर्को तरिका पनि छ - BOCU-1, तर यसले MIME अनुकूलताको लागि लक्ष्य राख्छ (जुन मलाई आवश्यक थिएन) र एन्कोडिङमा अलि फरक दृष्टिकोण लिन्छ। मैले यसको प्रभावकारिताको मूल्याङ्कन गरेको छैन, तर मलाई लाग्छ कि यो SCSU भन्दा उच्च हुने सम्भावना छैन।

सम्भावित सुधारहरू

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

उदाहरणका लागि, स्पष्ट तरिकामा तपाईले राज्यको उपस्थितिबाट छुटकारा पाउन सक्नुहुन्छ, स्टेटलेस कोडिङ बनाउन सक्नुहुन्छ - केवल चरहरू अद्यावधिक नगर्नुहोस्। offs, auxOffs и is21Bit एन्कोडर र डिकोडरमा। यस अवस्थामा, एउटै वर्णमालाको क्यारेक्टरहरूको अनुक्रमहरू प्रभावकारी रूपमा प्याक गर्न सम्भव छैन, तर त्यहाँ एक ग्यारेन्टी हुनेछ कि उही क्यारेक्टर सधैं एउटै बाइटहरू संग इन्कोड गरिएको छ, सन्दर्भको पर्वाह नगरी।

थप रूपमा, तपाईंले पूर्वनिर्धारित अवस्था परिवर्तन गरेर विशिष्ट भाषामा इन्कोडरलाई टेलर गर्न सक्नुहुन्छ - उदाहरणका लागि, रूसी पाठहरूमा ध्यान केन्द्रित गर्दै, सुरुमा इन्कोडर र डिकोडर सेट गर्नुहोस्। offs = 0x0400 и auxOffs = 0। यो विशेष गरी स्टेटलेस मोड को मामला मा अर्थ बनाउँछ। सामान्यतया, यो पुरानो आठ-बिट एन्कोडिङ प्रयोग गर्न मिल्दोजुल्दो हुनेछ, तर आवश्यकता अनुसार सबै युनिकोडबाट क्यारेक्टरहरू सम्मिलित गर्ने क्षमता नहटाई।

पहिले उल्लेख गरिएको अर्को कमजोरी यो हो कि UTF-C मा एन्कोड गरिएको ठूलो पाठमा स्वेच्छाचारी बाइटको नजिक क्यारेक्टर बाउन्ड्री फेला पार्ने कुनै द्रुत तरिका छैन। यदि तपाईंले एन्कोड गरिएको बफरबाट 100 बाइटहरू अन्तिममा काट्नु भयो भने, तपाईंले केही गर्न नसक्ने फोहोर हुने खतरा हुन्छ। इन्कोडिङ बहु-गीगाबाइट लगहरू भण्डारण गर्नको लागि डिजाइन गरिएको छैन, तर सामान्यतया यसलाई सच्याउन सकिन्छ। बाइट 0xBF पहिलो बाइटको रूपमा कहिल्यै देखा पर्दैन (तर दोस्रो वा तेस्रो हुन सक्छ)। तसर्थ, एन्कोडिङ गर्दा, तपाइँ अनुक्रम सम्मिलित गर्न सक्नुहुन्छ 0xBF 0xBF 0xBF हरेक, भन्नुहोस्, 10 KB - त्यसोभए, यदि तपाइँलाई बाउन्ड्री फेला पार्न आवश्यक छ भने, समान मार्कर नभेटेसम्म चयन गरिएको टुक्रा स्क्यान गर्न पर्याप्त हुनेछ। पछिल्लो पछ्याउँदै 0xBF चरित्रको सुरुवात हुने ग्यारेन्टी छ। (डिकोडिङ गर्दा, तीन बाइटहरूको यो अनुक्रम, अवश्य पनि, बेवास्ता गर्न आवश्यक छ।)

संक्षेप गर्न

यदि तपाईंले यो सम्म पढ्नुभयो भने, बधाई छ! मलाई आशा छ कि तपाईले, म जस्तै, युनिकोडको संरचनाको बारेमा केहि नयाँ (वा तपाईको मेमोरी ताजा) सिक्नुभएको छ।

डेमो पृष्ठ। हिब्रूको उदाहरणले UTF-8 र SCSU दुवैमा फाइदाहरू देखाउँछ।

माथि वर्णन गरिएको अनुसन्धानलाई मापदण्डको अतिक्रमण मान्नु हुँदैन। यद्यपि, म सामान्यतया मेरो कामको नतिजाबाट सन्तुष्ट छु, त्यसैले म तिनीहरूसँग खुसी छु साझेदारी गर्नुहोस्: उदाहरणका लागि, एउटा सानो JS पुस्तकालयको तौल मात्र 1710 बाइट हुन्छ (र निश्चित रूपमा कुनै निर्भरता छैन)। मैले माथि उल्लेख गरे अनुसार, उनको काम मा पाउन सकिन्छ डेमो पृष्ठ (त्यहाँ पाठहरूको सेट पनि छ जसमा यसलाई UTF-8 र SCSU सँग तुलना गर्न सकिन्छ)।

अन्तमा, म फेरि एक पटक UTF-C प्रयोग गरिएका केसहरूमा ध्यान आकर्षित गर्नेछु यसको लायक छैन:

• यदि तपाईंको लाइनहरू पर्याप्त लामो छन् (100-200 वर्णहरूबाट)। यस अवस्थामा, तपाईंले कम्प्रेसन एल्गोरिदमहरू जस्तै डिफ्लेट प्रयोग गर्ने बारे सोच्नु पर्छ।
• यदि तपाईंलाई आवश्यक छ भने ASCII पारदर्शिता, अर्थात्, यो तपाईंको लागि महत्त्वपूर्ण छ कि एन्कोड गरिएका अनुक्रमहरूमा ASCII कोडहरू समावेश छैनन् जुन मूल स्ट्रिङमा थिएनन्। यदि, तेस्रो-पक्ष API हरू (उदाहरणका लागि, डाटाबेससँग काम गर्ने) सँग अन्तरक्रिया गर्दा, तपाईंले एन्कोडिङ परिणामलाई बाइटहरूको अमूर्त सेटको रूपमा पास गर्नुभयो भने, स्ट्रिङको रूपमा नभई यो आवश्यकताबाट बच्न सकिन्छ। अन्यथा, तपाइँ अप्रत्याशित कमजोरीहरू प्राप्त गर्न जोखिममा हुनुहुन्छ।
• यदि तपाइँ चाँडै एक स्वेच्छाचारी अफसेटमा क्यारेक्टर सीमाहरू फेला पार्न सक्षम हुन चाहनुहुन्छ भने (उदाहरणका लागि, जब रेखाको अंश क्षतिग्रस्त हुन्छ)। यो गर्न सकिन्छ, तर सुरुबाट लाइन स्क्यान गरेर मात्र (वा अघिल्लो खण्डमा वर्णन गरिएको परिमार्जन लागू गरेर)।
• यदि तपाईँले स्ट्रिङका सामग्रीहरूमा तुरुन्तै कार्यहरू गर्न आवश्यक छ भने (तिनीहरूलाई क्रमबद्ध गर्नुहोस्, तिनीहरूमा सबस्ट्रिङहरू खोज्नुहोस्, कन्केटनेट गर्नुहोस्)। यसका लागि स्ट्रिङहरू पहिले डिकोड गर्न आवश्यक छ, त्यसैले UTF-C यी ​​केसहरूमा UTF-8 भन्दा ढिलो हुनेछ (तर कम्प्रेसन एल्गोरिदमहरू भन्दा छिटो)। उही स्ट्रिङ सधैं एउटै तरिकाले इन्कोड गरिएको हुनाले, डिकोडिङको सटीक तुलना आवश्यक पर्दैन र बाइट-द्वारा-बाइट आधारमा गर्न सकिन्छ।

अपडेट: प्रयोगकर्ता ट्योमिच तल टिप्पणीहरूमा UTF-C को उपयोगिता सीमाहरू हाइलाइट गर्ने ग्राफ पोस्ट गरियो। यसले देखाउँछ कि UTF-C सामान्य-उद्देश्य कम्प्रेसन एल्गोरिथ्म (LZW को एक भिन्नता) भन्दा बढी कुशल छ जबसम्म प्याक गरिएको स्ट्रिङ छोटो छ। ~140 वर्णहरू (यद्यपि, म नोट गर्छु कि तुलना एक पाठमा गरिएको थियो; अन्य भाषाहरूको लागि परिणाम फरक हुन सक्छ)।


स्रोत: www.habr.com