IP地址的奇怪的无点十进制表示法......它是如何工作的?

bee*_*eks 88 firefox ipv4 notation

今天早些时候,我以为我的剪贴板中有一个 URL,但实际上我从电子表格中复制了四个 9 位整数,它们是来自专有系统的标识号。与手头的任务完全无关。我将它粘贴到 Firefox 中,惊讶地发现它实际上加载了一个页面。我以前见过IPv4地址的无点十进制表示法,但这个长数字要大得多。

714687644714805209715128610715964400(在前面贴一个HTTP://)

这是如何运作的?我在 Internet 上找到的所有十进制 -> IPv4 转换器都将其视为无效输入。如果我获取它实际加载的 IPv4 地址,并执行相同的计算将其转换为无点十进制,我得到的数字要小得多。

我读过ping可以接受双字并进行一些转换,但它无法将此数字转换为 IP 地址。IPv6是不可能的,因为该主机没有 IPv6 连接。

这是一种什么样的疯狂?我和我的同事都难住了。

编辑:它现在重新上线。

pea*_*ter 92

这是一个非常有趣的问题,我花了一点时间才弄明白。简短的回答是数字的最后 32 位是3660944368(十进制,可以通过 找到714687644714805209715128610715964400 mod 2^32

这是 IPv4 地址218.53.147.240的十进制值,可以通过将其转换为 base-256 来找到,3660944368 = 218*(256^3)+53*(256^2)+147*(256)+240类似于以十进制(base-10)写出一个数字。例如234 = 2*10^2+ 3*10 + 4

正如@chritohnide 指出的那样,点分 IPv4 地址的每一部分称为一个八位字节,因为它代表 8 个二进制数字。还值得注意的是,IPv4 地址的各种格式(例如点分十进制或纯十进制)只是表示 32 位二进制数的不同方式以获取收益。

由于 IPv4 地址是 32 位数字,因此仅使用数字的最后 32 位来解析地址。为什么这是真的并不那么明显。正如其他人指出的那样,完整数字与十进制的 IPv6 地址非常相似,但不是有效地址。

查看Teredo 规范(参见4. Teredo Addresses),Client IPv4 占用 IPv6 地址的最后 32 位,但数字的前缀与 Teredo 规范不匹配(另请参见wikipedia)。

  • 很好的答案。提及点分 IPv4 地址的每一部分都称为 *八位字节* 可能也很有用,因为它是 8 位二进制数的十进制表示(4 个八位字节 = 4 x 8 位 = 32 位 IPv4 地址)并且十进制版本实际上只是为了我们的利益。 (12认同)
  • @Izkata:不太可能,因为该地址将位于 IPv6 地址空间的未分配和保留部分。 (5认同)
  • 你确定这不是 IPv6 十进制表示法?它成功转换为`0089:a4d2:471b:45ef:77ed:c70f:da35:93f0` (4认同)
  • 该数字(以 ASCII 表示)可能只是通过 C stdlib 字符串之一运行到 int 函数以转换为 32 位 ipv4 地址。在 C stdlib 的大多数实现中,这些转换将自动进行模 2^<所需整数大小>。在这种情况下,结果正是观察到的行为。 (3认同)
  • 值得注意的是,这可能是 Firefox 的 URL 解析器的一个怪癖。它似乎认识到它是一个数字而不是一个 URL 并尝试将其解析为 32 位无点 IP 地址(解析后的整数以 32 位模结束,它并没有真正对输入进行任何错误检查)。例如,Chrome 不会显示此行为。实际上可能值得将其报告为 Firefox 中的一个微不足道的错误。 (3认同)
  • 事实上:[在 Firefox 中忽略这些类型的地址和其他地址的请求](https://bugzilla.mozilla.org/show_bug.cgi?id=67730) 几年前就已经提交了,但似乎从未提交过搦。 (3认同)

归档时间:

查看次数:

6807 次

最近记录:

11 年,5 月 前