--libcurl

原文 ↗ Hacker News 讨论 ↗

Curl 长期以来的 `--libcurl` 选项可以为任意 curl 命令生成等价的 C 代码，如今因其在命令行 HTTP 调用与嵌入式库使用之间搭起了强大的桥梁而再次受到关注。评论者指出，这让 libcurl 的 API 更容易学习，也支持类似 Office 宏和浏览器“Copy as cURL”的“记录并自定义”工作流，并且实际上把 curl 变成了一个可被工具翻译成多种语言的中间表示。也有人将这类确定性代码生成器与基于 LLM 的方案进行对比，讨论更具交互性、可反射的系统和 shell 的更广泛想法，并提到像 curlconverter 和 Hurl 这样建立在 curl 普及度之上的相关工具。

--libcurl 的作用及其受欢迎的原因

  • 生成可编译的 C 代码，使用 libcurl，且与给定的 curl 命令保持一致。
  • 被视为：
    • 样板代码生成器，这样你就不必学习 libcurl 的每一个选项。
    • 该库的“活”文档：运行一个命令，就能准确看到需要调用哪些 API。
    • 从 CLI 用法平滑过渡到在应用程序中嵌入 libcurl 的路径。
  • 示例工作流：curl … --libcurl file.c，然后用 -lcurl 编译，或者通过 make。

模式：“记录操作，显示代码”

  • 与 Office VBA 宏及其他允许你执行操作然后检查生成代码的工具相比。
  • 提到的类似想法包括：
    • Open XML SDK 的 Office 文档代码浏览工具。
    • ASM 的 ASMifier，生成用于操作字节码的 Java 代码。
  • 希望在 GUI 系统工具中也能看到这种模式（Gnome 设置、防火墙/网络配置），它们可以输出等价的 CLI/脚本命令。

将 cURL 作为中间表示

  • 浏览器开发者工具中的“Copy as cURL”被大量使用，然后转换为：
    • Python（例如 requests）、JavaScript、Go、R（httr2）、Postman collections 等。
  • cURL 实际上是 HTTP 请求的通用“IR”：
    • 在各类工具之间，作为导出和导入格式被广泛支持。
    • 比原始 HTTP 更简洁；隐藏了无关的头部和默认值。
  • 有人指出“Copy as cURL”常常包含不必要的头部。
  • 一位评论者认为 HTTP 能做 cURL 做不到的事情（例如 HTTP/1.1 管线化）。

LLM 与确定性代码生成器

  • 有玩笑式说法认为 LLM 让 --libcurl 过时了。
  • 强有力的反驳是：像 --libcurl 以及其他代码生成工具这样的确定性生成器：
    • 可预测、经过实战检验、可离线使用，而且资源占用低。
    • 不涉及数据收集和训练伦理方面的担忧。
  • 也有人仍然将二者结合使用（例如用 AI 把生成的 C 转成 Python）。

批评、局限与安全性

  • 有报告称某些标志（例如 --upload-file）无法很好地转换。
  • 对“标志太多”和功能膨胀的担忧；有人建议单独提供一个 curl-as-libcurl 二进制。
  • 担心“互联网上更多不安全的 C 代码”，但反驳意见是：
    • 信任 libcurl 的成熟度。
    • 生成的代码很简单；真正的风险在于用户后续添加的逻辑。

相关工具与生态

  • 提到：
    • Hurl：一个基于 libcurl 的 CLI 测试工具，支持链式调用和断言。
    • 多种 curl→代码转换器（网页和 CLI）以及它们的隐私影响。
    • 一些反思认为，之所以需要代码生成，本身就说明了 C 相较于 Python/Node 等语言的冗长。