你可以有 0-255 的十六进制，存储在 2 个字符中，所以它可以压缩数据，并用于各种事物，包括颜色、IP 和 MAC 地址。
我的问题是为什么他们停在 16 位（或者为什么最常用）？字母表中有足够的 32 位字母，这将在相同的空间量内提供 0-65536 的范围，可能允许 280 万亿种颜色，而只有 1600 万种。如果让字母区分大小写并添加两个符号，则可以使用 64 位，这两个字符最多可以表示 43 亿个值。
我认为这会起作用的一些情况示例：
IPv4 快用完了。我知道 v6 正在推出，但它很长，很难记住。取192.168.0.1地址，也可以存为C0.A8.0.1。使用 64 位十六进制但仍保持最多 8 个字符，您可以拥有 280 万亿个组合而不是 40 亿个组合，我们不会有这个问题。
如上所述，它还提供了更大范围的颜色。RAW 照片格式以每个颜色通道 32 位而不是 8 位记录，缺点是文件大小会大幅增加。如果 RGB 值以十六进制存储，则在增加颜色范围时文件的大小应该没有变化，因为它仍会以每像素 6 位的方式存储，但基数更高。相反，它被记录为每像素 96 位的数值，这是一个非常不必要的增加 1600%，使照片超过 20MB（根据在线计算器，32 位颜色的 4K RAW 视频可能高达 2.5GB每秒）。
这部分实际上与问题无关，但我不久前编写了一个脚本，可以将数字转换为不同的基值，范围从二进制到基数 88（之后用完符号），这表明它很容易实现来实施类似的事情。例如，这里是 66000 的输出。
Base 2: 11111111111110000
Base 16: 101D0
Base 32: 20EG
Base 64: G7G如果有人感兴趣，
代码在这里，但它仍然有一些错误，我只尝试过玛雅之内。有点离题，但我也刚刚注意到，正常的十六进制似乎比原始数字少了 20% 左右，而基数 88 几乎减少了 50%。
最后一个问题：有没有人尝试过我将照片存储为十六进制的想法？如果您使用 64 位十六进制并使用 [64;1920;Bgh54D;NgDFF4;...] 之类的数据存储照片，它是否可能有效？如果没有，我可能会尝试创建一些可以做到这一点的东西。
小智 11
如果我正确地阅读了这个问题，那么您是在说当您使用更大的基数时数据会“缩小”，而实际上并没有。
以您自己的示例为例：基数 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，您可以将 1 个十六进制数字转换为 4 个二进制数字，然后将结果放在一起以获得实际的二进制字符串。在您的 base 64 系统中，如果我们有类似 GG:HH:01:02:03 的内容，每个字母将转换为 6 位。
这有什么问题呢？计算机在内部以 2 的幂工作的事实。他们并不真正关心您使用的符号。在 CPU 寄存器、内存和其他设备中，您永远不会看到数据被分成 6 位一组。
TL;DR：十六进制只是一种符号，可以帮助我们人类更轻松地查看二进制内容，因为一个字节可以表示为两个字符 (0-F)，无论您使用哪种符号，计算机中存储和处理的内容都是相同的阅读。
| 归档时间： |
|
| 查看次数： |
7322 次 |
| 最近记录： |