ID में दृश्य रूप से अस्पष्ट अक्षरों को समझना और उनसे बचना

ID में दृश्य रूप से अस्पष्ट अक्षरों को समझना

• दृश्य रूप से अस्पष्ट अक्षर वे होते हैं जिन्हें किसी खास फ़ॉन्ट या हस्तलेखन में अलग-अलग पहचानना मुश्किल होता है
  • O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g आदि इसके उदाहरण हैं
• ऐसे अक्षर डेटा एंट्री के दौरान त्रुटि और भ्रम पैदा कर सकते हैं
  • जैसे उपयोगकर्ता के लिए 'O' और '0' में फर्क करना कठिन होने से गलत कोड दर्ज हो सकता है, जिससे खराब user experience होता है
• यह खास तौर पर उन स्थितियों में महत्वपूर्ण है जहाँ ID को बोलकर बताया जाता हो या हाथ से लिखना पड़ता हो
  • customer support, discount code, tracking code, error ID, product ID आदि

Case-sensitive रखना है या नहीं, यह तय करना

• यह तय करना होता है कि ID में uppercase और lowercase का फर्क रखा जाएगा या नहीं
  • case-sensitive रखने पर, दृश्य अस्पष्टता हटाने के बाद चुने जा सकने वाले अक्षर 53 हैं
  • case-sensitive न रखने पर चुने जा सकने वाले अक्षर 22 हैं
• अगर ID की लंबाई 5 अक्षर हो, तो संभव ID की संख्या:
  • case-sensitive: 53^5 = 418,195,493
  • case-insensitive: 22^5 = 5,153,632
• लेकिन ID की लंबाई बढ़ने पर संभव ID की संख्या घातीय रूप से बढ़ती है
• इसलिए ID की लंबाई और दृश्य अस्पष्टता की संभावना के बीच संतुलन खोजना चाहिए
• साथ ही, uppercase और lowercase दोनों का उपयोग करने पर ऐसे third-party systems में अप्रत्याशित समस्याएँ आ सकती हैं जो case distinction नहीं रखते

दृश्य रूप से स्पष्ट character set

• अगर readability को प्राथमिकता देनी हो, तो निम्न character set के उपयोग की सिफारिश की जाती है:
  • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

अतिरिक्त विचार

• कुछ खास character combinations दूसरे अक्षरों जैसे दिख सकते हैं (उदाहरण: rn, m जैसा और 3, w जैसा दिख सकता है)
  • ID generation चरण में ऐसे combinations से बचना बेहतर है
• जिन अक्षरों का उच्चारण मिलता-जुलता हो, उनसे भी बचना अच्छा है (उदाहरण: b और p)
  • खास तौर पर तब, जब ID को बोलकर बताया जाता हो

मौजूदा उदाहरण

• Crockford's Base32: अस्पष्ट अक्षरों को एक ही value के रूप में decode करता है, और अनजाने में बनने वाले अपशब्दों पर भी विचार करता है
• Open Location Code: 23456789CFGHJMPQRVWX character set का उपयोग करता है. इसका उद्देश्य दृश्य अस्पष्टता से बचना है, साथ ही सामान्य भाषाओं के शब्द बनने से भी रोकना है. हालांकि इसमें 6/G, 9/Q शामिल हैं

GN⁺ की राय

• ID generation में usability और readability को सर्वोच्च प्राथमिकता देनी चाहिए. खास तौर पर तब, जब ID को बोलकर साझा करना या हाथ से लिखना अक्सर ज़रूरी हो.
• ऐसा character set चुनना महत्वपूर्ण है जो दृश्य अस्पष्टता को न्यूनतम करे, लेकिन साथ ही ID की लंबाई और उपलब्ध combinations की संख्या के बीच उचित संतुलन भी बनाए.
• साथ ही, third-party systems के साथ integration करते समय अप्रत्याशित issues आ सकते हैं, इसलिए case-sensitive रखना है या नहीं, इसका निर्णय सावधानी से करना चाहिए.
• ID generation logic में कुछ खास character combinations को बाहर रखना, या मिलते-जुलते उच्चारण वाले अक्षरों से बचना जैसी अतिरिक्त सावधानियाँ भी ज़रूरी हैं.
• Crockford's Base32 या Open Location Code जैसे उदाहरणों को संदर्भ के रूप में लेकर, प्रोजेक्ट की आवश्यकताओं के अनुसार सबसे उपयुक्त character set डिज़ाइन करना बेहतर होगा.

[roxie]

यह भी अच्छा लग रहा है : https://stackoverflow.com/a/58098360/8556340

[roxie]

उच्चारण तक को ध्यान में रखा गया है, यह सचमुच अद्भुत है।

[GN⁺]

Hacker News राय

• वास्तविक कामकाजी माहौल में लाखों डिवाइसों पर अस्पष्ट अक्षरों वाले serial number इस्तेमाल करने से customer support में बड़ी मुश्किलें आईं। regex से टाइपो के variant बनाकर उन्हें DB से मिलान कर असली serial number का अनुमान लगाना एक दुःस्वप्न जैसा अनुभव था.
• यूज़र के अनुसार encoding तरीका अलग होना चाहिए। Base32 में स्पष्ट character set होता है, इसलिए यह उपयुक्त है, और मौखिक रूप से बताने के लिए word-list अभिव्यक्ति (उदाहरण: "TIDE ITCH SLOW REIN RULE MOT") का उपयोग करना अच्छा है। हालांकि, मुहावरों, homophone, बोलियों आदि के जाल मौजूद होते हैं, इसलिए अपनी word list खुद नहीं बनानी चाहिए.
• CPAN पर मज़ाक में अपलोड किए गए arbitrary radix arithmetic module (Math::Fleximal) की वजह से अप्रत्याशित support request मिले थे। कारण यह था कि किसी ने hexadecimal को alphanumeric code में बदलने वाले demo code को production में इस्तेमाल कर लिया था.
• Nintendo Switch के DLC serial number input screen में अस्पष्ट अक्षरों वाली keys को disable करके UX बेहतर किया गया है.
• cursive में लिखते समय अलग पहचानना मुश्किल हो ऐसे अक्षरों से भी बचना चाहिए। खासकर '7' और '1' आसानी से भ्रमित कर सकते हैं.
• अगर uppercase और lowercase दोनों का उपयोग करें, तो बाद में case-insensitive system या protocol की वजह से अप्रत्याशित समस्या हो सकती है। कुछ commercial system यूज़र सुविधा के नाम पर इसे bug मानने से भी इनकार करते हैं.
• हर बार जब 2FA backup code कागज़ पर लिखता हूँ, तो कुछ खास अक्षरों (o/0, v/u, 5/S आदि) को लेकर बेचैनी होने लगती है। इससे बचने के लिए मैं अक्षरों में अतिरिक्त निशान जोड़ देता हूँ.
• Wi‑Fi password के लिए ऐसा रोज़मर्रा का शब्द चुना गया ("vacation") जिसे तीसरी कक्षा का बच्चा भी सही spelling के साथ लिख सके.
• KeepassXC uppercase, lowercase, number, symbol आदि जैसे character type के हिसाब से अलग-अलग रंग देकर readability को काफी बढ़ाता है.
• Bitcoin address modified Base58 encoding का उपयोग करते हैं.
• लेख में Arial font को गलती से Ariel लिखा गया है.