KiB naar MB omrekenen

Een kibibyte is precies 1.024 bytes. De naam is in 1998 ingevoerd zodat «kilobyte» weer 1.000 kon betekenen, al is de gewoonte nooit helemaal aangeslagen.

Een megabyte is een miljoen bytes. Fabrikanten van opslag hebben altijd decimaal geteld, en daarom lijken hun getallen groter dan wat de computer laat zien.

De factor is 0,001024, en die draagt vrijwel niemand met zich mee. Afgerond op 0,00102 zit hij er 0,39 % naast — bij kleine getallen onzichtbaar, en rond 1.000 KiB 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 KiB is 1.024 van de eenheid eronder; één kB is 1.000. Op deze pagina is dat het verschil tussen 0,001 MB en 0,001 MB — 2,4 % — 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 bestand vermeld als 24.500 KiB oogt alsof het ruim onder een limiet van 25 MB blijft. Dat doet het niet: 24.500 KiB is 25.088.000 bytes, en een limiet afgedwongen als 25.000.000 wijst het af met 88.000 bytes. Niets in beide cijfers verklaart de weigering, wat waarom de gewone volgende stap is het opnieuw te proberen, dan de dienst de schuld te geven, en pas veel later te controleren wat de twee getallen werkelijk betekenen.

De kloof heeft twee componenten die vermenigvuldigd worden. Elke kibibyte is 2,4 procent groter dan een kilobyte, en er zitten er duizend per megabyte in plaats van 1.024, dus onderschat een KiB-cijfer door duizend gedeeld het bestand door heel het traject met 2,4 procent. Op een kleine bijlage is dat een paar kilobyte en irrelevant. Binnen vijf procent van een harde limiet beslist het de uitkomst.

Vermenigvuldig met 1.024 om bytes te krijgen, deel dan door een miljoen. 24.500 × 1.024 is 25.088.000, en dat is 25,088 MB. In één stap is het een vermenigvuldiging met 0,001024, wat exact is en eindigt, dus zit er nergens afronding in de rekenkunde en komen twee correcte omzetters exact overeen. De onzekerheid zit nooit in de som; hij zit in wat de limiet aan de andere kant telt.

De controle die een verwisselde omzetting opvangt is de richting van de verandering. Van KiB naar MB gaan moet de numerieke waarde met ruwweg een factor duizend laten dalen, en iets minder dan duizend precies, want kibibytes zijn de grotere eenheid. Een resultaat dat precies een duizendste is, heeft de 2,4 procent laten vallen, en een resultaat dat 1.024 keer kleiner is, is naar MiB omgezet.

De meeste consumentendiensten documenteren een limiet in MB en controleren die tegen een decimaal bytentotaal, dus is 25 MB 25.000.000 bytes. Sommige controleren het binaire cijfer, wat 26.214.400 is en 4,9 procent royaler. De documentatie zegt zelden welke, en het verschil wordt pas zichtbaar op het moment dat een bestand geweigerd wordt, wat het slechtste moment is om te gaan onderzoeken.

Dat maakt onverschilligheid de veiligere strategie dan precisie. Zit een bestand binnen vijf procent van een opgegeven plafond, dan zit het in het gebied waar het antwoord van een implementatiedetail afhangt dat je niet kunt zien, en is de juiste reactie het bestand kleiner te maken in plaats van te bepalen welke lezing van toepassing is. Onder zo’n negentig procent van het plafond is elke plausibele interpretatie het eens en hoeft de vraag niet gesteld te worden.

E-mailbijlagen worden niet als bytes verstuurd. Ze worden gecodeerd in een tekstveilige vorm die elke drie bytes als vier tekens weergeeft, wat ongeveer 33 procent toevoegt, en regeleindes voegen nog iets toe. Een bestand van 20 MB komt dus bij de groottecontrole aan als ongeveer 27 MB bericht, en een limiet van 25 MB op de totale berichtgrootte weigert het ruimschoots.

Dit is het effect om te onthouden, want het is een orde van grootte groter dan alles op deze pagina over kilobytes. Waar een limiet voor een bericht geldt in plaats van een bestand, is de bruikbare bestandsgrootte ongeveer drie kwart van het opgegeven cijfer. Uploads over het web zijn meestal niet getroffen, want een bestand verstuurd als formulierdata gaat als ruwe bytes, maar alles dat als post reist draagt de overhead.

Gehoste repositories zijn strenger dan mail omdat ze programmatisch controleren en bij de grens weigeren. Een platform dat boven 50 MB waarschuwt en boven 100 MB weigert, vergelijkt een bytentelling, en een bestand vermeld als 97.000 KiB is 99.328.000 bytes — onder de limiet, maar met minder dan een procent, wat geen marge is om op te plannen. Grote bestanden in een repository blijven ook bestaan in de geschiedenis, dus geldt de controle voor alles dat ooit gecommit is, niet voor wat er nu staat.

Het patroon dat de hele categorie vermijdt, is grote binaire bestanden buiten de plek met het plafond te houden: een artefactopslag, een objectbucket, of een large-file-extensie die een verwijzing in de repository opslaat en de inhoud elders. Dat is een andere beslissing dan het getal correct omzetten, en het is degene waardoor het getal niet herhaaldelijk omgezet hoeft te worden.

Mist een bestand het plafond met een paar procent, dan zijn de goedkoopste verkleiningen meestal geen compressie. Afbeeldingen dragen ingebedde thumbnails, kleurprofielen en cameraметadata die enkele honderden kilobytes kunnen zijn; documenten stapelen revisiegeschiedenis en ingebedde lettertypen op; archieven bevatten vaak bestanden die al gecomprimeerd zijn en niets winnen bij nogmaals comprimeren. Verwijderen wat niet nodig is wint van uitknijpen wat er is.

Moet de inhoud zelf krimpen, wees dan bewust van wat elke stap kost. Een foto opnieuw coderen op lagere kwaliteit is lossy en onomkeerbaar; de afmetingen verkleinen is meestal effectiever per eenheid zichtbare schade; een archief splitsen vermijdt het verlies helemaal tegen de prijs van een ongemakkelijkere overdracht. Een al gecomprimeerd bestand herhaaldelijk opnieuw comprimeren is de ene aanpak die betrouwbaar faalt, want de tweede doorgang heeft bijna niets meer te vinden. Op een bestand dat een paar procent te groot is, wint één ingebed element verwijderen meestal van elke andere optie, want het is exact, omkeerbaar en kost niets aan kwaliteit.

Een gereedschap dat KiB afdrukt heeft zijn conventie verklaard en is te vertrouwen. Een gereedschap dat KB afdrukt heeft dat niet, en op Windows bedoelt het vrijwel zeker 1.024 bytes ondanks het label. Dat betekent dat hetzelfde bestand door het ene gereedschap gerapporteerd kan worden als 24.500 KiB en door een ander als 24.500 KB, met beide cijfers identieke bytes beschrijvend en slechts een eerlijk gelabeld.

Doet precisie ertoe, vraag dan om de bytentelling in plaats daarvan. Elke bestandsbeheerder toont hem ergens, elk commandoregelgereedschap drukt hem af, en het haalt de vraag helemaal weg — een bytentelling hoeft niet geïnterpreteerd te worden, zet exact om naar elke eenheid, en is het getal waar de limiet toch tegen vergeleken zal worden. Herhaalt een workflow zich — een wekelijkse export, een batch scans, een set opleveringen naar dezelfde klant — dan verwijdert die bytentelling eenmalig vastleggen de omzetting uit elke volgende ronde.