早上好,我是まさきん。
我在手机收到的通知上加了一个“丢给Claude”按钮。一按,就会用通知的内容直接打开Claude的对话。可是遇到较长的日语文本时,URL就装不下了。今天就来记录一下我的解决办法:把全文挪到Notion。
※以上为文章发布时的信息。最新条件请以官方网站为准。
- 日语经过URL编码后,每个字会膨胀到约9个字符。
- 在我的环境里以2,000左右为参考值,把较长的引导语缩短后才顺利通过。
- 长文的全文放在Notion,按钮里只放页面ID和开头部分。
- claude.ai/new?q= 这个网页版用法,我没能在官方文档中确认到。
- 桌面版的 claude://claude.ai/new?q= 则写在官方帮助页面里。
通知看完就结束了
我们家通过Telegram接收家里的定期报告和故障通知。自动化的结果会一条接一条地推送到手机上。之前我也写过让AI每晚检查信用卡消费的机制。
不过,通知往往看完就算了。就算心里想“这个该怎么办”,打开Claude再粘贴进去也有点麻烦。所以我决定直接在通知上加一个咨询的入口。
按钮的机制
通知上带着一个“🤖 丢给Claude”的按钮。它的内容是 claude.ai/new?q=<请求文本> 这样的URL。一按,Claude的对话就会以填好请求文本的状态打开。
按钮用的是Telegram的InlineKeyboardButton。官方Bot API说明,url字段可以指定“HTTP或tg://的URL”。另一方面,按下时发给机器人的 callback_data 有1〜64字节的限制。这次只需要打开URL,所以用url字段就够了。
| 项目 | 官方规范 | 我的用法 |
|---|---|---|
| text | 按钮显示的文字 | 🤖 丢给Claude |
| url | HTTP或tg://的URL | claude.ai/new?q=… |
| callback_data | 1〜64字节 | 没有使用 |
| 通知正文 | 1〜4096字符 | 报告或故障内容 |
日语每个字会膨胀成9个字符
在这里我碰到了第一道墙。把日语放进URL后,字符数会一下子增加很多。
URL里能用的字符是固定的,其他字符都要替换成一种叫百分号编码的形式。RFC 3986规定,1个字节用“%”加2位十六进制数,共3个字符来表示。
日语的字符在UTF-8中一般是3个字节。RFC 3629的表格里,这个范围也是3字节的序列。3个字节各变成3个字符,所以1个字大约是9个字符。例如日语平假名的 a,就会变成 %E3%81%82。
| 字符种类 | UTF-8字节数 | 编码后的字符数 |
|---|---|---|
| 半角英文和数字 | 1字节 | 1个字符(保持原样) |
| 大多数平假名和汉字 | 3字节 | 约9个字符 |
| 部分符号 | 1〜3字节 | 3〜9个字符 |
明白了原理之后,我才恍然大悟。按这个算法,200个日语字符,URL就接近2,000个字符了。
光是最初的引导语就超过了2,000
一开始,我在请求文本的开头加了一段比较长的引导语,比如“这是家里的自动通知”之类的前言。结果光这段引导语,编码后就超过了2,000。
于是我把引导语大幅缩短,才顺利通过。但只要正文一长,还是会碰到同样的问题。这时我意识到,需要另找一个存放的地方。
URL长度并没有统一的上限
那么,URL到底能放多少字符呢?查了一下,似乎并没有统一的上限。
HTTP规范RFC 9110建议至少支持8,000个八位字节(octet)的URI。但这只是下限的建议,并没有规定上限。URL太长的话,服务器也可能返回“414 URI Too Long”。
浏览器、应用以及中间经过的各种服务,能处理的长度各不相同。所以在我的环境里,以2,000左右作为参考值。这个数字并不保证在任何地方都能通过。
+和%变成了乱码
还有一个不起眼却让我卡住的地方,就是符号。传给 ?q= 的文本里,“+”和“%”出现了乱码。即使正确编码了,显示出来的文字还是会走样。
在URL的世界里,有把“+”当作空格来解读的惯例。WHATWG的URL标准中,在解析表单格式时也有把“+”替换为空格的步骤。至于究竟是在哪一步出的问题,这里我不下定论。
对策我做得很简单:发送前把“+”和“%”替换成全角的“+”“%”。反正是给人读的请求文本,用全角基本不会有什么影响。
长文挪到了Notion
接下来是正题,也就是解决办法。长文本我不再放进URL了。
取而代之的是,把全文写进Notion里一个名为“Claude交接”的数据库。按钮的URL里只放该页面的ID和开头部分。Claude那边再凭这个ID去读取Notion的页面。
| 比较项目 | 短文 | 长文 |
|---|---|---|
| URL里放什么 | 请求文本本身 | 页面ID和开头部分 |
| 全文存放位置 | URL里 | Notion页面 |
| Claude的动作 | 直接读取 | 去读取Notion |
| 运行确认 | 实际发送确认过 | 实际发送确认过 |
短文和长文我都实际发送过,确认可以正常运行。
Notion API能做的事
用Notion的官方API,可以在数据库下面创建页面。做法是把已有的页面或数据源指定为父级。
读取时,指定页面ID就能取出页面的信息。不过,页面的正文要走另一个接口。官方文档写明,要用“获取块的子元素”的API来读取。
还有一点需要注意,就是限制。官方的请求限制中规定,单个富文本的内容最多2,000个字符。与其把长文塞进一个块里,不如分开写更稳妥。
要让Claude读取,需要事先连接Notion的连接器(connector)。连接器是让Claude访问外部服务数据的机制。官方帮助页面写着,权限会沿用连接者本人的权限。
流程步骤
把我的机制按流程排列,就是下面这样。
- 通知脚本准备好通知正文和请求文本。
- 把请求文本里的“+”和“%”替换成全角。
- 确认编码后的长度是否在参考值以内。
- 如果够短,就直接放进 ?q= 生成按钮。
- 如果太长,就把全文写进Notion的交接数据库。
- 只把页面ID和开头部分放进 ?q= 生成按钮。
- 把通知和按钮发送到Telegram。
写成伪代码,大致是这样。
文本 = 把请求文本里的“+”“%”替换为全角
if 编码后的长度 <= 参考值:
q = 文本
else:
ID = 把全文保存到Notion交接数据库
q = "请读取Notion页面 " + ID + "。开头: " + 文本的开头部分
按钮URL = "https://claude.ai/new?q=" + 编码(q)
把生成按钮的部分拆成了独立脚本
最开始,我是在发送通知的脚本里拼接URL的。但随着替换和长度判断越来越多,代码变得不好读了。
于是我把生成按钮URL的处理拆成了一个独立的小脚本。发送通知的一方只需接收生成好的URL。就算通知的种类增加了,也能重复使用同一个部件。
自动化幕后的故事,我在Cloudflare Workers免费额度Cron上限的文章里也写过。拆得小一点,以后修改起来就轻松多了。
Mac桌面应用上的差异
我在Mac的Claude桌面应用上也试了一下。用 claude://new?q= 的话,只会启动应用,文字没有传过去。
而用 claude://claude.ai/new?q= 的话,文字就传过去了。官方帮助页面上也载有这种格式。帮助页面还写着,q 的文本超过约14,000个字符会被截断,并且所有的值都需要进行URL编码。
另外,Telegram按钮的url字段在官方规范中是HTTP或tg://的URL。这和把 claude:// 直接放进按钮是两回事,请分开看待。
网页版的 claude.ai/new?q=,我没能在官方文档中确认到。现在虽然可以用,但将来可能会有变化。桌面版的 claude:// 则在官方帮助页面上载有格式。
如果靠一部手机打理家里的大小事,通信费也值得重新审视一下。通知和与AI的交流越多,手机就越成为生活的窗口。
常见的失败与陷阱
我觉得这个机制适合“通知看完就放过去的人”,可能也适合“想把自动化结果拿去问AI的人”。不过,也有几个容易踩坑的地方。
- 引导语写得太长,正文就放不进去了
- 按字数计算,忽略了编码后的长度
- “+”或“%”变成乱码,请求的意思被改变
- 在按钮的URL里混入了令牌或个人ID
- 交接页面越积越多,整理跟不上
尤其是令牌这件事要格外小心。URL很容易通过历史记录或分享被别人看到。只放交接用的页面ID,应该会比较安心吧。
交接页面的整理,我自己也还在进行中。满7天后自动归档的处理还没有实现。规则定了却没人遵守的事,我在清点164个任务的文章里也写过。用机制来收拾干净,才算完成这份作业吧。
开始之前要确认的事
- 用于通知的服务是否支持URL按钮
- 是否有计算请求文本编码后长度的机制
- 是否已决定加号和百分号的处理方式
- 是否准备好了长文的存放位置(如Notion)
- 是否已在Claude上连接Notion的连接器
- URL里是否没有放入令牌或个人ID
- 是否有清理交接页面的规则
常见问题
Q. 为什么日语会让URL变长?
大多数日语字符在UTF-8中是3个字节。URL里1个字节用“%XX”这3个字符来表示。所以每个字会膨胀到约9个字符。
Q. URL最多能放多少字符?
似乎没有统一的上限。HTTP规范建议支持8,000个八位字节以上。但实际的上限因浏览器和服务而异。在我的环境里以2,000左右为参考值。
Q. claude.ai/new?q= 是官方功能吗?
网页版的这个用法,我没能在官方文档中确认到。现在虽然可以用,但将来可能会有变化。桌面版的 claude://claude.ai/new?q= 写在官方帮助页面里。
Q. “+”和“%”为什么会变成乱码?
在URL里有把“+”当作空格来解读的惯例。不过,在我的环境里具体是在哪一步出的问题,我没有下定论。作为对策,我在发送前把它们替换成全角。
Q. 不能让Telegram的按钮携带较长的数据吗?
callback_data 有1〜64字节的限制,不适合用来携带长文本。所以我改成把全文放在Notion。
Q. 放在Notion的全文,Claude要怎么读取?
先在Claude上连接Notion的连接器。Claude会以URL里的页面ID为线索,去读取对应的页面。短文和长文两种情况我都实际确认过可以运行。
Q. 交接页面不会越积越多吗?
会越积越多。满7天后自动归档的处理还没做出来。这是目前遗留的课题之一。
参考的官方信息
- Telegram Bot API(InlineKeyboardButton、sendMessage)
- RFC 3986(URI语法、百分号编码)
- RFC 3629(UTF-8)
- RFC 9110(HTTP规范、URI长度、414)
- WHATWG URL Standard(表单格式的解析)
- Open Claude Desktop with a link(Claude Help Center)
- Open the Claude mobile app with a link(Claude Help Center)
- Use connectors to extend Claude’s capabilities(Claude Help Center)
- Notion connector(Claude)
- Create a page(Notion API)
- Retrieve a page(Notion API)
- Retrieve block children(Notion API)
- Request limits(Notion API)
总结
在通知上加一个“丢给Claude”按钮,离开口咨询就近了一大步。不过,日语在URL里会膨胀到约9倍。最后我定下的做法是:短文直接放,长文挪到Notion。
剩下的作业是清理交接页面。如果你也常常看完通知就放过去,不妨试着加一个按钮,怎么样?
本文包含联盟营销广告。如果您通过本站链接申请相关商品或服务，我们可能会从合作企业获得报酬。此外，运营者是乐天集团的员工，也可能通过员工推荐计划获得报酬。文章内容与评价均基于运营者的真实体验与调查完成，与是否存在广告无关，但请您在阅读前了解上述关系。详情请参阅免责声明与联盟营销说明。 免责声明与联盟营销说明
本文包含机器翻译内容。正式条件请以乐天移动官方网站的多语言页面为准。
如果您对乐天移动的通信区域·信号状况有疑问，可以通过官方的 电波改善调查申请表 进行咨询。
