cURL 转代码

如何使用cURL 转代码

关于cURL 转代码的常见问题

cURL 转代码会上传我的请求内容吗？

不会上传。分词、解析、体检与九种写法的生成全部在你的浏览器本地完成，你粘进来的地址、Cookie 与 Token 不会发送到任何服务器，刷新页面即清空，只有目标语言、缩进这类展示偏好会记在本机。也正因为如此，本工具没有也不会有「试跑一下」按钮：要真的把请求发出去就得由服务器代理转发，那等于把你的凭据送到我们这里。（站点自身仅有匿名访问量统计，与你粘的内容无关。）

手机上能用 cURL 转代码工具吗？

可以，也不用装任何 App 或插件。cURL 转代码是纯网页实现，手机、平板、电脑浏览器打开即用。九个目标语言的标签条和代码区都可以横向滚动，请求结构在窄屏上会改成上下堆叠，复制按钮走系统剪贴板，转完直接粘到你的编辑器或聊天窗口里。剪贴板不可用时会提示你手动选中代码，不会静默失败。

Chrome 里复制的 curl 命令怎么转成 fetch？

在 Chrome 开发者工具的 Network 面板里右键那条请求，选 Copy → Copy as cURL，把结果粘进本页的输入框，再切到 JavaScript fetch 标签就能拿到代码。要注意从浏览器复制出来的命令里带着一大堆 Cookie、Origin、Sec- 开头的头，这些在 fetch 里是设不上的，本工具会逐条标出来但不替你删；Cookie 想带上得改用 credentials 选项，并且跨域还要服务端放行。

curl 转 Python 用 requests 还是 httpx？

curl 转 Python 代码时两个标签都给，按项目来选：requests 用得更广、同步为主；httpx 支持 async 且接口与 requests 很像。真正要留神的是重定向默认值——requests 默认跟随、httpx 默认不跟随，正好相反。curl 不加 -L 时是不跟随的，所以本工具在 requests 那边会显式写出 allow_redirects=False，在 httpx 那边则什么都不写；反过来加了 -L 才会给 httpx 写 follow_redirects=True。

curl -X POST 转代码怎么写？

多数时候你不用写 -X。curl 只要带了 -d、--data-raw 或 -F 就默认发 POST，本工具按同一规则推断方法，并在体检里注明是因为带请求体才按 POST 生成；带 -I 按 HEAD，带 -T 按 PUT，都不带就是 GET。显式写了 -X 就以它为准，-X 与 -I 同时出现时也听 -X 的。有个坑：-X GET 配 -d 时 curl 照样把请求体发出去，本工具也照原样保留，但浏览器的 fetch 不允许 GET 带 body，这种命令转成 fetch 后要自己改。

curl -m 超时转代码后各语言怎么写？

按各语言自己的单位换算，不做四舍五入以外的改动。以 curl -m 2.5 为例：Python requests 与 httpx 都是 timeout=2.5，axios 与 Node.js 是 timeout: 2500，Go 是 2500 * time.Millisecond，PHP 是 CURLOPT_TIMEOUT_MS => 2500，Java 是 Duration.ofMillis(2500)，所以半秒不会被截掉。fetch 没有超时参数，本工具补的是 AbortSignal.timeout(2500)。另外 -m 管整体、--connect-timeout 只管建连，在 PHP 与 Java 里是两个不同的参数，别混用。

curl -d 和 --data-raw 转出来的代码一样吗？

不一定一样。-d 会把值里的换行剥掉，而且值以 @ 开头时会被当成文件名去读；--data-raw 不解释 @，一律当字面量；--data-binary 认 @ 但不剥换行；--data-urlencode 会先做 URL 编码。所以同样一段带换行的 JSON，-d 转出来的请求体是没有换行的那一版。多个 -d 会按 curl 的语义用 & 连起来。浏览器复制出来的命令用的都是 --data-raw，粘过来最省心。

Windows curl 单引号报错怎么办？

这是最常见的一类问题：macOS 与 Linux 上复制出来的 curl 用单引号包裹参数，而 Windows 命令行根本不认单引号，会把引号连同内容一起当作地址的一部分，于是报错或者请求发歪。两个办法：一是在开发者工具里改选 Copy as cURL (cmd)，二是把 bash 版粘进本页，切到「cURL 命令规范化」标签并选 Windows cmd 风格，直接拿到一条能在 cmd 里跑的等价命令。

curl 转 fetch 之后为什么跨域或 Cookie 没带上？

curl 不受同源策略约束，浏览器里的 fetch 受。命令在终端里跑得通，不代表同一个请求在网页里也能发出去：跨域要服务端返回对应的 CORS 响应头才行，这不是转换工具能替你解决的。Cookie 则是另一回事——它由浏览器接管，写在 headers 里会被静默丢弃，同源请求要改用 credentials 选项让浏览器自己带上。本页的「浏览器里设不上的请求头」表把这些逐条列了出来。

curl -u 的用户名密码会明文写进代码吗？

默认不会。本工具默认把 Cookie、Authorization、X-Api-Key 这类凭据以及 -u 的密码换成环境变量读法，各语言分别是 process.env、os.environ、os.Getenv、getenv 与 System.getenv，界面上会明确列出替换了哪几处。想看原值就取消勾选「凭据换成环境变量占位」。另外 Basic 认证优先用目标语言自带的 auth 参数，只有 fetch、Go、Java 这类没有现成参数的才会现算 Base64，按 UTF-8 编码，中文用户名密码也不会出错——不过占位开着时连 Base64 都不算，这三种写法改成从 BASIC_AUTH_PASSWORD_BASIC 读整串 Basic 值。

cURL 转代码支持 -F 上传文件吗？

支持解析，但只能给到读文件的骨架。curl -F 上传文件的三种形态都认：name=value 是字面值、name=@path 是上传文件、用小于号引导的那种是取文件内容当字段值，;type= 与 ;filename= 也会解析出来。要说清楚的是，本工具跑在你的浏览器里，读不到你磁盘上的文件，所以生成的是「怎么读这个文件」的代码而不是文件内容；multipart 的分隔串也不复刻，交给目标语言的库自己生成。

curl -k 和 curl --compressed 转代码后去哪了？

-k 是跳过证书校验：Python 那边对应 verify=False、PHP 对应 CURLOPT_SSL_VERIFYPEER、Go 走 InsecureSkipVerify，而浏览器 fetch 压根没有对应物，只能给一条说明。curl --compressed 是请求压缩响应并自动解压，多数客户端默认就会做，所以本工具不会手写 Accept-Encoding——在 Go 里手动设这个头反而会关掉自动解压。两者都会在体检里各留一条提示，不静默丢掉。

cURL 转代码支持哪些语言？能转 Go 和 PHP 吗？

一共九种写法：JavaScript fetch、axios、Node.js 原生 https、Python requests、Python httpx、Go net/http、PHP cURL、Java HttpClient，外加一个 cURL 命令规范化（可切三种引号风格）。Go 和 PHP 都在其中。九个标签渲染的是同一份请求模型，不会出现某个标签少一个请求头的情况；版本口径分别标在每种写法旁边，数据表复核于 2026-08-30。

PowerShell curl 转代码支持吗？

不支持，而且是刻意不支持。Invoke-WebRequest 的参数模型与 curl 差异很大，硬猜出来的代码会错得很隐蔽——看着像对的，实际把请求体或请求头弄丢了。所以识别到它时本工具只给一句指引：回开发者工具里改选 Copy as cURL (bash) 再粘过来。PowerShell 里用 curl.exe 写的真 curl 命令是支持的，反引号续行也认。

curl 命令转换的九种目标写法一览

本工具支持的九种目标写法是：JavaScript fetch、axios、Node.js 原生 https、Python requests、Python httpx、Go net/http、PHP cURL、Java HttpClient、cURL 命令规范化。

这件事在中文里有好几种叫法：curl 转 fetch、curl 转 python、curl 转 go、curl 转 php、curl 转 java，说的都是同一件事——把一条 curl 命令翻译成某种语言里等价的 HTTP 请求代码；英文站点上的 curl converter、curl to fetch、curl to python、curl to axios、curl to go 找的也是这类工具。cURL 转代码在线就能用，不必装插件、不必注册。下表是这九种写法各自的版本口径与关键映射，数据取自本站数据表，页面不手写第二份。

九个标签渲染的是同一份请求模型：解析只做一次，切标签只重渲染，不会出现某个标签少一个请求头的情况。生成的是等价的常见写法，不是逐位等价——连接复用、cookie jar、重试策略、客户端证书这些在各语言里没有一一对应，缺的一律列进说明，不静默丢。

三种「复制为 cURL」写法差在哪

Chrome 复制为 curl 时其实有三个下拉选项，copy as curl 出来的东西在 macOS、Windows cmd 与 PowerShell 下形态完全不同。把 bash 版直接粘进 cmd，就是 Windows curl 单引号报错的根源：cmd 不认单引号，会把引号和内容一起当成地址。本工具会自动识别写法并在界面上写明「已按某某写法解析」，判错了也能手动切。

bash 版还会把非 ASCII 字符写成 $'\xNN' 的字节转义（例如中文会变成三个 \x 开头的字节），本工具按 UTF-8 拼回原文；遇到不是合法 UTF-8 的字节序列时原样保留并给出说明，不猜测。

重定向与超时默认值对照表

这是本工具最要紧的一条正确性：curl 不加 -L 是不跟随重定向的，而各语言的默认值五花八门。不显式补齐差异，转出来的代码就和原命令行为不一样，而且不会报错——它会安静地跟到最终地址，你拿到的是另一个响应、另一个状态码。

curl -L 重定向本身只是一个开关，麻烦的是各语言默认值不一致。本工具的做法是只在默认值与原命令相反时才补一行开关：默认跟随的目标遇上没有 -L 的命令，就显式关掉；默认本来就不跟随的（比如 Node.js 原生 https、PHP cURL），则写一条注释说明为什么这里什么都不用写——省得你以为工具漏了。curl -m 超时要当心的是单位：-m 允许小数秒，Python 用秒、axios 与 Node.js 用毫秒、Go 与 Java 用 Duration、PHP 用毫秒，本工具按各自单位换算后写进代码。

浏览器里设不上的请求头清单

从开发者工具复制出来的命令必然带着一堆浏览器自己加的头。它们在 fetch 里是写不进去的：规范把这些列为受浏览器接管的请求头，写了会被静默丢弃。本工具照旧把它们输出出来（删不删是你的决定），但会逐条标出。curl 转 fetch 跨域前先看这一条：能不能跨域取决于服务端的 CORS 响应头，不是改请求头能解决的。

User-Agent 是否可改随浏览器与版本而定，本工具照旧输出，不替你断言它一定生效或一定被丢弃。

curl 常用选项速查：-d、-H、-u 是什么意思

下表是本工具做 curl 命令解析时真正认识的选项，页面和解析器读的是同一张表，不存在「表里写着支持、实际没解析」的情况。另有 23 个认识但没有通用对应物的选项（代理、客户端证书、重试、HTTP 版本等），它们不会被静默吞掉，而是集中列进转换体检。

转换体检覆盖的 28 条规则

转换体检是生成代码的同时顺带跑的一遍静态检查：按下表 28 条规则，把「curl 能做而目标语言做不到」以及「两边默认值不一样」的地方逐条标出来，分阻断生成、注意、提示三级。它只解释差异、给出改法，不替你改写命令，也不判断这条请求能不能跑通。

全部通过时界面显示的是「未发现常见问题」，而不是一句「和 curl 一模一样」的保证——体检只覆盖上表这些已知差异，写法正确与请求能不能跑通是两回事。