根据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使用十六进制。
我们这样做是有原因的吗？还是自然界中纯粹是历史性的？
十进制是事实上的标准；从未正确标准化IPv4地址的字符串格式。几乎所有工具都只采用十进制，点分四进制表示法，但这并不是普遍适用的。仍使用通用实现的任何工具inet_aton()都可能处理替代格式。
pingiputils软件包中包含的一个有用示例。使用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，实际上确实有对字符串表示的RFC，inet_pton()遵循的标准！
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句