Quais são as limitações específicas do armazenamento hexadecimal em um disco rígido? [duplicado]


-1

Vou começar dizendo que não sou especialista em computação. Minha pergunta é postada como um ponto de curiosidade.

Buscando na web por respostas, tenho visto postado que hexadecimal poderia ser usado para armazenar numérico informações sobre discos rígidos. Eu até perguntei neste site e recebi respostas muito bem escritas e lógicas. Mas existem muitos sites onde há aqueles que alegam que o hexadecimal pode ser usado para armazenar informações numéricas em um disco rígido. Nota: guarde, não exiba .

A lógica predominante nesses casos é que desde dígitos hexadecimais são meio bytes, ou nibbles, eles ocupam somente o tamanho do valor numérico regular de um conjunto de caracteres.

Para cada 100 bytes usados ​​para representar um número a 100 dígitos , construído a partir de um conjunto de caracteres, apenas 42 bytes podem ser usados ​​para armazenar a mesma seqüência numérica que os dígitos hexadecimais. A equação: [100 log 10 / log 16] é utilizada para apoiar esta noção.

No entanto, outros alegaram que o armazenamento real de informações em hexadecimal em um disco rígido não é tão eficiente, porque os dígitos hexadecimais (A-F) seriam armazenado como caracteres completos que requerem 8 bits ou 1 byte. Por exemplo, para armazenar 1A34B7 Na verdade, seria necessário pelo menos dois dígitos hexadecimais para representados com bytes completos no disco rígido em vez de metade bytes para as porções numéricas. Ele pode exibir o valor em meio-bytes, mas quando o armazenamento entra em jogo, os dígitos hexadecimais do caractere devem usar bytes completos.

Qual é a realidade desse cenário?

Obrigado.


Eu acho que você está perdendo um ponto chave. Não há números armazenados (base 10 ou base 16). Há apenas informações armazenadas e a maneira como você as interpreta.
Hennes

E a interpretação feita é como seria o armazenamento hexadecimal em um disco rígido e como ele interpretaria essa informação no cenário postado acima? Obrigado.
J. J.

Por favor, forneça links para esses sites que você cita.
sawdust

Respostas:


0

Eu acho que você está confundindo alguns tópicos.

Se você tivesse que armazenar o número 100 em um computador, ele seria armazenado em binário, hex 0x64, que ocuparia um único byte. Há algumas ressalvas nisso, é claro. Como é perfeitamente correto armazenar o número 100 em um disco como um valor de três bytes, mas isso normalmente só acontece quando um computador está tratando algum fluxo de texto como texto.

Em termos do meio de armazenamento real, em muitos casos, se o meio permitir que mais de um bit de dados seja armazenado, o fabricante tentará utilizá-lo. Por exemplo, melhorando o armazenamento através de armazenamento shingled (para discos) ou TLC (para SSD). Seja qual for o método subjacente, no entanto, o resultado final é que o fabricante fornecerá um número de armazenamento em bytes.


Obrigado Claris. Eu acho que seria seguro assumir que dígitos hexadecimais como FF também armazenariam como um byte completo, correto?
J. J.

1
"Se você tivesse que armazenar o número 100 em um computador, ele seria armazenado em binário, hex 0x64" - Não totalmente correto. Você só menciona apenas um formato numérico, um inteiro de byte único. Há também inteiro múltiplo, ponto fixo, ponto flutuante, BCD, ASCII e qualquer outro código possível (por exemplo, código Gray). O programa aplicativo (não o "fabricante" ) pode armazenar os dados em qualquer formato que escolher.
sawdust

3
Binário geralmente é considerado a representação nativa de dados na maioria dos processadores. Mas isso geralmente não é muito conveniente para o desenvolvedor ou outros propósitos. Hexadecimal, decimal ou octal são geralmente mais convenientes. Mas geralmente são apenas maneiras diferentes de representar a mesma coisa e têm pouco significado para armazenamento interno. O armazenamento interno será o que for considerado mais eficiente. Se isso será eficiência de armazenamento, eficiência de acesso ou algum comprometimento, é uma decisão que o desenvolvedor deve tomar.
LMiller7
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.