不久前，我给站点 nytpu.com 加了可在终端浏览的 curl 版本，运行 curl nytpu.com/gemlog/2026-03-18 或 curl nytpu.com 即可。cmd.exe 默认禁用 ANSI 转义序列，Powershell 又把 curl 别名指向 Invoke-WebRequest，因此视窗（Windows）用户需用 curl.exe。我只在联邦宇宙（Fediverse）简单提过，以为不言自明；但有几个人问做法，才决定写帖说明，虽晚了约七个月。点子来自 trinkey 的 curl trinkey.com 和 strongsand 的 curl proot.party，并非我想出；做法虽差别不小，创意仍归他们。更新：截至 2026-10-14，两人的 curl 版本均已失效。

2026 年 3 月 18 日（更新于 2026 年 10 月 14 日）

很久以前，我给自己的站点加了一个好玩的 curl 版本，专门用来在终端里查看。试试运行：curl nytpu.com/gemlog/2026-03-18，或者 curl nytpu.com。

（抱歉 Windows 用户：cmd.exe 默认禁用 ANSI 转义码；而在 PowerShell 里必须用 curl.exe 而不是 curl，因为 PowerShell 莫名其妙把 curl 别名成了 Invoke-WebRequest。这两点都不能怪我。）

我在 Fediverse 上稍微提过，但没多解释，因为觉得它挺不言自明的。后来有好几个人问我怎么做到的，所以我决定还是写一篇帖子讲讲——虽然晚了大概七个月。

得说明一下，这个点子来自 trinkey 的 curl trinkey.com 和 strongsand 的 curl proot.party，并不是我自己想出来的。虽然我的实现方式和他们差别不小，但这个很酷的点子还是要归功于他们。（更新：不幸的是，截至 2026 年 10 月 14 日，他们俩的 curl 版本都已经不能用了。）

先说更有意思的部分：实际生成要发给客户端的、带 ANSI 标记的文件。我的索引页和关于页完全是手写的。

我知道 trinkey 和 strongsand 大概是靠 ratatui 库（或类似工具）实时生成它们的 curl 页面，那样可能更省事；但对我来说手写反而更快捷。

我把主转义码——ESC[，也就是 \x1b[——存进 Vim 寄存器，需要时方便粘贴；同时打开维基百科的主要图形码页面查具体的转义码。差不多就是这样。我试验出一套自己喜欢的、统一的样式，并且在制作带标记的 curl 页面时参考了我页面的 Gopher 版本。

我的版本有一个明显的不同之处：它给整个博客都做了 curl 版本，而不只是一两个页面。这完全是撞上了一个方便的巧合：四年多以前，我在自己写博客用的自定义标记语言 Gemroff 里实现了输出带 ANSI 标记的纯文本。最初只是为了写的时候能在终端里方便地预览草稿；但把它接进我的静态站点生成器后，几乎没费什么事就立刻生成了 Curl 版本。

另外，我确实手动写了一个博客文章的包装模板，以及一个列出文章的索引页模板；但再加上静态站点生成器里的几行代码，就把它接通了。

这也正是很难说这件事“很容易”的主要原因！它对我容易，只是因为我自己用了完全自定义的标记语言和静态站点生成器，而且几年前正好做对了设计选择——比如我的 SSG 本来就支持多种模块化输出格式，而不是像其他 SSG 那样只输出 HTML，因为我要把站点同时放在 HTTP、Gemini 和 Gopher 上。

不过，就算只做几个手写页面来玩，也完全是可以接受的建站方式，因为它只是个有趣的噱头，没人会真的用它浏览超过几分钟。

最后一步，是把站点的 Curl 版本呈现给任何 user agent 里包含 curl 的请求。对我来说，这只是改了几行 Nginx 配置；用别的服务器大概也一样简单。我想要的主要功能是一个覆盖用的响应头（X-Original: true），这样随便跑一下 curl 的人还是能拿到未改动的 HTTP 响应；同时我希望所有东西仍然以静态方式提供。

嗯，真的就这些了！就像我说的，刚弄好时我觉得它相当不言自明；但它和人们平时用 Web 服务器或 ANSI 转义码做事的方式几乎不搭边，所以我也理解大家为什么会好奇或困惑。要是能看到更多站点玩这个小把戏，应该挺有意思的！

讨论气氛轻松、怀旧且偏正面，多数人觉得能用 curl 直接读到纯文本或 ANSI 版网页很有趣，并顺势分享自己的类似项目。分歧主轴不在“好不好玩”，而在实现方式该用标准 HTTP Accept 内容协商，还是自定义头或识别 User-Agent，以及是否要兼顾其他文本客户端、Windows 终端、代理抓取与 curl 客户端安全。

认为 curl 可访问的文本网站很有趣，并乐于分享类似项目

• 不少读者觉得把网站做成 curl 能直接读的纯文本或 ANSI 版很酷，有人已经在个人站上这样实践，用子域名分别展示最近听的音乐和读的书；也有人正在把家务、日历和气象站数据做成明文版，以便极简设备读取。（较多人）
• 社区里出现一批顺势自荐或指路的同类项目：有人做了类似 curl wttr.in 的简化天气服务，有人做了带 curl | sh 模式的多语言网站，说明这种玩法容易激发模仿和再创作。（较多人）
• 一条代表性玩笑说，早就想试试像 RMS 那样在终端里浏览网页，把这种访问方式看作复古的极客乐趣。（少数人） > 有人表示这类可用 curl 访问的内容非常有趣，并希望以后能看到更多（@zanderwohl）

认为该用标准 Accept 内容协商，而不是自定义头或识别 curl

• 有人指出，若想拿到原始 HTML，加 X-Original: true 这类自定义头不如用更标准的 Accept: text/html；如果要把 ANSI 版给 curl，也可以约定 text/x-ansi 这样的媒体类型，这样 wget 等其他文本客户端也能通过内容协商获取，而不是只靠识别 curl。（少数人） > 评论建议，与其用自定义头判断，不如用标准 Accept 内容协商，并给 curl 版本指定类似 text/x-ansi 的类型，让其他文本客户端也能取到该版本（@jayknight）

认为可以完全静态实现，不必检查 User-Agent

• 有人补充，其实不检查 User-Agent 也能 100% 静态做到：把真正的 HTML 放进备用终端缓冲区，再把给 curl 看的 ANSI 内容追加在后面；curl 拉取时会先输出 HTML，但随后立即清屏并写入 ANSI 版，浏览器里这些 ANSI 则被注释隐藏，适合 GitHub Pages 等静态托管。（少数人）

提醒在 Windows 上用 Terminal 可正常运行，但别用 PowerShell 模式

• 有人提醒，这个玩法在 Windows 上其实正常，只要从 Terminal 运行、不要进入 PowerShell 模式即可。（少数人）

提醒 curl 刚修复漏洞，恶意服务器可能反向攻击客户端

• 有人提到，当天正好发布了 curl/libcurl 的修复，主要漏洞场景是恶意服务器反过来攻击客户端；因此用 curl 随意访问外部站点时仍要有安全意识。（少数人）

好奇这是否也让浏览网页的代理更容易访问站点

• 也有人提问，这种做法是否有助于让浏览网页的代理程序（agents）更容易获取网站内容，把话题引向机器可读性。（少数人）

有价值的补充

• curl wttr.in 是社区熟悉的先例：早就有通过 curl 获取天气的纯文本服务，说明“curl 可访问站点”并非全新想法。
• Finger 协议被重新提起：这个早期互联网协议能用终端查询用户或主机信息，和如今用 curl 取回结构化明文在精神上很接近，可视为轻量文本查询传统的延续。
• 自建这类服务要注意滥用与成本：例如 wthr.dev 虽仿照 wttr.in 做了更简化的天气查询，但因运行在自家地下室，设置了极严格的速率限制，地理编码启发式也还有点不准。