kB से MiB में बदलें

एक किलोबाइट 1,000 बाइट की होती है जब कोई मानक संस्था उसे परिभाषित करे, और 1,024 की जब कोई ऑपरेटिंग सिस्टम करे। यह पेज 1,000 से हिसाब लगाता है; 1,024 वाली इकाई किबीबाइट कहलाती है।

एक मेबीबाइट 1,024 किबीबाइट की है, यानी 1,048,576 बाइट। Linux के औज़ार और याददाश्त की संख्याएँ लगभग हमेशा यही कहती हैं, भले लिखा «MB» हो।

गुणक 0.000954 है, और इसे लगभग कोई साथ लेकर नहीं चलता। 0.00095 पर गोल करने से यह 0.39 % चूकता है — छोटे अंकों पर दिखता ही नहीं, और 1,000 kB के आसपास पूरी एक इकाई बन जाता है।

गोल करने से पहले जानने लायक़ अंक यही है: ख़ुद चूक नहीं, बल्कि वह जगह जहाँ से चूक नज़रअंदाज़ करने लायक़ नहीं रह जाती। उससे नीचे छोटा गुणक ही समझदारी है; उससे ऊपर ऊपर वाले ख़ाने का इस्तेमाल कीजिए, जो लिखने से पहले गोल नहीं करता।

एक MiB अपने नीचे वाली इकाई का 1,024 गुना होता है; एक MB 1,000 गुना। इस पेज पर यह 1048.576 kB और 1000 kB का फ़र्क़ है — 4.9 % — और हर सीढ़ी पर यह फ़ासला बढ़ता जाता है। इसीलिए एक तस्वीर पर यह गोलाई भर है और हार्ड डिस्क पर दिखने लायक़ हिस्सा।

ग़ायब जगह का पूरा रहस्य इतना ही है, और इस पेज पर वह 4.9 % का बनता है। MB के नाम पर बिकी डिस्क में ठीक उतना ही होता है जितना डिब्बे पर लिखा है — दशमलव हिसाब से एक MB यानी 1000 kB। विंडोज़ उसे 1,000 के बजाय 1,024 से बाँटता है और नाम दशमलव वाला ही रखता है, इसलिए उसका «एक MB» दरअसल 1048.576 kB का निकलता है और डिस्क का अंक उतना ही छोटा दिखने लगता है। ऐपल का मैकओएस 10.6 से इन्हें दशमलव इकाइयों में ही गिनता है, और यही वजह है कि एक ही डिस्क दो मशीनों पर दो अलग आकार की दिख सकती है। न कुछ ग़ायब हुआ है, न कोई गोलाई हुई है — वही बाइट दो नामों से गिने जा रहे हैं।

कोई फ्रंट-एंड प्रोजेक्ट दोनों परंपराएँ एक साथ रखता है और अक्सर बताता नहीं। नेटवर्क-पैनल 1,000-बाइट किलोबाइट में ट्रांसफ़र-आकार बताता है, जबकि build-औज़ार और कैश 1,024 की घातों में गिनते हैं।

दोनों के बीच बदलाव एक प्रीफ़िक्स-क़दम और दशमलव-बाइनरी सीमा दोनों पार करता है, इसलिए यह 1,048.576 से बाँटता है, हज़ार से नहीं।

जानने लायक़ अंक — 500 kB है 0.4768 MiB, 2,000 kB है 1.9073, 5,000 kB है 4.7684। 2,090 kB पर पहुँचा पेज 2 MiB की सीमा पार नहीं करता, पर सात किलोबाइट भीतर है।

उलटी दिशा में भी फ़र्क़ पड़ता है — 50 MiB पर बनी कैश 52,428.8 kB रखती है, 50,000 नहीं।

4.9 प्रतिशत पर बहस से पहले तय कीजिए कौन-सा आकार मापा जा रहा है। टेक्स्ट bundle आमतौर पर अपनी बिना-दबी लंबाई के एक-तिहाई या कम तक दबता है।

बजट को यह भी बताना चाहिए — ट्रांसफ़र किया गया, दबा हुआ, या डिस्क पर कच्चा। जो नहीं बताया गया, उसे जो भी औज़ार के पास था उसी के ख़िलाफ़ जाँचा जाएगा।

कई bundler प्लेन बाइट-गिनती को asset-सीमा के रूप में स्वीकारते हैं, और उस रूप में इस्तेमाल करने का मतलब है कि कोई प्रीफ़िक्स तय करने की ज़रूरत नहीं।

जहाँ औज़ार प्रीफ़िक्स पर अड़ा हो, बाइनरी वाला चुनिए और साफ़ लिखिए — किसी proxy-configuration में 50m लिखा 52,428,800 बाइट है, चाहे पढ़ने वाले ने कुछ भी मान लिया हो।

प्रदर्शन-बजट छोटी, लगातार बढ़ोतरी पकड़ने के लिए हैं, और वे जिस अंतराल को पकड़ने की कोशिश करते हैं वह अक्सर इसी इकाई-ग़लती के बराबर है। हर रिलीज़ चार प्रतिशत बढ़ता bundle यही ठीक चीज़ है जो बजट को पकड़नी चाहिए।

इलाज है बताया गया अंक और सीमा को एक ही स्रोत से लाना — जो भी इकाई build-औज़ार मापता है, वही सीमा में लिखिए।

क्लाइंट-साइड भंडार — कैश, डेटाबेस — ब्राउज़र द्वारा गिनी गई कोटा के ख़िलाफ़ मापा जाता है, और यह exact बाइट-गिनती देता है, बिना किसी प्रीफ़िक्स के।

कच्चे बाइट रखने की वजह है कि कोटा बदलते रहते हैं — मुक्त डिस्क, browser-नीति पर निर्भर। बदला हुआ अंक hard-code करने वाला कोड बदलावों के साथ चलेगा नहीं।

हज़ार से बाँटिए, फिर पाँच प्रतिशत घटा दीजिए। 4,400 kB लगभग 4.18 MiB बनता है, ठीक-ठीक 4.1962 के ख़िलाफ़ — इतना नज़दीक कि तुरंत पता चल जाए कि 4 MiB सीमा पार हुई या नहीं।