MB naar MiB omrekenen

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.

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,953674, en die draagt vrijwel niemand met zich mee. Afgerond op 0,95 zit hij er 0,39 % naast — bij kleine getallen onzichtbaar, en rond 1.000 MB 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 1,0486 MB en 1 MB — 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 bestandsbeheerder toont 24,8 MB. Het formulier zegt maximaal 25 MB. De upload wordt geweigerd, twee keer, en niets op beide schermen verklaart waarom. Wat gebeurde is dat de twee getallen in verschillende eenheden staan met dezelfde afkorting: de bestandsbeheerder deelde door 1.048.576 en de server deelde door 1.000.000, dus is 24,8 aan de ene kant 26,0 aan de andere.

Dit is de meest voorkomende manier waarop de binair-decimaal-splitsing iemand echte tijd kost, en het is volledig onzichtbaar terwijl het gebeurt. Er is geen foutmelding die zegt "jouw megabyte is niet onze megabyte". Het bestand faalt, de voor de hand liggende volgende zet is comprimeren of bijsnijden, en degene die dat doet leert nooit dat de marge die nodig was een procent was in plaats van tien.

Limieten geschreven door aanbieders zijn meestal decimaal, want ze zijn gezet door mensen die specificaties schrijven in plaats van door een besturingssysteem dat een maplijst weergeeft. Een plafond van 25 MB is 25.000.000 bytes, een veld "max 10 MB" is 10.000.000, en een avatarlimiet van 2 MB is 2.000.000. Wordt een limiet in code afgedwongen, dan is het bijna altijd een geheel getal bytes rechtstreeks vergeleken, en dat gehele getal is met de hand geschreven als een rond decimaal cijfer.

De grootte die je ziet, komt daarentegen van wat het weergeeft. Windows telt in mebibytes en schrijft MB. De meeste Linux-bestandsbeheerders doen hetzelfde. De macOS Finder telt in megabytes en bedoelt het. De twee cijfers voor je zijn dus doorgaans op verschillende manieren gemeten, en het verschil loopt altijd dezelfde kant op: het bestand is groter dan het oogt.

Verkenner gebruikt al stappen op basis van 1.024 sinds lang voor de IEC de mebibyte in 1998 bedacht, en heeft de nieuwere namen nooit overgenomen. Een bestand van 26.004.685 bytes wordt getoond als 24,8 MB, wat een correcte deling door 1.048.576 is en een onjuist label. Microsoft heeft het label behouden voor compatibiliteit met drie decennia documentatie, schermafbeeldingen en gewoonte.

De uitweg is het eigenschappenvenster, dat de exacte bytentelling onder het vriendelijke cijfer afdrukt. Dat getal is ondubbelzinnig en is waar een server tegen vergelijkt. Doet een limiet ertoe — een upload, een mailboxquotum, een inzendportaal — lees dan de bytentelling en vergelijk gehele getallen in plaats van twee afgeronde cijfers in twee conventies te lezen en te hopen.

Snow Leopard veranderde de Finder om opslag decimaal te rapporteren, dus liet een schijf verkocht als 500 GB eindelijk 500 GB zien en werden bestanden ’s nachts iets grotere getallen. De verandering verwijderde een verwarring en creëerde een andere: hetzelfde bestand leest nu anders op een Mac en op een pc, met beide schermen die MB zeggen.

Dat is de moeite waard om te weten als iemand anders je een grootte opgeeft. "Het is 26 megabyte" van een Mac-gebruiker en "het is 24,8 megabyte" van een Windows-gebruiker kunnen hetzelfde bestand zijn, en de discrepantie is geen overdrachtsprobleem, geen compressieverschil en geen beschadigde kopie. Verschillen twee mensen zo’n vijf procent over een grootte, dan is de eenheid het eerste om te controleren.

De nuttige rekenkunde gaat andersom dan waar deze pagina naar vernoemd is. Is een limiet 25 MB decimaal, dan is het grootste bestand dat past 23,84 MiB, wat je bestandsbeheerder zal tonen als 23,8 MB. Voor een limiet van 10 MB is het doel 9,5 zoals getoond; voor 50 MB is het 47,7; voor 2 MB is het 1,9. De regel is de opgegeven limiet met 0,954 te vermenigvuldigen en het resultaat te behandelen als het cijfer op je eigen scherm.

Een ronde versie is makkelijker te onthouden en veiliger: trek vijf procent af van de opgegeven limiet en mik daaronder. De verloren marge is triviaal — een halve mebibyte op een plafond van 25 MB — en absorbeert zowel de eenheidskloof als wat de upload rond het bestand wikkelt. Een bestand dat met ruimte over past, wordt in één keer geüpload.

E-mail is het geval waar de eenheidskloof het kleinere probleem is. Bijlagen worden base64-gecodeerd zodat binaire data een tekstoverdracht overleeft, en base64 maakt van elke drie bytes vier tekens — een toename van 33 procent voor de regeleindes meegeteld zijn. Geldt de opgegeven limiet voor het samengestelde bericht, dan accepteert een plafond van 25 MB een bestand van ruwweg 18 MB, en geen eenheidsomzetting verklaart de ontbrekende zeven.

Webformulieren gedragen zich anders en beter. Een browser-upload gebruikt multipart formuliergegevens, wat de bytes ongewijzigd draagt met slechts een paar honderd bytes headers en scheidingstekens eromheen. Een limiet van 10 MB op een webformulier gaat dus echt over het bestand, en de enige correctie nodig is de decimaal-versus-binaire. Weten in welke van de twee situaties je zit, vertelt je of je vijf procent of een kwart moet aftrekken.

Een kloof van een half procent zou wegvallen in afronding en een kloof van vijftig zou opvallen. Deze zit in de band waar hij niets verandert aan hoe een bestand aanvoelt en alles aan of het een drempel haalt. Foto’s, documenten en korte video’s belanden allemaal in het bereik waar een opgegeven limiet en een getoonde grootte minder dan een afrondingsstap verschillen die je zou bevragen.

Het stapelt ook op naar boven, wat waarom hetzelfde misverstand meer kost naarmate de getallen groter worden. De binaire en decimale eenheden divergeren met 2,4 procent bij kilo, 4,86 bij mega, 7,37 bij giga en 9,95 bij tera, want elke stap vermenigvuldigt de discrepantie opnieuw met 1,024. Bij een e-mailbijlage is dat één geweigerd bestand; bij een opslagarray is het het grootste deel van een schijf.

Is de eenheidsvraag opgelost, dan is de overgebleven kloof echt en hangt de oplossing af van wat het bestand is. Foto’s en video zijn al gecomprimeerd, dus levert ze in een ZIP zetten bijna niets op — een procent of twee, soms minder dan de overhead van het archief. De afmetingen verkleinen is wat echt werkt: de pixelbreedte van een afbeelding halveren verwijdert ongeveer drie kwart van de data, en het is meestal onzichtbaar op een scherm waarop de ontvanger het bekijkt.

Documenten gedragen zich anders. Een PDF is vaak groot door de afbeeldingen erin in plaats van de tekst, dus kan opnieuw exporteren op een lagere afbeeldingsresolutie veel verwijderen zonder de leesbaarheid aan te tasten. Kantoorbestanden, logs en dataexports comprimeren goed en een ZIP is als eerste de moeite waard. En waar het bestand slechts iets te groot is — wat na deze omzetting meestal zo is — is één ingebedde afbeelding of een ongebruikte pagina verwijderen sneller dan alles opnieuw coderen.