ü/ü की पहेली
Unicode में visually identical characters को encode करने के कई तरीके — जैसे ü को एक single code point के रूप में या “u” plus a combining diaeresis के रूप में — search, file handling, और identity data में subtle bugs पैदा करते हैं। टिप्पणीकार normalization (NFC/NFD), collation, और “confusables” पर चर्चा करते हैं, और बताते हैं कि operating systems, filesystems, और programming languages इन्हें अलग-अलग तरह से कैसे संभालते हैं और इसका spam filtering से लेकर लोगों के legal names तक पर क्या असर पड़ता है। कई लोगों का तर्क है कि consistent normalization और locale-aware comparison आवश्यक हैं, लेकिन यह भी रेखांकित करते हैं कि ये समस्याएँ software में वास्तविक दुनिया की भाषा को represent करने की गहरी जटिलता और राजनीति को दर्शाती हैं.
नॉर्मलाइज़ेशन बनाम कोलेशन और असली बग
- कई लोग बताते हैं कि लेख की समस्या Unicode की अंतर्निहित खामी नहीं, बल्कि Unicode normalization की एकरूपता की कमी है।
- Unicode Normalization Forms (NFC/NFD) संयुक्त बनाम विघटित अक्षरों को संभालती हैं; canonical रूप से समतुल्य अनुक्रमों को एक जैसा दिखना चाहिए।
- अन्य लोग ज़ोर देते हैं कि normalization (NFC/NFD) और collation/search (Unicode Collation Algorithm, TR10) अलग समस्याएँ हैं; समानता, sorting, और search के लिए दोनों महत्वपूर्ण हैं।
Confusables, सुरक्षा, और search
- कई लोग Unicode “confusables” पर चर्चा करते हैं (दिखने में समान लेकिन अलग code points), जो spam, phishing, और abuse में काम आते हैं।
- ऐसी libraries मौजूद हैं जो strings को regexes या canonical “confusable groups” में map करती हैं ताकि ℍ℮1l೦ ≈ “Hello” जैसी चालों को पकड़ा जा सके।
- सब कुछ एक ही form में समेट देने पर skepticism भी है, क्योंकि कुछ characters वैध रूप से एक से अधिक base letter से मिलते-जुलते होते हैं।
Filesystems, macOS, और normalization की परेशानी
- macOS ऐतिहासिक रूप से filenames को NFD में normalize करता था; APFS ने विवरण बदले, लेकिन mixed normalization और tool assumptions के साथ एक उलझा हुआ ecosystem छोड़ दिया।
- इससे cross-platform bugs होते हैं (जैसे, एक जैसे दिखने वाले filenames का टकराना, diacritics का गलत स्थान पर render होना, “ß” बनाम “ss” के conflict)।
- ZFS की configurable normalization के लिए तारीफ़ की जाती है; HFS+/APFS और git interactions को concrete failure cases के रूप में उद्धृत किया जाता है।
Search behavior, diacritics, और locales
- इस पर काफ़ी असहमति है कि search को accents के साथ कैसा व्यवहार करना चाहिए:
- कुछ लोग accent-insensitive search चाहते हैं (non-native users और keyboard limitations में मदद के लिए)।
- अन्य लोग ज़ोर देते हैं कि अक्षरों को एक में मिला देना (जैसे n बनाम ñ, cono बनाम coño) अर्थ और precise search को बिगाड़ देता है।
- यह सहमति है कि systems को exact और fuzzy, दोनों modes चाहिए, अक्सर locale-aware भी, और Unicode अकेले language-specific rules (Turkish I, Swedish Å/Ä/Ö, Dutch IJ, Hungarian digraphs, आदि) नहीं सुलझाता।
नाम, passports, और वास्तविक दुनिया की झुंझलाहट
- diacritics वाले नामों (जैसे ü, ß, non-Latin scripts) के government, banking, travel, और legacy IT systems में टूट जाने की कई कहानियाँ हैं।
- workaround में नामों का ASCII-करण, दोहरी आधिकारिक spelling, या यहाँ तक कि legal name changes शामिल हैं; कुछ टिप्पणीकार इसे व्यावहारिक मानते हैं, तो कुछ इसे अस्वीकार्य।
- European regulations (जैसे GDPR की accuracy requirement) को टूटे हुए name handling को सुधारने के बाहरी दबाव के रूप में उल्लेख किया गया है।
Unicode design tradeoffs और Han unification
- एक पक्ष एक जैसे दिखने वाले characters और combining marks के लिए multiple encodings की आलोचना करता है, और चाहता है कि Unicode ने एक canonical form लागू की होती।
- दूसरे जवाब देते हैं कि:
- Unicode को legacy encodings के साथ round-trip करना और distinct scripts तथा casing behaviors का सम्मान करना चाहिए।
- “एक जैसा दिखने वाला glyph → एक ही code point” font, script, और इतिहास के पार अस्पष्ट है, और Han unification दिखाती है कि ऐसा unification पहले से ही कितना विवादास्पद है।
- कई लोग नोट करते हैं कि text का सही handling लगभग हमेशा locale (और कभी-कभी language tagging) माँगता है, केवल raw code points नहीं।