kB naar MiB omrekenen

Een kilobyte is 1.000 bytes als een normalisatie-instituut hem definieert en 1.024 als een besturingssysteem dat doet. Deze pagina rekent met 1.000; de eenheid van 1.024 heet kibibyte.

Een mebibyte is 1.024 kibibyte, oftewel 1.048.576 bytes. De hulpmiddelen van Linux en de geheugengetallen bedoelen vrijwel altijd dit, ook als er «MB» staat.

De factor is 0,000954, en die draagt vrijwel niemand met zich mee. Afgerond op 0,00095 zit hij er 0,39 % naast — bij kleine getallen onzichtbaar, en rond 1.000 kB een hele eenheid.

Dat is het getal dat je vóór het afronden wilt weten: niet de fout zelf, maar vanaf waar hij ophoudt verwaarloosbaar te zijn. Daaronder is de korte factor de verstandige; daarboven gebruik je het veld hierboven, dat pas afrondt op het moment van afdrukken.

Eén MiB is 1.024 van de eenheid eronder; één MB is 1.000. Op deze pagina is dat het verschil tussen 1048,576 kB en 1000 kB — 4,9 % — en het gat groeit bij elke stap omhoog: op een foto een verwaarloosbare afronding, op een harde schijf een zichtbaar stuk.

Hierin zit het raadsel van de verdwenen opslag volledig. Een schijf die als terabyte verkocht wordt bevat in decimale eenheden precies wat erop staat; Windows telt hem daarna in binaire eenheden maar houdt de decimale naam aan, en daar krimpt het getal zonder dat er iets weg is. macOS telt deze eenheden sinds 10.6 decimaal, en daarom kan dezelfde schijf op twee computers twee maten lijken.

Een front-endproject draagt beide conventies tegelijk en zegt dat zelden. Het netwerkpaneel rapporteert overdrachtsgroottes in kilobytes van 1.000 bytes, prestatierichtlijnen zijn op dezelfde manier geschreven, en CDN-facturatie telt in decimale gigabytes want zo is bandbreedte altijd verkocht. Ondertussen tellen de buildtool, de proxycache en het opslagquotum van de browser eronder allemaal in machten van 1.024.

De omzetting tussen de twee steekt een voorvoegselstap en de grens tussen decimaal en binair tegelijk over, dus deelt hij door 1.048,576 in plaats van door duizend. Op een bundel van 3.000 kB is dat het verschil tussen 3,00 en 2,86, en het kleinere cijfer is het echte. Een binaire limiet controleren met de decimale kortere weg meldt altijd meer speling dan er is.

De cijfers om te kennen: 500 kB is 0,4768 MiB, 1.000 kB is 0,9537, 2.000 kB is 1,9073 en 5.000 kB is 4,7684. Een pagina die een netwerkpaneel optelt tot 2.090 kB is nog geen 2 MiB-budget over, want 2 MiB is 2.097,152 kB — maar zit binnen zeven kilobyte ervan, en een decimale aflezing tegen een 2 MB-lijn zou het al negentig kilobyte eerder als over gemeld hebben.

De kloof loopt de andere kant op voor een limiet in binair opgegeven en decimaal gelezen. Een cache ingesteld op 50 MiB bevat 52.428,8 kB aan assets, niet 50.000, en een capaciteitsplan gebouwd op het ronde cijfer laat bijna twee en een half megabyte van de cache ongebruikt.

Voordat over 4,9 procent gediscussieerd wordt, is het de moeite waard vast te stellen welke grootte gemeten wordt. Een tekstbundel comprimeert doorgaans tot een derde van zijn ongecomprimeerde lengte of minder, dus hetzelfde bestand kan eerlijk 900 kB of 260 kB genoemd worden afhankelijk van of het cijfer is wat de build produceerde of wat over het netwerk ging.

Budgetten horen dus de toestand net zo goed als de eenheid te noemen: overgedragen, gecomprimeerd, of ruw op schijf. Buildtools rapporteren doorgaans ongecomprimeerde assetgroottes omdat dat is wat ze hebben, en browserpanelen rapporteren overgedragen bytes omdat dat is wat ze zagen.

Verscheidene bundlers accepteren assetgrootte-limieten als kale bytetellingen, en die vorm gebruiken betekent dat er geen voorvoegsel afgesproken hoeft te worden. Een limiet van 250.000 bytes is ondubbelzinnig en direct vergelijkbaar met de bytetellingen die dezelfde tool rapporteert. Een limiet geschreven als 250 kB is dezelfde bedoeling met een voetnoot eraan.

Waar de tool op een voorvoegsel staat, geef de voorkeur aan het binaire en schrijf het expliciet. Een cachelimiet van 50m in een proxyconfiguratie is 52.428.800 bytes wat de lezer ook aannam, en MiB in het commentaar ernaast schrijven kost één regel.

Prestatiebudgetten bestaan om kleine, gestage groei te vangen, en de omvang van de kloof die ze zoeken, is vaak even groot als deze eenhedenfout. Een bundel die vier procent per release groeit, is precies het soort drift dat een budget zou moeten signaleren, en het is precies de hoeveelheid die een decimaal-versus-binair verschil zal absorberen voordat iemand het merkt.

De oplossing is het gerapporteerde getal en de limiet uit dezelfde bron te laten komen. Meet de buildtool in bytes, stel het budget dan in bytes; meet de monitoring overgedragen kilobytes, stel het budget dan in overgedragen kilobytes.

Opslag aan de cliëntkant — caches, databases, bewaarde staat — wordt gemeten tegen een quotum dat de browser berekent uit beschikbare schijfruimte, en de bytetellingen die het rapporteert zijn exact in plaats van voorvoegseld. Het opslagestimaat om zijn cijfers vragen geeft gebruik en quotum in bytes, wat de vorm is om te vergelijken.

De reden om de ruwe bytes te bewaren is dat quota bewegen. Ze hangen af van vrije schijfruimte, de opslagklasse van de origin, en browserbeleid, dus een waarde die vorige week 500 MiB was, is deze week misschien anders. Code die de bytetelling opslaat en herbevestigt, gedraagt zich correct.

Deel door duizend, trek er dan vijf procent af. Een totaal van 4.400 kB wordt 4,4 en dan ongeveer 4,18 MiB, tegen exact 4,1962 — dicht genoeg om meteen te weten of een plafond van 4 MiB is overschreden. Voor alles tot een paar megabyte zit de schatting binnen een paar kilobyte van het echte cijfer.

De andere kant op, vermenigvuldig met duizend en tel er vijf procent bij op: een limiet van 10 MiB is ongeveer 10.500 kB, tegen 10.485,76. De twee kortere wegen zijn niet symmetrisch, maar op deze schaal is het verschil tussen de twee correcties een paar kilobyte en ruim binnen de ruis van elke echte meting.