问题标签 [inet-ntop]

我正在尝试构建一个工具来根据域名收集有关 IP 地址的信息。我一直在使用 inet_ntop 来实现这一点，并且通常对于大多数域都运行良好。当我在 google.com 或 amazon.com 等网站上试用时，似乎会重复打印相同的 IP 地址。

示例输出： 主机：google.com IPv4：54.239.17.6 IPv4：54.239.17.6 IPv4：54.239.17.6 IPv4：54.239.17.6 IPv4：54.239.17.6 IPv4：54.239.17.6 ....

我想知道是否有人遇到过这种情况，是我做错了什么还是与网站的配置方式有关。

我想到的一个想法是用以前的 IP 检查当前 IP 并打破循环。不过，这似乎是一个相当老套的解决方案。

我正在使用新的Delphi Tokyo 10.2.2，就我而言，我使用的是在运行时加载的包。

即使做一个简单的例子并请求 EXE 仅加载 RTL 单元也会发生运行时错误，仅在Windows XP操作系统上：

无法在动态链接库WS2_32.dll中找到过程入口点inet_ntop。

使用Delphi Tokyo 10.2.1不会发生问题。

任何想法？

我在这里不知所措。我已经使用二进制（16）列中的inet_pton将IP地址插入到MySql表中，当我尝试使用inet_ntop检索它时，我得到了一个奇怪的结果

它显示：23a6::

它应该显示：35.166.0.0

数据库中的十六进制值为 0x23a600000000000000000000000000000

似乎它应该工作。我哪里错了？

我需要获取 api.openweathermap.org 的 IP 地址。

这是我尝试过的：

输出是一个随机字符串，比如“��jk5”，应该是82.196.7.246

我正在查看inet_ntop文档。通常，字符串生成器操作会C返回指向字符串末尾的指针或指示写入字符串长度的整数。

状态的文档inet_ntop相当含糊：

这里有两个问题：

1. 空字符串终止：不清楚是否需要在整个内存分配中添加空字符串分隔符，inet_ntop在以 3 或更多顺序编译时打印在哪里

2. 我不知道函数的输出是返回指向最后写入字符的指针，还是第一个写入字符的指针。

返回什么inet_ntop？

我有问题。我有需要将域名转换为 IP 的代码。为此，我正在使用函数 getaddrinfo()。但似乎，当我调用另一个函数（GETADDRINFO() 之后）时，我的程序会失败（getaddrinfo 返回错误并生成分段错误）。我发现，这个问题是在调用 getaddrinfo() 之后调用函数 inet_ntop()。但我不知道为什么会发生这种奇怪的行为......这是我的代码：

如果你删除

inet_ntop (AF_INET, new_ai->ai_addr->sa_data, addrstr, DOMAIN_NAME_MAX_LENGTH);

它不会给出段错误。但是为什么给它呢？？请帮忙，谢谢！

（PS：我尽量简化我的代码。这就是它没有产生任何有用结果的原因）

请帮我！我需要将域名（例如 google.com）翻译（或转换）为 IP 地址。为此，我在互联网上找到了代码，它们运行良好，但我不明白为什么函数 inet_ntop() 被调用了两次。请帮我。这是代码：

我的问题是 - 为什么函数 inet_ntop() 使用了两次？我想，第一个电话会给你 IP 地址……但是为什么你需要第二个电话呢？谢谢！

传递unsigned char数组inet_ntop()调用是否有效？上面的代码有效，但手册页说 API 在第二个参数中需要网络地址结构。

阅读关于如何以最佳方式表示 IPv6 地址的 RFC 建议 ( RFC 5952 )，我尝试在 C++ 中实现一个函数，该函数将字节数组转换为适当的文本表示，即std::string.

为了检查我的代码是否正确，我将我的结果与inet_ntop( #include <arpa/inet.h>) 返回的结果进行比较。请注意，我实际上使用的是 Windows 等效的#include <ws2tcpip.h>.

在大多数情况下，我的函数具有相同的行为，并且我完全理解基本规则（省略前导零，通过用“::”替换它来压缩最长的零块，等等）。

但有趣的部分如下：据我了解，对于一些特殊地址（IPv4 映射、IPv4 兼容和 IPv4 转换的 IPv6 地址，请参阅RFC 2765），建议以其他十六进制表示法表示IPv4 地址常用的点分十进制表示法的最后 4 个字节。

例如::ffff:0:168.0.0.1，::ffff:168.0.0.1和::168.0.0.1在其推荐的文本表示中都是有效的 IPv6 地址，并且inet_ntop也得出了该结论。

现在我的问题0:0:0:0:0:ffff:0.0.1.1是：根据 ，IPv6 地址inet_ntop缩短为::ffff:0:101，再次选择十六进制表示。这种行为的原因是什么？我认为因为我们在这里有一个特殊的地址前缀，所以无论最后 4 字节块的前两个字节是否为零，都将使用点分十进制表示法，因此将其写为::ffff:0.0.1.1. 我是误解了 RFC 建议还是inet_ntop在这方面不一致？我观察到这inet_ntop在我的所有其他测试用例中都非常符合 RFC。

我希望你能帮助我。

编辑：经过更多测试后，似乎inet_ntop确实总是选择十六进制表示法而不是点分十进制表示法，即使 IPv6 地址实际上只是那些特殊的嵌入式 IPv4 地址中的一些，如果最后 4 的前两个字节字节块为零。