Linenoise: मल्टीबाइट सपोर्ट जोड़ें

देखें: http://www.cl.cam.ac.uk/~mgk25/unicode.html

मेरे कांटे पर एक नज़र डालें, https://github.com/msteveb/linenoise , जिसमें utf-8 के लिए समर्थन है

क्या आपको वास्तव में उन सभी कार्यों की आवश्यकता है? मैं सामान से काफी परिचित नहीं हूं लेकिन मैंने कुछ अजीब समस्याओं को आसानी से mbstowcs() के बजाय strlen() का उपयोग करके ठीक किया है जहां स्ट्रिंग की लंबाई स्ट्रिंग में वर्णों की संख्या के बराबर मानी जाती है। लेकिन मुझे बैकस्पेस के साथ विस्तृत वर्णों को हटाने का तरीका नहीं मिला ..

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

मेरा भी वही मुद्दा है; मैंने शेल कार्यान्वयन के लिए लाइन-शोर की कोशिश की। अगर मुझे रंगीन संकेत चाहिए, तो एस्केप-कोड को लंबाई गणना में शामिल किया जा रहा है।

एक सरल, आसान समाधान या तो है:

1) प्रॉम्प्ट की लंबाई स्वयं निर्दिष्ट करने की अनुमति दें।
2) प्रॉम्प्ट को आउटपुट करने के बाद कर्सर की स्थिति निकालने के लिए टर्मिनल कमांड का उपयोग करें (सुनिश्चित नहीं है कि यह संभव है)

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

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

मेरे कांटे पर 'utf-8 सपोर्ट' शाखा ने निम्नलिखित UTF-8 समस्याओं को ठीक किया जो नवीनतम लिनेनोइस संस्करण 1.0 में दिखाई देती हैं:

• मल्टी-बाइट वर्ण: ö (U+00F6)
• बहु-कोड वर्ण: ö (U+006F U+0308)
• विस्तृत वर्ण: 日本語 ('जापानी')
• उपरोक्त वर्णों सहित शीघ्र पाठ और ANSI रंगीन पाठ से बच गए।

मैंने पहली बार https://github.com/msteveb/linenoise की कोशिश की

हैलो, मैं इस मुद्दे के साथ निम्नलिखित मार्ग पर जाने के बारे में सोच रहा हूं:

1. सी सादे स्ट्रिंग फ़ंक्शंस को बहु-बाइट जागरूक लोगों द्वारा प्रतिस्थापित किया जाना चाहिए, यह जांचने के लिए संदर्भ के रूप में @yhirose का उपयोग करें।
2. एक एपीआई निर्यात करें जो लाइननोइस उपयोगकर्ता को स्ट्रिंग लंबाई गणना के लिए वैकल्पिक फ़ंक्शन सेट करने की अनुमति देता है। फ़ंक्शन को सादे C फ़ंक्शंस में डिफ़ॉल्ट के रूप में सेट करें।
3. एक अलग फ़ाइल के रूप में @yhirose कोड शामिल करें जिसे आप अपने एप्लिकेशन में जोड़ सकते हैं, मल्टी-बाइट समर्थन के लिए, लंबाई फ़ंक्शन सेट करने के लिए लिनेनोइस नए फ़ंक्शन को कॉल कर सकते हैं।

इस तरह हम प्राप्त करते हैं कि लिनेनोइस सादगी लगभग अछूती रहती है, लेकिन वैकल्पिक रूप से यह दोनों C++ फ़ंक्शंस के साथ मल्टी बाइट वर्णों का समर्थन करना संभव है, अन्य उपयोगकर्ता द्वारा प्रदान किए गए फ़ंक्शन मानक वाले से अलग हैं, या लिननोइस में शामिल हैं यदि आपका प्रोजेक्ट सी में है और आप फिर से लिखना नहीं चाहते हैं जो @yhirose ने पहले ही बार-बार लिखा है।

आपको समझ में आता है? धन्यवाद।

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

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

• あ (यू+3042): E3 81 82 (3 बाइट्स): चौड़ा (2 कॉलम चौड़ाई)
• ö (U+00F6): C3 B6 (2 बाइट्स): संकीर्ण (1 कॉलम चौड़ाई)
• ö (यू+006एफ यू+0308): 6F CC 88 (3 बाइट्स): संकीर्ण (1 कॉलम चौड़ाई)

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

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

एक और चीज जो मैंने की है वह है तीसरी प्रतिबद्धता में कॉलम स्थिति/चौड़ाई की गणना करते समय सभी एएनएसआई एस्केप अनुक्रम वर्णों को छोड़ना। यह परिवर्तन हमें शीघ्र पाठ में रंग का उपयोग करने में सक्षम बनाता है।

मैं निकट भविष्य में नए एपीआई को देखने के लिए वास्तव में उत्साहित हूं। कृपया मुझे बताएं कि क्या इस मामले पर आपके कोई प्रश्न हैं। मुझे यकीन है कि आप शानदार काम करेंगे !!

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

शोध के आधार पर, मैंने अपनी शाखा को अद्यतन किया है। यहाँ लिनेनोइस हेड और utf8-support शाखा के बीच का अंतर है । जैसा कि आप वहां देख सकते थे, मैंने linenoise.c से पूरी तरह से सभी UTF-8 विशिष्ट कोड से छुटकारा पा लिया और उन्हें encodings/utf8.h और encodings/utf8.c में डाल दिया। इसके अलावा, मैंने linenoise.h पर linenoiseSetEncodingFunctions नामक एक प्रयोग API जोड़ा, ताकि उपयोगकर्ता एन्कोडिंग फ़ंक्शन का अपना सेट सेट कर सकें। मैंने पुष्टि की कि सभी कार्य अभी भी काम कर रहे हैं।

यहाँ मेरे वर्तमान प्रायोगिक API का एक अंश है:

typedef size_t (linenoisePrevCharLen)(const char *buf, size_t buf_len, size_t pos, size_t *col_len);
typedef size_t (linenoiseNextCharLen)(const char *buf, size_t buf_len, size_t pos, size_t *col_len);
typedef size_t (linenoiseReadCode)(int fd, char *buf, size_t buf_len, int* c);

void linenoiseSetEncodingFunctions(
    linenoisePrevCharLen *prevCharLenFunc,
    linenoiseNextCharLen *nextCharLenFunc,
    linenoiseReadCode *readCodeFunc);

linenoisePrevCharLen और linenoiseNextCharLen वापसी मूल्य के रूप में बाइट लंबाई लौटाएं, और कॉलम लंबाई को col_len पैरामीटर पर सेट करें । linenoiseReadCode बाइट्स को buf में पढ़ता है, और बाइट्स को परिवर्तित करता है और एन्कोडिंग के लिए एक सार्थक वर्ण कोड को c पैरामीटर पर सेट करता है।

यदि उपयोगकर्ता linenoiseSetEncodingFunctions कॉल नहीं करते हैं, तो यह _default_ कार्यान्वयन को कॉल करना समाप्त कर देगा। वे बस एक चरित्र के रूप में _one बाइट_ को संभालते हैं।

आशा है कि जब आप नई एन्कोडिंग एपीआई डिज़ाइन करेंगे तो पोस्ट मददगार होगी। मेरे द्वारा इसकी वास्तव में प्रतीक्षा की जा रही है!!

@yhirose यह एक शानदार काम है !!! :-) मैं कोड की जांच करने और इसे मर्ज करने जा रहा हूं। इसके लिए शुक्रिया।

अभी तक विलय नहीं हुआ?

@antirez विलय पर कोई प्रगति?

मैंने अपने कांटे को संशोधित किया है (https://github.com/yhirose/linenoise/tree/utf8-support) मूल लिनेनोइस में किए गए हालिया परिवर्तनों जैसे 'संकेत' सुविधा के साथ पकड़ने के लिए।

बहुत बहुत धन्यवाद @yhirose। आपने अच्छा कोड बेहतर बनाया है! और मेरा
काम आसान!

@सोनोफोटो

सोम को, २७ जून २०१६ १८:५६:४५ -0700, येरोज़ ने लिखा:

   I have modified my fork 

(https://github.com/yhirose/linenoise/tree/utf8-support) को पकड़ने के लिए
मूल लिनेनोइस जैसे 'संकेत' में किए गए हालिया परिवर्तनों के साथ
विशेषता।
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

*

मेरा कांटा (https://github.com/yhirose/linenoise/tree/utf8-support) अब यूनिकोड 9.0 का समर्थन करता है।

@antirez क्या आपके पास निकट भविष्य में @yhirose के मल्टी-बाइट समर्थन को मर्ज करने के लिए खाली समय होगा? या हमें तब तक @yhirose के कांटे का उपयोग करने के लिए https://github.com/hoelzro/lua-linenoise स्विच करना चाहिए? ️

मेरा कांटा (https://github.com/yhirose/linenoise/tree/utf8-support) अब यूनिकोड 11.0 का समर्थन करता है और इसमें एंटीरेज़/लाइनोइस में किए गए सभी हालिया परिवर्तन शामिल हैं।

मेरा कांटा (https://github.com/yhirose/linenoise/tree/utf8-support) अब यूनिकोड 12.1 का समर्थन करता है।

मेरा कांटा (https://github.com/yhirose/linenoise/tree/utf8-support) अब यूनिकोड 13.0 का समर्थन करता है।