Converter kB para MiB

Um kilobyte são 1.000 bytes quando quem define é um órgão de normalização e 1.024 quando quem define é um sistema operacional. Esta página calcula com 1.000; a unidade de 1.024 se chama kibibyte.

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,000954, e quase ninguém carrega isso na cabeça. Arredondado para 0,00095 ele erra 0,39 % — invisível em números pequenos, e já uma unidade inteira por volta de 1.000 kB.

É 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 1048,576 kB e 1000 kB — 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 projeto front-end carrega as duas convenções ao mesmo tempo e raramente avisa isso. O painel de rede relata tamanhos de transferência em kilobytes de 1.000 bytes, orientações de performance são escritas do mesmo jeito, e cobrança de CDN conta gigabytes decimais porque é assim que banda sempre foi vendida. Enquanto isso, a ferramenta de build, o cache do proxy e a cota de armazenamento do navegador por baixo de tudo isso contam em potências de 1.024.

A conversão entre os dois cruza um passo de prefixo e a linha decimal-binário junto, então divide por 1.048,576 em vez de por mil. Num pacote de 3.000 kB, isso é a diferença entre 3,00 e 2,86, e a cifra menor é a verdadeira. Checar um limite binário com o atalho decimal sempre relata mais folga do que existe, a direção errada para um erro de checagem.

Números que valem a pena ter: 500 kB são 0,4768 MiB, 1.000 kB são 0,9537, 2.000 kB são 1,9073 e 5.000 kB são 4,7684. Uma página que o painel de rede totaliza em 2.090 kB não passou de um orçamento de 2 MiB, porque 2 MiB são 2.097,152 kB — mas está a sete kilobytes disso, e uma leitura decimal contra uma linha de 2 MB teria declarado ultrapassado noventa kilobytes antes.

A lacuna corre na direção contrária para um limite declarado em binário e lido como decimal. Um cache configurado em 50 MiB guarda 52.428,8 kB de recursos, não 50.000, e um plano de capacidade construído sobre a cifra redonda deixa quase dois megabytes e meio do cache não utilizados. Nenhum erro é grande, e os dois são sistemáticos, o que significa que se acumulam na mesma direção toda vez que o cálculo é repetido.

Antes de discutir os 4,9 por cento, vale acertar qual tamanho está sendo medido. Um pacote de texto tipicamente comprime para um terço do comprimento original ou menos, então o mesmo arquivo pode ser honestamente descrito como 900 kB ou 260 kB dependendo de a cifra ser o que o build produziu ou o que atravessou a rede. Isso é um fator de três, contra uma questão de unidade que vale cinco por cento.

Orçamentos deveriam, portanto, nomear o estado tanto quanto a unidade: transferido, comprimido, ou bruto em disco. Ferramentas de build geralmente relatam tamanhos de recurso sem compressão porque é isso que elas têm, e painéis de navegador relatam bytes transferidos porque é isso que observaram. Um limite que não diz qual dos dois governa vai ser imposto contra o que a ferramenta tiver por acaso, e os dois não são comparáveis.

Vários empacotadores aceitam limites de tamanho de recurso como contagens de bytes puras, e usar essa forma significa que nenhum prefixo precisa ser acordado. Um limite de 250.000 bytes é inequívoco, busca de forma limpa, e é diretamente comparável contra as contagens de bytes que a mesma ferramenta relata. Um limite escrito como 250 kB é a mesma intenção com uma nota de rodapé anexada, e a nota é a parte que se perde quando a configuração é copiada para outro projeto.

Onde a ferramenta insiste num prefixo, prefira o binário e escreva explicitamente. Um limite de cache de 50m numa configuração de proxy são 52.428.800 bytes seja lá o que quem lê presumiu, e escrever MiB no comentário ao lado custa uma linha. A alternativa é um limite que todos acreditam ser 50 milhões de bytes e que na verdade é quase dois milhões e meio maior.

Orçamentos de performance existem para pegar crescimento pequeno e constante, e o tamanho da lacuna que procuram frequentemente é do mesmo tamanho que esse erro de unidade. Um pacote crescendo quatro por cento por lançamento é exatamente o tipo de deriva que um orçamento deveria sinalizar, e é exatamente a quantia que uma discrepância decimal-versus-binário vai absorver antes de alguém perceber. Um lançamento de folga inexplicada já é o suficiente para esconder um quarto inteiro de crescimento.

A correção é fazer o número relatado e o limite virem da mesma fonte. Se a ferramenta de build mede em bytes, defina o orçamento em bytes; se o monitoramento mede kilobytes transferidos, defina o orçamento em kilobytes transferidos. Toda conversão entre o relatório e o limite é um lugar onde um desvio sistemático pode se instalar e ficar.

Armazenamento do lado do cliente — caches, bancos de dados, estado persistido — é medido contra uma cota que o navegador calcula a partir do disco disponível, e as contagens de bytes que relata são exatas em vez de prefixadas. Pedir à estimativa de armazenamento seus números dá uso e cota em bytes, a forma para comparar, e convertê-los para mebibytes para exibição é uma escolha de apresentação feita depois.

O motivo de manter os bytes brutos é que cotas se movem. Dependem de disco livre, da classe de armazenamento da origem, e da política do navegador, então um valor que era 500 MiB semana passada pode não ser essa semana. Código que guarda a contagem de bytes e reconfere vai se comportar corretamente por essas mudanças; código que fixa uma cifra convertida numa unidade mais amigável não vai.

O símbolo SI para kilo é um k minúsculo, então um kilobyte decimal é corretamente escrito kB. A unidade binária leva maiúscula: KiB, com o K maiúsculo escolhido deliberadamente porque o minúsculo já estava ocupado. Isso deixa KB, com K maiúsculo e sem i, como a forma que não pertence a nenhum padrão e é usada o tempo todo, geralmente significando 1.024.

A grafia é, portanto, um sinal fraco em vez de uma regra. Um documento que escreve kB e MB consistentemente, com a caixa correta em todo lugar, provavelmente foi escrito por alguém que conhece a diferença e quer dizer decimal. Um que escreve KB segue um hábito muito mais antigo e muito provavelmente quer dizer 1.024. Nenhuma observação é forte o bastante para agir sozinha, mas as duas valem notar antes de assumir de qual convenção uma cifra veio.

Divida por mil, depois tire cinco por cento. Um total de 4.400 kB vira 4,4 e depois cerca de 4,18 MiB, contra 4,1962 exato — perto o bastante para saber na hora se um teto de 4 MiB foi ultrapassado. Para qualquer coisa até alguns megabytes, a estimativa fica a poucos kilobytes da cifra verdadeira.

Na direção contrária, multiplique por mil e acrescente cinco por cento: um limite de 10 MiB são cerca de 10.500 kB, contra 10.485,76. Os dois atalhos não são simétricos, já que um tira 4,86 por cento e o outro devolve isso sobre uma base menor, mas nessa escala a diferença entre as duas correções é alguns kilobytes e cabe folgadamente dentro do ruído de qualquer medição real.