Converter MB para MiB

Um megabyte é um milhão de bytes. Os fabricantes de armazenamento sempre contaram em decimal, e por isso os números deles parecem maiores do que o que o computador mostra.

Um mebibyte são 1.024 kibibytes, ou seja 1.048.576 bytes. As ferramentas do Linux e os números de memória quase sempre se referem a isto, mesmo escrevendo «MB».

O fator é 0,953674, e quase ninguém carrega isso na cabeça. Arredondado para 0,95 ele erra 0,39 % — invisível em números pequenos, e já uma unidade inteira por volta de 1.000 MB.

É esse o número que interessa antes de arredondar: não o erro em si, mas a partir de onde ele deixa de ser desprezível. Abaixo disso o fator curto é o sensato; acima, use o campo lá em cima, que só arredonda na hora de escrever.

Um MiB são 1.024 da unidade de baixo; um MB, 1.000. Nesta página isso é a diferença entre 1,0486 MB e 1 MB — 4,9 % — e a distância cresce a cada degrau: por isso é arredondamento desprezível numa foto e um pedaço visível de um HD.

O mistério do espaço que some é inteiro isso. Um disco vendido como um terabyte tem exatamente o que diz em unidades decimais; o Windows reconta em unidades binárias e mantém o nome decimal, então o número encolhe sem que nada tenha se perdido. O macOS conta em unidades decimais desde o 10.6, e é por isso que o mesmo disco pode aparecer com dois tamanhos em dois computadores.

Um gerenciador de arquivo mostra um tamanho abaixo do limite. O formulário diz máximo de tantos MB. O upload é recusado, duas vezes, e nada nas duas telas explica isso. O que aconteceu é que os dois números estão em unidades diferentes usando a mesma abreviação: o gerenciador de arquivo dividiu por uma potência de 1.024 e o servidor dividiu por um milhão redondo, então um número menor de um lado corresponde a um maior do outro.

Essa é a forma mais comum de a divisão entre binário e decimal custar tempo real de alguém, e é totalmente invisível enquanto acontece. Não existe mensagem de erro dizendo "o seu megabyte não é o nosso megabyte". O envio falha, o movimento óbvio seguinte é comprimir ou cortar o arquivo, e quem faz isso nunca descobre que a margem necessária era de um por cento, não de dez.

Limite escrito por provedor costuma ser decimal, porque é definido por gente escrevendo especificação, não por um sistema operacional renderizando uma listagem de pasta. Um teto de vinte e cinco MB significa vinte e cinco milhões de bytes redondos, e quando um limite é aplicado em código quase sempre é um número inteiro de bytes comparado diretamente, escrito à mão como uma cifra decimal redonda.

O tamanho que você vê, por outro lado, vem de quem está exibindo. Windows conta em unidade binária e escreve MB. A maioria dos gerenciadores de arquivo do Linux faz o mesmo. O Finder do macOS conta em unidade decimal e quer dizer isso mesmo. Então os dois números na sua frente costumam ser medidos de formas diferentes, e a diferença sempre corre na mesma direção: o arquivo é maior do que parece.

O Explorador de Arquivos usa degraus baseados em 1.024 desde muito antes de os nomes binários específicos existirem, e nunca adotou os nomes mais novos. Um arquivo de um certo tamanho em byte é mostrado com um rótulo que a divisão binária correta produziu, mas com a etiqueta errada. A Microsoft manteve o rótulo por compatibilidade com décadas de documentação, captura de tela e hábito.

A saída é a caixa de propriedades, que imprime a contagem exata de byte por baixo do número amigável. Esse número é inequívoco e é o que um servidor compara. Se um limite importa — um upload, uma cota de caixa de e-mail, um portal de envio — leia a contagem de byte e compare números inteiros em vez de ler duas cifras arredondadas em duas convenções e torcer.

Numa atualização de 2009 o Finder passou a relatar armazenamento em unidade decimal, então um disco vendido com uma certa capacidade finalmente exibia esse mesmo número, e arquivos passaram a mostrar cifras ligeiramente maiores da noite para o dia. A mudança removeu uma confusão e criou outra: o mesmo arquivo agora lê diferente num Mac e num PC, com as duas telas dizendo MB.

Vale saber isso quando alguém te informa um tamanho verbalmente. "São vinte e seis megabytes" de quem usa Mac e "são vinte e quatro vírgula oito megabytes" de quem usa Windows podem ser o mesmo arquivo, e a discrepância não é um problema de transferência, uma diferença de compressão nem uma cópia corrompida. Se duas pessoas discordam sobre um tamanho por uns cinco por cento, a unidade é a primeira coisa a conferir.

A conta útil corre na direção oposta da que dá nome a esta página. Se um limite decimal é de vinte e cinco MB, o maior arquivo que cabe é um pouco menos que isso em unidade binária, o que o seu gerenciador de arquivo vai mostrar como um número levemente menor que vinte e cinco. A regra prática é multiplicar o limite declarado por 0,954 e tratar o resultado como o número na sua própria tela.

Uma versão mais redonda é mais fácil de lembrar e mais segura: subtraia cinco por cento do limite declarado e mire abaixo disso. A margem perdida é trivial, e ela absorve tanto a lacuna de unidade quanto o que quer que o envio embrulhe ao redor do arquivo. Um arquivo que cabe com folga sobe de primeira.

E-mail é o caso em que a lacuna de unidade é o problema menor. Anexo é codificado num formato de texto para sobreviver a um transporte de texto, e essa codificação aumenta o tamanho em cerca de um terço antes mesmo de contar quebra de linha. Onde o limite declarado se aplica à mensagem montada, um teto de vinte e cinco MB aceita um arquivo bem menor que isso, e nenhuma conversão de unidade explica o resto que falta.

Formulário web se comporta diferente e melhor. Um upload de navegador carrega os bytes praticamente sem alteração, com só algumas centenas de bytes de cabeçalho ao redor. Então um limite num formulário web realmente é sobre o arquivo, e a única correção necessária é a de decimal contra binário. Saber em qual das duas situações você está diz se deve cortar cinco por cento ou um quarto.

Uma lacuna pequena demais arredondaria fora, e uma enorme seria óbvia. Esta fica na faixa em que não muda nada sobre como um arquivo parece e muda tudo sobre se ele passa de um limiar. Fotografia, documento e vídeo curto caem todos na faixa em que um limite declarado e um tamanho exibido diferem por menos do que qualquer um questionaria.

Também se acumula para cima, motivo pelo qual o mesmo mal-entendido custa mais quanto maiores os números ficam. As unidades binária e decimal divergem cada vez mais a cada degrau da escada, porque cada passo multiplica a discrepância de novo. Num anexo de e-mail isso é um arquivo recusado; num conjunto de armazenamento é boa parte de um disco inteiro.

Uma vez resolvida a questão de unidade, a lacuna que resta é real e o conserto depende do tipo de arquivo. Fotografia e vídeo já vêm comprimidos, então colocar num ZIP economiza quase nada — o que realmente funciona é reduzir a dimensão: cortar a largura em pixel de uma imagem pela metade remove boa parte do dado, e costuma ser invisível numa tela em que o destinatário vai ver.

Documento se comporta diferente. Um PDF costuma ser grande por causa das imagens dentro dele, não do texto, então reexportar numa resolução de imagem menor tira bastante peso sem tocar na legibilidade. Arquivo de escritório, log e exportação de dado comprimem bem, e um ZIP vale tentar primeiro. E onde o arquivo está só um pouco acima do limite, o que depois desta conversão costuma ser o caso, cortar uma imagem embutida ou uma página não usada é mais rápido que recodificar tudo.