Вы можете иметь 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; ...]? Если нет, я мог бы попытаться создать что-то, что может сделать это.