1 पॉइंट द्वारा GN⁺ 2025-09-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फ़ोटो फ़ाइलों को alphabetical order में sort करने की कोशिश की गई, लेकिन operating system और file manager के sorting results अलग निकले
  • Linux ls में sorting सही होती है, लेकिन Windows, Google Drive, KDE Dolphin जैसे ज़्यादातर GUI file managers नंबर वाली filenames को संख्यात्मक रूप से समझने वाला “natural sort” लागू करते हैं
  • इसकी वजह से file-10.txt file-9.txt के बाद आने के बजाय अलग तरह से दिख सकता है, यानी पारंपरिक string sorting से अलग परिणाम मिलता है
  • असली समस्या यह थी कि दोनों फ़ोनों में filename rules अलग थे: एक में seconds के बाद milliseconds सीधे जुड़े थे, जबकि दूसरे में underscore से अलग किया गया था, इसलिए sorting का आधार बदल गया
  • आखिरकार समाधान सिर्फ यही है कि filename convention एक जैसा किया जाए या हर file manager की hidden settings बदली जाएँ; लेखक को इस बात का अफ़सोस है कि “अब कंप्यूटर उपयोगकर्ता के निर्देश से पहले अनुमान लगाने लगे हैं”

पृष्ठभूमि और समस्या की स्थिति

  • लेखक अपने पिता के साथ hiking पर गया, दोनों ने अपने-अपने Android फ़ोन से तस्वीरें लीं, और बाद में सभी तस्वीरें एक ही फ़ोल्डर में रखीं
  • फ़ोटो filenames का pattern IMG_YYYYMMDD_HHmmss था, या उसके बाद अतिरिक्त अंक और .jpg जुड़ा होता था
  • क्योंकि इन filenames में साल-महीना-तारीख और समय का क्रम था, लेखक ने सोचा कि फ़ाइलों को alphabetical order में sort करने पर वे shooting time के क्रम में आ जाएँगी
  • लेकिन Windows PC, Google Drive, KDE Dolphin आदि में एक ही नियम वाली फ़ाइलें भी सही क्रम में sort नहीं हो रही थीं
    • उदाहरण: पिता के फ़ोन से ली गई 5:54 वाली फ़ोटो 9:20 वाली फ़ोटो से पहले दिख रही थी, और 12:11 वाली फ़ोटो के बाद कहीं आ रही थी
  • Gnome और स्मार्टफ़ोन के अन्य file managers में भी नतीजा यही था
  • Linux ls command में सही क्रम बना रहा, जिससे भ्रम और बढ़ गया

कारण का विश्लेषण

  • शुरुआत में लेखक को लगा कि शायद दोनों फ़ोनों में से किसी एक ने underscore (_) की जगह कोई अजीब character इस्तेमाल किया होगा, लेकिन Linux ls से जाँच करने पर sorting सामान्य मिली
  • अलग-अलग Linux distributions और OpenBSD server पर भी ls सही alphabetical sorting दिखाता रहा
  • इसके उलट, कई GUI file managers (Windows, Google Drive, KDE Dolphin आदि) filename में नंबर होने पर उन्हें असली संख्या के आकार के रूप में compare करते हैं
    • यानी alphabetical order की जगह natural sorting को default बना दिया जाता है
  • Natural sort string के भीतर के अंकों को साधारण characters नहीं बल्कि संख्यात्मक मान की तरह compare करता है
    • उदाहरण: file-9.txt < file-10.txt → इंसानों को अपेक्षित लगने वाला क्रम
    • लेकिन पारंपरिक sorting में 1 < 9 होने से file-10.txt पहले आ जाता है
  • मगर आजकल के file managers में अगर कोई “number part” हो, तो उस हिस्से को संख्या का वास्तविक मान मानकर 9 को 10 से पहले लाने के लिए ज़बरदस्ती sort किया जाता है
    • इससे filename बनाने वाले उपयोगकर्ता की मूल मंशा से अलग क्रम बन सकता है

असली कारण और समाधान

  • लेखक के पिता के फ़ोन में milliseconds के अंक seconds के बाद सीधे जुड़ते थे, जबकि लेखक के अपने फ़ोन में underscore से अलग करके लिखे जाते थे
    • पिता का फ़ोन: seconds के बाद सीधे milliseconds जोड़ता था → संख्या बड़ी बन जाती थी और पीछे चली जाती थी
    • लेखक का फ़ोन: underscore से अलग करता था → उसे अलग string part की तरह माना जाता था
  • समाधान: दोनों में से किसी एक तरफ़ के filenames को एक समान pattern में फिर से व्यवस्थित कर दिया जाए, तो समस्या हल हो जाती है
  • KDE Dolphin में options के भीतर pure alphabetical sorting चुनी जा सकती है, लेकिन यह setting छिपी हुई है, इसलिए झंझट बढ़ता है
  • अलग-अलग programs में यह सुविधा अलग हो सकती है, इसलिए हर बार अलग setting करनी पड़ सकती है

लेखक का निष्कर्ष

  • “alphabetical order” चुनने के बावजूद, software उपयोगकर्ता की मंशा का अनुमान लगाकर दूसरी sorting लागू कर दे, इस बात की लेखक ने आलोचना की
  • लेखक को पुराने समय की वह सरल शैली याद आती है, जब कंप्यूटर वही करता था जो उसे स्पष्ट रूप से कहा जाता था

1 टिप्पणियां

 
GN⁺ 2025-09-29
Hacker News राय
  • मुझे लगता है कि Microsoft, Google और KDE द्वारा अपनाया गया sorting तरीका ज़्यादा intuitive है और ज़्यादा आम use cases को cover करता है; लेखक की स्थिति बेहद दुर्लभ लगती है। ज़्यादातर लोग चाहते हैं कि “10”, “9” के बाद आए। Desktop environments भी sorting को “alphabetical” नहीं बल्कि “name” के आधार पर बताते हैं, इसलिए गलतफ़हमी नहीं होनी चाहिए। मुझे यह पसंद नहीं कि कंप्यूटर हमारी मंशा पढ़ने की कोशिश करे, लेकिन autosave जैसी चीज़ों की तरह यह असल ज़िंदगी में उपयोगी भी है। सख्त alphabetical sorting का विकल्प होना अच्छा होगा, लेकिन default के रूप में आम मामलों के लिए intuitive व्यवहार सही है।

    • मैं भी इतना समझदार हूँ कि जानता हूँ कि alphabetical order में “10”, “9” से पहले आता है, लेकिन file manager में मैं चाहता हूँ कि “9” के बाद “10” आए। Single-digit नंबरों के आगे 0 लगाना भी पसंद नहीं, और अगर बाद में तीन अंकों की ज़रूरत पड़े तो फिर से rename करना झंझट है। Audiobook files को chapter के हिसाब से बाँटते समय, और यह ध्यान रखते हुए कि हर player सही तरह sort नहीं करेगा, मैं “Chapter 01.mp3” या “Chapter 001.mp3” जैसा format इस्तेमाल करता हूँ। इसके लिए automation script भी बनाई है, फिर भी यह देखने में अच्छा नहीं लगता और बेवजह का काम है। अगर हर device नंबरों को ठीक से समझे तो बहुत बेहतर होगा।
    • मैं सहमत नहीं हूँ। अगर अंकों को text में लिखने का कोई एकमात्र और सार्वभौमिक तरीका होता, तो बात समझ में आती। लेकिन number input के कई रूप होते हैं, इसलिए “मंशा पढ़ने” वाला feature कुछ ही मामलों में ठीक से काम करता है। Decimal points, thousand separators, scientific notation जैसी चीज़ें जटिल exceptions हैं, और requirements को ध्यान से देखें तो पता चलता है कि इसे भरोसेमंद तरीके से implement करना मुश्किल है।
    • यह दावा कि लोगों को पहले से 0 लगाना स्वाभाविक और परिचित लगता है, मुझे व्यावहारिक नहीं लगता। उदाहरण के लिए version 5.9.17 से 5.10.0 पर जाने पर कोई पुराने folder names को 5.09.17 करके नहीं बदलता। आज का standard sorting तरीका अस्पष्ट नहीं बल्कि intuitive है, जबकि सख्त character-by-character sorting user interface के लिए उपयुक्त नहीं है।
    • समस्या यह है कि यह बदलाव पुराने “मूर्ख” alphabetical sorting से अलग है, इसलिए लोगों को चौंकाता और भ्रमित करता है। बेहतर होता कि बहुसंख्यक लोगों के लिए “smart” तरीका और “strict alphabetical” तरीका अलग-अलग options के रूप में दिए जाते। अगर options साफ़ और सरल हों, तो non-expert users का अनुभव भी उलझन भरा नहीं होगा।
    • आपने कहा कि ज़्यादा आम स्थिति वह है जहाँ “10”, “9” से पहले आए, लेकिन शायद आपका मतलब इसका उल्टा था। और जानकारी के लिए, “name” sorting का औपचारिक नाम “Natural sort order” है।
  • यह विषय “Worse is better” बहस की याद दिलाता है। लेखक जिस ANSI/Unicode-आधारित simple sorting की माँग कर रहा है, वह असल में केवल कुछ developers के काम की चीज़ है। वास्तव में 99% GUI users intuitive sorting चाहते हैं। Primary users कौन हैं, यह समझना product design को बहुत प्रभावित करता है। बेहतर feature किसी product के लिए सही हो सकता है, लेकिन किसी system के लिए growth और evolution के लिहाज़ से simplicity ज़्यादा उपयुक्त हो सकती है।

    • Developer के दिमाग में mixed numbers वाले names को शुद्ध naive तरीके से संभालने का मॉडल है, जबकि आम users के लिए 10 का 9 के बाद आना स्वाभाविक है। Developers की सोच सब पर थोपना ठीक नहीं।
    • जो लोग कहते हैं कि “worse” तरीका चाहिए, उनसे यह भी पूछना चाहिए कि case-sensitive sorting के बारे में उनकी क्या राय है। क्या सचमुच ASCII/Unicode codepoint order का पालन करना चाहिए, या characters को normalize करके uppercase/lowercase को साथ रखना चाहिए?
    • “target user base” का बहाना बनाकर option न जोड़ना मनाने वाला तर्क नहीं है। दोनों तरीके देना कोई मुश्किल काम नहीं है। Advanced mode में ही सही, अलग-अलग ज़रूरतों को समायोजित करने वाला software ही सच में बेहतर software है। 80/20 rule की तरह, कुछ ही लोग इस्तेमाल करें तब भी कुछ features ज़रूरी होते हैं। यह देखकर थकान होती है कि “perfect user vision” के नाम पर साफ़-साफ़ ज़रूरी features भी छोड़ दिए जाते हैं।
  • Hash value से नाम वाली files ढूँढते समय automatic sorting सबसे ज़्यादा परेशान करती है। Windows में यह उन कुछ options में से है जिन्हें मैं registry से तुरंत बंद कर देता हूँ। कई बार पुराने दिन याद आते हैं जब कंप्यूटर वही करता था जो उससे कहा जाता था। आजकल ऐसा लगता है कि वह “user की मंशा पढ़ने” के बजाय “user की सोच बदलने” की कोशिश कर रहा है, और यह बात खटकती है। Open source सहित, “user ग़लत है” वाली हठी मानसिकता से भी असंतोष है।

    • यह समस्या केवल simple hash तक सीमित नहीं है; कई identifiers में बीच-बीच में बिना अर्थ वाले numbers होने पर और भी भ्रम पैदा होता है। User IDs, Unix timestamps जैसी number chunks वाली files ढूँढते समय, abcd89764237 और abcd683426834 जैसी चीज़ें नज़र में अजीब जगह पर दिखती हैं, और काफ़ी देर बाद समझ आता है कि ऐसा क्यों है।
  • अगर सब लोग दावा करते हैं कि उन्हें average user की needs पता हैं, तो फिर कोई यह क्यों नहीं कहता कि कंप्यूटर file names को ही अपनी मर्ज़ी से बदल दे? अगर ASCII sorting लागू नहीं करनी, तो extension सहित file names से चिपके रहने की भी ज़रूरत नहीं है। असल में users को jpg, png extensions से फ़र्क नहीं पड़ता, और case distinction की भी परवाह नहीं होती। Windows परिवार में extensions का उपयोग अक्सर पुरानी compatibility की वजह से रहा है। “कंप्यूटर-जैसे file names” थोपते रहना लेकिन “कंप्यूटर-जैसी sorting” को ही तोड़ देना अजीब लगता है। Users क्या चाहते हैं, यह हमें नहीं पता, इसलिए दावे से निष्कर्ष नहीं निकालना चाहिए।

  • मुझे ज़्यादातर मामलों में लेख में बताई गई version-based sorting बेहतर लगती है। Alphabetical sorting में दिखाना तो bug जैसा महसूस होता है। मेरे हिसाब से समस्या sorting की अवधारणा में नहीं, labeling में है।

    • असल में इसे “alphabetical” कहकर समझाया ही नहीं जाता; लेखक ने “name” sorting को “alphabetical” समझ लिया।
    • बताया गया व्यवहार उपयोगी है, लेकिन user को पहले से बताना या option चुनने देना ही सही तरीका है।
    • Linux का sort command भी अब version sorting (sort -V) support करता है। अंदर कैसे काम करता है, यह नहीं जानता, लेकिन ज़्यादातर स्थितियों में ठीक चलता है। सबसे अहम बात, इसे आसानी से on/off किया जा सकता है।
    • लेख में जिस sorting का ज़िक्र है वह “lexical” है, लेकिन आम लोग “lexical” और “alphabetic” का अंतर नहीं जानते।
  • यहाँ files को “alphabetical” क्रम में sort करने का आदेश नहीं, बल्कि “name” के आधार पर sort करने की बात है, इसलिए इसकी व्याख्या हर OS में अलग हो सकती है। मुझे लगता है कि ज़्यादातर users के लिए जो interpretation बेहतर है, वही logic और data के आधार पर चुनी गई है। शायद भविष्य में ऐसे नियम जुड़ें कि अगर number group में 0 हो तो मूल alphabetical order अपनाया जाए, या user-selection option आ जाए।

    • अगर किसी number के आगे 0 हो, तो उसे octal मानकर केवल तब काम करे जब आगे के digits 0~7 हों—यह intuitive लग सकता है।
    • लेकिन ऐसी interpretation में बदलाव 10~20 साल पहले से आया है; पहले file managers में “name” sorting का मतलब ही “alphabetical/dictionary” sorting होता था।
  • macOS Foundation में Finder sorting के लिए इस्तेमाल होने वाला NSString.localizedStandardCompare() आधिकारिक रूप से दिया गया है। Windows भी StrCompareLogical देता है। यानी name sorting, यानी natural sorting, को platforms आधिकारिक रूप से standardize कर रहे हैं।

    • मुझे यह दिलचस्प लगा क्योंकि मैंने सोचा था कि यह ls command से अलग होगा, और अब मुझे भी यह तरीका बेहतर लगने लगा है। Photo apps आमतौर पर timestamp के आधार पर sort करती हैं, और अगर किसी file को सच में name order में sort करना हो, तो मैं या तो creation date से sort करूँगा या file names को खुद normalize करूँगा।
  • Unicode report साफ़ तौर पर कहती है कि भाषा और context के अनुसार sorting तरीका बदल सकता है। उदाहरण के लिए, अगर “A-10” को numbers पहचाने बिना alphabetical order में sort करें, तो “A-10”, “A-2” से पहले आएगा। बात जटिल है, लेकिन इसी वजह से file browsers ने natural sorting अपनाई, यह मुझे सही लगता है।

    • लेकिन फिर सवाल उठता है कि -10 तो -2 से छोटा है, तो क्या क्रम उल्टा नहीं होना चाहिए?
  • “foo9” को “foo10” से पहले लाने वाला sorting तरीका ही “natural sort” है। हाल ही में Python की 2-line code से natural sorting करना सीखा और बहुत संतोष हुआ। संबंधित Stack Overflow code सुझाता हूँ।

    • sort(1) command भी natural sorting (-V) support करता है। Image files बनाकर ls | sort -V चलाएँ तो सही काम करता है। du -sh * के output को भी sort -h option से sort किया जा सकता है।
  • “Image-1.jpg, Image-11.jpg, Image-2.jpg” जैसी मिली-जुली sorting की कमी महसूस नहीं होती। एक समय natural sorting अजीब लगी थी, लेकिन Windows में numbers के हिसाब से sorting होने लगी तो सच में बहुत सुविधा हुई। Files काफ़ी स्वाभाविक क्रम में दिखने लगीं और मैं काफ़ी संतुष्ट था।

    • लेकिन कुछ लोगों के लिए यही क्रम अपेक्षित हो सकता है, इसलिए आखिरकार यह व्यक्ति पर निर्भर करता है।