-1

Вы можете иметь 0-255 в шестнадцатеричном формате, хранить в 2 символа, так что он как бы сжимает данные и используется для всех видов вещей, включая цвет, IP и MAC-адреса.

Мой вопрос: почему они остановились на 16 битах (или почему это чаще всего используется)? В алфавите достаточно букв алфавита для 32 бит, что дает диапазон 0-65536, содержащийся в том же объеме пространства, потенциально позволяя получить 280 триллионов цветов, а не 16 миллионов. Если вы сделаете буквы чувствительными к регистру и добавите два символа, вы можете перейти к 64-битному формату, позволяя представить до 4,3 миллиарда значений двумя символами.


Некоторые примеры ситуаций, которые, я думаю, сработают:

IPv4 заканчивается. Я знаю, что v6 внедряется, но он очень длинный и его трудно запомнить. Возьмите адрес 192.168.0.1, он также может быть сохранен как C0.A8.0.1. Используя 64-битный шестнадцатеричный код, но сохраняя его максимум до 8 символов, вы можете получить 280 триллионов комбинаций вместо 4 миллиардов, и у нас не будет этой проблемы.

Как упомянуто выше, это также обеспечивает намного больший диапазон цветов. Формат фотографий RAW записывает 32 бита на цветной канал вместо 8, что приводит к огромному увеличению размера файла. Если значения RGB хранятся в шестнадцатеричном формате, размер файла не должен изменяться при увеличении диапазона цветов, поскольку он все равно будет храниться в пределах 6 бит на пиксель, но с более высоким базовым числом. Вместо этого он записывается в виде числовых значений с 96 битами на пиксель, что является очень ненужным увеличением на 1600%, оставляя фотографии более 20 МБ (и, согласно онлайн-калькулятору, 4K RAW-видео с 32-битным цветом может достигать 2,5 ГБ) в секунду).


Эта часть на самом деле не связана с вопросом, но некоторое время назад я написал сценарий, который может преобразовывать числа в различные базовые значения, начиная от двоичного до базового 88 (после которого заканчиваются символы), что показывает, что это легко возможно реализовать похожие вещи. В качестве примера, вот выход из 66000.
База 2: 11111111111110000
База 16: 101D0
База 32: 20EG
База 64: G7G
Код здесь, если кому-то интересно, у него все еще есть несколько ошибок, и я пробовал его только из Maya. Немного не по теме, но я также только что заметил, что нормальный гекс, похоже, на 20% меньше битов, чем исходное число, а база 88 - это почти 50% сокращение.


Последний вопрос: кто-нибудь пытался использовать мою идею хранения фотографий в шестнадцатеричном формате? Будет ли это работать, если вы используете 64-битный шестнадцатеричный код и сохраняете фотографии с данными, подобными [64; 1920; Bgh54D; NgDFF4; ...]? Если нет, я мог бы попытаться создать что-то, что может сделать это.

3 ответа3

9

Если я правильно читаю вопрос, вы говорите, что данные «сжимаются», когда вы используете большие базы, а на самом деле это не так.

Возьмите свой собственный пример: База 2: 11111111111110000 База 16: 101D0 База 32: 20EG База 64: G7G

Для этого мы использовали бы 101D0, потому что гекс является стандартным. Что бы произошло, если бы мы использовали обозначение base 64?

Ответ: по сути, ничего, так как вы все еще храните и обрабатываете данные в битах на вашем устройстве. Даже если вы скажете, что у вас G7G вместо 101D0, вы все равно храните и работаете с 11111111111110000 на своем устройстве. Представьте, что у вас есть номер 5. Если вы поместите это в двоичном виде, это будет 101. 101 имеет 3 цифры, а 5 имеет одну, и это не означает, что 5 является более сжатым, чем 101, так как вы все равно сохраните число как 0101 на вашем компьютере.

Просто чтобы не отставать от ваших примеров, IPv6 или MAC-адресов (для этого примера это одно и то же, строки из двух цифр, разделенных точками).

У нас в гексе 00:00:FF:01:01. Вот как вы бы регулярно это выражали. Это переводится в двоичном виде как 0000 0000 0000 0000 1111 1111 0000 0001 0000 0001 (Вы, вероятно, начинаете понимать, почему мы сейчас используем гекс). Это легко, потому что, поскольку 16 = 2 ^ 4, вы можете преобразовать одну шестнадцатеричную цифру в 4 двоичные цифры и просто сложить результат вместе, чтобы получить действительную двоичную строку. В вашей базовой системе 64, если бы у нас было что-то вроде GG:HH:01:02:03, каждая буква была бы переведена в 6 бит.

В чем проблема с этим тогда? Факт, что компьютеры работают внутренне с полномочиями двух. Они действительно не заботятся о нотации, которую вы используете. В регистрах ЦП, памяти и других устройствах вы никогда не увидите данные, разделенные на группы по 6 бит.

TL; DR: Шестнадцатеричная система - это просто нотация, которая помогает людям легче видеть двоичные объекты, поскольку байт может быть выражен в виде двух символов (0-F), то, что хранится и обрабатывается на компьютере, одинаково, независимо от того, какую нотацию вы используете прочитай это.

3

Шестнадцатеричный буквально означает 16. ;)

Но, кроме странного ответа, шестнадцатеричная (или любая другая базовая система нумерации степени 2) - это просто более компактный формат для представления двоичных данных. На самом низком уровне значения по-прежнему численно представлены битами. На самом низком уровне эти биты разбиты на куски, с которыми аппаратная архитектура может легко справиться.

Имейте в виду, что шестнадцатеричные числа не представлены в виде символов 0-9 и af - они буквально хранятся в виде битов. Как вы предлагаете, каждая "цифра" не кодируется как 8-битный символ 0–255, где используются только первые 16 значений в системе.

Давайте сравним сравнение представлений base 2 и base 64 в вашем примере.

base2: 11111111111110000 --> 17 "digits" with 1 bit per digit = 17 bits
base64: G7G --> need 3 "digits" with 6 bits per digit = 18 bits

Теперь рассмотрим кодировку base64, где каждая "цифра" фактически представлена 8-битным символом. У вас все еще есть G7G, но теперь каждая "цифра" требует 8 бит.

G7G --> 3 "digits" with 8 bits per digit --> 24 bits

Даже в этом упрощенном примере, если вы используете base64 для представления всего, у вас может быть намного больше свободного пространства (потраченного впустую), чем в системе нумерации, которая выделяет пространство меньшими порциями.

Как я уже сказал, предыдущий пример является упрощением и предполагает, что вы имеете дело только с беззнаковыми числами (т.е. без отрицательных чисел). В действительности, данные будут храниться в "словах", размер которых может варьироваться в зависимости от архитектуры оборудования. Если у вас есть 8-битное слово, вы должны назначить значения в 8-битных блоках, поэтому 17-битное значение теперь требует 24 бита для хранения.

Таким образом, хотя использовать обычную систему нумерации со степенью двойки тривиально, как вы предлагаете, это не является обычным явлением. Это может быть потому, что популярные современные компьютерные архитектуры возникли из 16-битных архитектур, где шестнадцатеричный был буквально родным языком аппаратного обеспечения.

2

Шестнадцатеричный код - довольно хороший компромисс между двоичным и десятичным.

  • Это легко преобразовать в двоичный файл, просто посмотрев на него.

  • Легко читать, писать и общаться устно, если это необходимо. Представьте себе, что вы пытаетесь сообщить кому-то строку в кодировке base64 по телефону.

  • В одноплатных компьютерах 70-х и 80-х годов использовались 7-сегментные светодиоды, и никакой другой механизм отображения из коробки не использовался. К счастью, A, B, C, D, E и F могут быть представлены в одном из них.

Конечно, когда мы говорим о 64-битных, 128-битных и более больших количествах, или таких вещах, как хэши, не так-то просто общаться в шестнадцатеричном, десятичном или чем-то еще. Для меня "расцвет" шестнадцатеричного был, когда 8- и 16-разрядные процессоры были обычным явлением, а также когда низкоуровневое программирование было более распространенным явлением, поскольку это было более необходимо. Я могу ошибаться.

Я не уверен, что шестнадцатеричный используется в общем, за исключением выражения адреса указателей в C/C++. Я полагаю, что шестнадцатеричный код используется здесь по привычке или традиции, а также стал сигналом того, что что-то является "необработанным двоичным" значением, а не каким-либо "типом".

Кто-нибудь пробовал мою идею хранить фотографии в шестнадцатеричном формате?

Любой файл, независимо от его типа или содержимого, представляет собой большую часть байтов. Это уже в двоичном виде. Hex - это (очень минимально) дружественный взгляд на это.

Если вы хотите посмотреть на байты файла в шестнадцатеричном формате, есть множество шестнадцатеричных редакторов и программ просмотра, которые это сделают.

Если вы предлагаете сохранить фотографию в виде текстового файла, содержащего список шестнадцатеричных чисел, я думаю, вы могли бы сделать это, если хотите, но она будет больше и медленнее, чем исходный файл.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .