ID में दिखने में मिलते-जुलते अक्षरों से बचना

• bug report, discount code entry, shipment tracking जैसी स्थितियों में, जहां लोग ID पढ़ते और आगे बताते हैं, O/0, I/l/1/7 जैसी visual ambiguity आसानी से input errors में बदल जाती है
• भ्रम font और handwriting के हिसाब से बढ़ता है, और 5/S, 2/Z, 8/B, 6/G, 9/q/g जैसे ऐसे combinations जिनमें फर्क धुंधला हो जाता है बार-बार दिखते हैं
• customer support, error ID, product ID जैसे IDs जिन्हें लोग सीधे handle करते हैं, उनमें बिना सोचे-समझे बड़ा character set चुनने से ज्यादा, पढ़ने में आसान character set चुनना real-world quality के लिए ज्यादा अहम है
• case-sensitive होने पर 5-character ID में 418,195,493 combinations बनाए जा सकते हैं, लेकिन case-insensitive होने पर यह घटकर 5,153,632 रह जाता है, इसलिए length और safety के बीच trade-off जरूरी है
• case-sensitive IDs को छोटा बनाना आसान होता है, लेकिन कुछ third-party systems या protocols case-insensitive तरीके से काम कर सकते हैं, जिससे integration stage में समस्या हो सकती है

---

इंसानों द्वारा पढ़े जाने वाले IDs में अक्षरों का भ्रम

• जब ID को bug report, discount code entry, shipment tracking जैसी system interactions में लिखा या बताया जाता है, तो टाले जा सकने वाले character confusion user experience को खराब कर सकते हैं
• प्रमुख दिखने में ambiguous characters के combinations ये हैं
  • O / 0: बिना slash या dot वाले 0 में अक्षर O और अंक 0 मिलते-जुलते दिख सकते हैं
  • I / l / 1 / 7: uppercase I, lowercase l, अंक 1, अंक 7 कई printed materials और handwriting में अलग पहचानना मुश्किल होता है
  • 5 / S, 2 / Z, 8 / B, 6 / G, 9 / q / g: कुछ fonts, stylized fonts और handwriting में भ्रम पैदा कर सकते हैं
• example string 9qg6G8B2Z5SIl170O को Arial, Helvetica, Courier, Times, Verdana, Georgia, Tahoma, Impact, Comic Sans जैसे कई system fonts में comparison target के तौर पर इस्तेमाल किया गया
• I और l जैसे कुछ combinations कई fonts में लगातार ambiguous दिख सकते हैं, और 9qg जैसे combinations हाथ से लिखने पर और भी ज्यादा भ्रमित कर सकते हैं

• • वे ID types जिनमें समस्या खास तौर पर बढ़ जाती है

  • customer support में आदान-प्रदान होने वाले discount codes
  • shipping या logistics में इस्तेमाल होने वाले tracking codes
  • issue reproduction और inquiry handling के लिए जरूरी error IDs
  • product identification में इस्तेमाल होने वाले product IDs

case sensitivity और character set का trade-off

• ID abc और ABC को समान value मानेगा या नहीं, यह generation rules तय करते समय साथ में निर्धारित करना चाहिए
• case-sensitive रखते हुए visually ambiguous characters हटाने पर उपलब्ध characters 53 होते हैं
• case-insensitive रखने पर उपलब्ध characters घटकर 22 रह जाते हैं
• ID length के हिसाब से संभावित combinations की संख्या इस प्रकार है
  • 5 characters, case-sensitive: 53^5 = 418,195,493
  • 5 characters, case-insensitive: 22^5 = 5,153,632
  • 8 characters, case-sensitive: 53^8 = 62,259,690,411,361
  • 8 characters, case-insensitive: 22^8 = 54,875,873,536
• आखिरकार विकल्प छोटे लेकिन ज्यादा confusion-prone IDs और लंबे लेकिन पढ़ने में आसान IDs के बीच संतुलन का है
• अगर uppercase और lowercase दोनों का इस्तेमाल करते हैं, तो कभी न कभी किसी case-insensitive third-party system या protocol में unexpected behavior मिल सकता है
  • एक commercial system ने users को iD और id को अलग-अलग IDs के रूप में चुनने दिया, लेकिन non-existent ID lookup के समय case-insensitive matching करके गलत data return कर दिया
  • उस bug पर जवाब मिला कि यह “convenience” के लिए behavior है

सिर्फ एक character नहीं, combinations से भी बचना पड़ सकता है

• कभी-कभी character combination खुद किसी दूसरे character जैसा दिख सकता है
  • rn m जैसा दिख सकता है
  • vv w जैसा दिख सकता है
• केवल इसी वजह से बड़ी संख्या में characters हटाने पर उपलब्ध character set बहुत छोटा हो सकता है, इसलिए generation stage में केवल खास combinations से बचना ज्यादा practical हो सकता है
• बोलकर बताने की स्थितियों में phonetic similarity को भी साथ में consider किया जा सकता है
  • उदाहरण के लिए, b और p बोलने पर मिलते-जुलते सुनाई दे सकते हैं

#参考 के लिए मौजूदा तरीके

• Crockford का Base32 ambiguous characters को same value के रूप में decode करता है, और accidental obscene expressions की समस्या पर भी विचार करता है
• Open Location Code 23456789CFGHJMPQRVWX character set का इस्तेमाल करता है
  • यह character set visually ambiguous characters से बचने और सामान्य भाषा के शब्दों की spelling से भी बचने के लिए चुना गया है
  • हालांकि इसमें 6 और G, 9 और Q दोनों शामिल हैं

[roxie]

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

[roxie]

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

[GN⁺]

Hacker News की राय

• काम पर हमने लाखों डिवाइस पर serial number लगाकर शिप किया था, लेकिन भ्रमित करने वाले अक्षर या अंक बिल्कुल भी नहीं हटाए गए थे, इसलिए ग्राहकों को उन्हें सही पढ़ने में बहुत दिक्कत हुई
  ग्राहक द्वारा बताए गए मान के आधार पर हर संभव typo संयोजन बनाकर फ़ैक्टरी डेटाबेस से मिलान करने वाला regex script बनाना पड़ा, और फिर तारीख जैसी दूसरी जानकारी से मिलाकर असली serial number का अनुमान लगाना पड़ा
  और भी विडंबना यह थी कि कुछ digit कभी बदलते ही नहीं थे, और कुछ स्थानों पर फ़ैक्टरी पहचान के लिए सिर्फ 0, 1, 2 ही चाहिए थे, इसलिए शुरुआत से ही पूरे character set की ज़रूरत नहीं थी. मानो उन्हें लगा हो कि वे 8 खरब यूनिट बना देंगे

  • कई बार serial number से business information लीक होने को रोकना उपयोगी होता है, या कम से कम उपयोगी माना जाता है
    उदाहरण के लिए, अगर किसी product पर 1, 2, 3 जैसे क्रमिक नंबर लगाए जाएँ, तो बहुत छोटे sample से भी कुल sales का काफ़ी आसान अंदाज़ा लगाया जा सकता है. वैध serial number का अनुमान लगाना कठिन बनाकर refund abuse जैसी चीज़ें रोकने में भी मदद मिल सकती है
    बेशक, ऐसी चिंताएँ हों तब भी पढ़ने में कठिन अक्षरों से बचने के उपाय साथ में किए जा सकते हैं, और अगर इसका मतलब यह है कि कोई नंबरिंग scheme पर सोच रहा था, तो उसे इस समस्या का बेहतर अंदाज़ा होना चाहिए था. असलियत में ज़्यादा संभावना यही लगती है कि किसी ने 30 सेकंड सोचा और कहा, “इतने digit रखेंगे तो कभी ख़त्म नहीं होंगे, बस”
  • अब सोचता हूँ कि Apple serial numbers में vowel न होने की वजह भी यही हो सकती है, या कम से कम एक कारण तो हो ही सकती है
    लगता है डिवाइस serial number में सिर्फ consonant और digit ही इस्तेमाल होते हैं

• encoding को user के हिसाब से बदलना चाहिए. Base32, खासकर Crockford और RFC 4648, छोटा रखने के लिए अच्छे हैं और इनमें non-ambiguous alphabet व उसके कारण भी ठीक से मौजूद हैं
  लेकिन अगर user को उसे बोलकर बताना हो, तो s/key RFC 1751 की तरह “TIDE ITCH SLOW REIN RULE MOT” जैसी word list representation बेहतर हो सकती है
  word list खुद नहीं बनानी चाहिए. idiom, homophone, dialect जैसी छिपी हुई मुश्किलें ख़त्म ही नहीं होतीं. “wet clam butterfly” जैसे बड़े हादसे अनजाने में नहीं बनाने चाहिए

  • दुर्भाग्य से, वह उदाहरण “TIED HITCH SLOE REIGN RULE MOW” की तरह भी सुनाई दे सकता है. सिर्फ 2 parity bit होने से यह भी पक्का नहीं कहा जा सकता कि यह decoding ग़लत है
    यह उदाहरण जिस RFC 1751 [0] में है, वह मौखिक संप्रेषण के लिए encoding की कल्पना नहीं करता, बल्कि user को ज़्यादा आसानी से “पढ़ने, याद रखने और दर्ज करने” देने के लिए है
    अगर विशेषज्ञ आपस में मौखिक रूप से बात कर रहे हों, तो सिर्फ 26 uppercase अक्षरों का उपयोग करना और NATO phonetic alphabet पर निर्भर रहना एक उचित विकल्प है. लेकिन बिना प्रशिक्षित user से शोरगुल वाले मौखिक माहौल में code सही-सही लेना अब भी अनसुलझी समस्या है
    [0] https://datatracker.ietf.org/doc/html/rfc1751
  • यह 1994 का है, इसलिए कुछ छूट दी जा सकती है, लेकिन फिर भी यह काफ़ी हास्यास्पद रूप से खराब RFC है
    “keyed message digest algorithm MD5 का उपयोग करना चाहिए, और यह पर्याप्त रूप से मज़बूत है” जैसी पंक्ति से ही हँसी आती है
    “ज़्यादातर लोगों के लिए पढ़ना, याद रखना और दर्ज करना कठिन है” तक तो ठीक था, लेकिन फिर बात “English words लोगों के लिए याद रखना और दर्ज करना कहीं आसान है” तक पहुँच जाती है. समस्या यह है कि ज़्यादातर लोग English नहीं जानते, तो लगा कि शायद word list बदल देंगे, लेकिन वहाँ लिखा है कि “interoperability के कारण भाषा-विशेष dictionary अलग रखना वांछनीय नहीं है”
    आख़िर में तर्क यह बनता है कि दुनिया भर के लोगों ने English alphabet के 26 अक्षर तो सीख ही लिए हैं, तो कुछ शब्द और जोड़ देने में क्या हर्ज है, लेकिन char Wp[2048][4] = […] में शुरुआती लोगों के लिए उपयुक्त सामान्य शब्द नहीं, बल्कि “WAD, BESS, MERT…” जैसी चीज़ें भरी हैं. यहाँ तक कि “ORR? AGEE EGAN HAAS!!”, “GAUL FLAM! DRAB!” भी आता है
  • जिज्ञासा है कि इस तरह के ID को क्या कहा जाता है

• यह पढ़कर मुझे पुरानी बात याद आ गई. एक बार बीमार होने पर तकलीफ़ से ध्यान हटाने के लिए मैंने arbitrary base arithmetic करने वाला एक खिलौना मॉड्यूल बनाया था, और क्योंकि यह आसान था, उसे CPAN पर डाल दिया
  वह मॉड्यूल https://metacpan.org/pod/Math::Fleximal है
  मैंने सोचा था कि मेरी बनाई छोटी-मोटी चीज़ों में यह वह आख़िरी चीज़ होगी जिस पर कभी support request आएगी, लेकिन सच में आई. वजह यह थी कि मैंने hex को alphanumeric code में बदलने का एक उदाहरण दिया था, और किसी को यह शानदार विचार आ गया कि लंबे नंबर को पढ़ने में आसान code में बदलने के लिए इसे वैसे ही इस्तेमाल कर लिया जाए
  मॉड्यूल ठीक से काम करता था, लेकिन यह जानना काफ़ी अजीब था कि यह कहीं production में चला गया है

• लेख में ज़ोर दिया गया है कि ऐसे अक्षरों से बचना चाहिए जिन्हें handwriting में भी अलग पहचानना मुश्किल हो, लेकिन उदाहरण तालिका में अंक 7 शामिल है. मैंने अनगिनत बार ऐसी स्थिति देखी है जहाँ किसी का 7 और 1 अलग करना मुश्किल था
  7 पर horizontal stroke बना देने से मदद मिलती है, लेकिन बहुत से लोग ऐसा नहीं लिखते, इसलिए कभी-कभी यह पक्का कहना मुश्किल होता है कि वह 7 है या serif वाला 1

  • लेख में आवाज़ से अलग पहचानना कठिन “B”(Bravo) और “P”(Papa) का ज़िक्र था, लेकिन उससे भी ज़्यादा मिलते-जुलते “F”(Foxtrot) और “S”(Sierra) छूट गए
    कभी-कभी दोनों लगभग अलग ही नहीं किए जा सकते. NATO/aviation standard alphabet (Alpha, Bravo, Charlie, Delta...) इस्तेमाल किया जा सकता है, लेकिन जब तक target audience बहुत सख़्ती से सीमित न हो, इससे बहुत फ़ायदा नहीं होता. ऐसे संयोजन से बचना ही बेहतर है
    चाहे ID string थोड़ी लंबी हो जाए, अक्षरों को पढ़ने, बोलने और सुनने की क्षमता को अधिकतम करना कहीं बेहतर है, और इससे समय व झुंझलाहट दोनों बहुत बचते हैं
  • मैंने कभी ऐसा handwriting style नहीं देखा जिसमें 1, 7 जैसा लगे. आम तौर पर I या l का 1 से भ्रम होता है
    जिज्ञासा है कि किस तरह की handwriting में 1, 7 के समान दिखता है. 7 की ऊपर की क्षैतिज रेखा ही उसे काफ़ी अलग कर देनी चाहिए
  • ऊपर के हिस्से में यह छूटा हुआ था, लेकिन “visually ambiguous dictionary” सेक्शन में 1 और 7 दोनों शामिल नहीं हैं

• अगर uppercase और lowercase दोनों का उपयोग किया जाए, तो कभी न कभी किसी case-insensitive third-party system या protocol से टकराने की संभावना बहुत अधिक होती है
  मैंने वास्तव में एक commercial system देखा है जो user को case-sensitive ID चुनने देता था, इसलिए iD और id अलग मान्य थे, लेकिन जब किसी non-existent ID को lookup किया जाता था, तो वह case-insensitive matching करके पूरी तरह ग़लत data लौटा देता था
  जब यह bug report किया गया, तो जवाब मिला कि यह “सुविधा के लिए feature” है

• Nintendo Switch पर DLC serial number दर्ज करते समय ambiguous character keys on-screen keyboard पर disabled थीं, जो काफ़ी अच्छा user experience लगा।
  इसका मतलब है कि serial number शुरू से ही ambiguous characters के बिना generate किए जाते हैं। यह UX operating system में built-in था या सिर्फ़ उस game Mario + Rabbids Sparks of Hope में था जिसे मैं खेल रहा था, यह पक्का नहीं है।

• open source password manager KeepassXC password को अधिक readable बनाने के लिए colors का उपयोग करता है। uppercase, lowercase, numbers, symbols जैसी हर character category के लिए अलग color इस्तेमाल होता है।
  विचार बहुत simple है, लेकिन खासकर random passwords में, भले ही पहले से high-readability font इस्तेमाल हो, फिर भी यह बहुत मदद करता है।

  • Bitwarden भी non-ambiguous font और तीन colors का उपयोग करता है। characters default color में, numbers blue में, और symbols red में होते हैं, जो वास्तव में बहुत अच्छा है।
    यह समझना मुश्किल है कि password-focused software बिना किसी color distinction के ambiguous font में characters render करने की अनुमति दे।
  • KeepassXC password generator में exclude character list भी आसानी से जोड़ी जा सकती है।
    TV remote जैसी interface से लंबा password टाइप करते हुए जब यह एहसास हो कि l1|I गड़बड़ा गया है, वह क्षण इतना झुंझलाहट भरा होता है कि मैंने इन्हें सीधे exclude कर रखा है।
  • color vision deficiency वाले व्यक्ति के नज़रिए से यह विचार पसंद नहीं है।

• यह पढ़ना अच्छा लगा क्योंकि यह रोज़मर्रा में अक्सर आने वाली समस्या पर बात करता है।
  हर बार जब कागज़ पर 2-step authentication backup codes लिखता हूँ, तो o/0, v/u, 5/S जैसे characters पर पहुँचते ही बेचैनी होती है। इसलिए मैं जानबूझकर इन्हें थोड़ा अलग ढंग से लिखता हूँ ताकि अलग दिखें।
  “phonetic similarity” वाला हिस्सा देखकर Wi‑Fi password चुनने का समय याद आ गया। मैं ऐसा सामान्य शब्द चाहता था जिसे एक वाक्य में बोलकर साझा किया जा सके, जो ambiguous न हो, जिसे तीसरी कक्षा का बच्चा भी spell कर सके, और जिसमें कई consonants हों, और अंत में मैंने “vacation” चुना।

  • मेरा नियम है कि हर digit के नीचे एक dot लगाता हूँ। इससे 5/S, 0/O, 8/B जैसी समस्याएँ हल हो जाती हैं। वास्तव में कौन-सी जोड़ियाँ समस्या बनती हैं, यह हर व्यक्ति की handwriting पर निर्भर करता है।
    अगर फिर भी पूरा भरोसा न हो तो NATO/aviation alphabet [1] भी जोड़ देता हूँ। उदाहरण के लिए अगर U हो, तो U से शुरू करके तिरछे Uniform लिख देता हूँ।
    बस थोड़ी discipline चाहिए। मैं 10 साल से ज़्यादा समय से ऐसा कर रहा हूँ और कभी भी 2-step authentication code नहीं खोया।
    [1] NATO और aviation code के वास्तविक अंतर पर की जाने वाली nitpicking को निश्चिंत होकर /dev/null में भेजा जा सकता है।
  • यह विश्वास करना मुश्किल है कि कोई ऐसी चीज़ हाथ से कागज़ पर लिखता है।
    दिमाग ही bottleneck है।

• ऐसी चर्चाएँ अच्छी लगती हैं। यह शायद cutting-edge या रोमांचक विषय न हो, लेकिन इंसानों और मशीनों दोनों की ज़िंदगी आसान बनाने में इसका काफ़ी अर्थ और ताकत है।
  यह best practices का वह क्षेत्र भी है जहाँ काम सही होने पर अक्सर किसी का ध्यान ही नहीं जाता। details पर ईमानदार ध्यान और sincerity का “यही तो होना चाहिए” मानकर खास प्रशंसा न मिलना थोड़ा अफ़सोसजनक है।

• लेख की गलती की बात करें तो, 9qg6G8B2Z5SIl170O (ariel) में font का नाम Ariel नहीं बल्कि Arial है। The Little Mermaid यहाँ नहीं है।

  • सही। और उस हिस्से में screenshot या web font इस्तेमाल करना बेहतर होता।
    Linux पर ज़्यादातर lines एक जैसी दिखती हैं।
  • लेख open source है, इसलिए correction में योगदान दिया जा सकता है।
    https://github.com/gajus/gajus-com/blob/main/src/blogPosts/2...
    typo पहले ही ठीक कर दिया गया है।