根据 IP 点表示法，使用以 10 为底的表示而非十六进制表示是标准的。
127.0.0.1 -> 7F.0.0.1
255.255.255.255 -> FF.FF.FF.FF
10.0.0.1 -> 0A.0.0.1
10.0.0.1/24 -> 0A.0.0.1/18
我在 RFC 中找不到任何关于为什么 IPv4 的约定是以 10 为基数的参考资料，但 MAC 和 IPV6 默认使用十六进制。
我们这样做有什么原因吗？还是纯粹是历史性的？
【问题讨论】：
标签： networking ip ipv4
十进制是事实上的标准； IPv4 地址的字符串格式从未正确标准化。几乎所有工具都只会采用十进制、点分四进制、符号，但这并不是普遍适用的；任何仍在使用inet_aton() 通用实现的工具都可能处理其他格式。
iputils 包中包含的ping 是一个有用的示例。取 google 的地址之一，尝试十进制、十六进制和八进制点分四：
ping -c1 216.58.195.238
ping -c1 0xd8.0x3a.0xc3.0xee
ping -c1 0330.072.0303.0356
这些都 ping 同一个地址，因为它们都代表相同的 32 位。
但它比这更进一步。您不必严格使用四个八位字节；在无类寻址和可变长度网络掩码出现之前，有类寻址曾经指定 8 位、16 位和 24 位网络前缀。其中一些内容仍然融入inet_aton()：
上面的地址，格式为8/8/16位：
ping -c1 216.58.50158
ping -c1 0330.072.0141756
ping -c1 0xd8.0x3a.0xc3ee
或者，格式化为 8/24 位：
ping -c1 216.3851246
ping -c1 0330.016541756
ping -c1 0xd8.0x3ac3ee
或者，忘记点，只输入 32 位：
ping -c1 3627729902
ping -c1 033016541756
ping -c1 0xd83ac3ee
但更好的是，您不必以相同的格式交出每个块：
ping -c1 0xd8.072.195.0xee
这一切都导致了一个合理的提醒，但是：inet_aton() 是一个旧的、旧的函数，并且无法理解 IPv6 地址是什么。如果您今天正在编写代码，您不会想要使用inet_aton()，您会想要使用inet_pton()，它可以同时处理这两种情况。我使用的inet_pton() 的实现更忠实于十进制点分四边形的事实标准 IPv4 地址表示。对于 IPv6，实际上确实有 an RFC on string representation，inet_pton() 遵循标准！
【讨论】：
inet_aton() 不在 POSIX 标准中，但通常由 C 库实现；恐怕我没有做过任何重要的 Windows 网络编码来确定，但文档似乎表明他们没有实现inet_aton()。他们确实建议使用inet_pton()，无论如何都是首选。