根据IP点表示法，使用基数10表示而不是十六进制是标准的。
dojo我在RFC中找不到关于为什么IPv4的约定是基数为10的任何引用，但MAC和IPV6默认使用Hex。
我们这样做是有原因的吗？或者它纯粹是历史性的？
答案 0 :(得分：2)
十进制是事实上的标准; IPv4地址的字符串格式从未正确标准化。几乎所有工具都只采用十进制，点分四元组，符号，但这并非普遍适用;任何仍使用inet_aton()的常见实现的工具都可能处理其他格式。
ping是一个有用的例子。取一个谷歌的地址，并尝试十进制，十六进制和八进制点四边形：
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地址表示。对于实际拥有an RFC on string representation的IPv6，inet_pton()遵循标准！
答案 1 :(得分：0)