Bug type
Regression (worked before, now fails)
Summary
When sending a file (via attachment or upload) in Lark/Feishu, if the original filename contains non-ASCII characters (e.g., Chinese, Japanese, emoji, or special symbols), the file is received with a URL-encoded filename (e.g., %E6%B5%8B%E8%AF%95.txt) instead of the original human-readable name (e.g., 测试.txt).
Steps to reproduce
Prepare a file with a non-ASCII filename (e.g., 示例文档.pdf).
Send the file via the Lark/Feishu client (Desktop/Web/Mobile).
The recipient views or downloads the file in their Lark/Feishu client.
Actual Result: The filename appears as a URL-encoded string (e.g., %E7%A4%BA%E4%BE%8B%E6%96%87%E6%A1%A3.pdf).
Expected Result: The filename should remain unchanged and display as 示例文档.pdf.
Expected behavior
When sending a file (via attachment or upload) in Lark/Feishu, if the original filename contains non-ASCII characters (e.g., Chinese, Japanese, emoji, or special symbols), the file is received with a URL-encoded filename (e.g., %E6%B5%8B%E8%AF%95.txt) instead of the original human-readable name (e.g., 测试.txt).
Actual behavior
The backend receives the Content-Dispositionheader from the upload request, which contains the filenameparameter encoded per RFC 5987 (e.g., filename=UTF-8''%E7%A4%BA%E4%BE%8B%E6%96%87%E6%A1%A3.pdf).
Before storing the file or returning metadata to the frontend, the backend fails to properly decode the filename*value using decodeURIComponent(or equivalent).
As a result, the encoded string is passed through the system and displayed as-is to the end user.
OpenClaw version
2026.03.08
Operating system
Ubuntu 24
Install method
npm
Model
any
Provider / routing chain
openrouter
Config file / key location
No response
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response
Bug type
Regression (worked before, now fails)
Summary
When sending a file (via attachment or upload) in Lark/Feishu, if the original filename contains non-ASCII characters (e.g., Chinese, Japanese, emoji, or special symbols), the file is received with a URL-encoded filename (e.g., %E6%B5%8B%E8%AF%95.txt) instead of the original human-readable name (e.g., 测试.txt).
Steps to reproduce
Prepare a file with a non-ASCII filename (e.g., 示例文档.pdf).
Send the file via the Lark/Feishu client (Desktop/Web/Mobile).
The recipient views or downloads the file in their Lark/Feishu client.
Actual Result: The filename appears as a URL-encoded string (e.g., %E7%A4%BA%E4%BE%8B%E6%96%87%E6%A1%A3.pdf).
Expected Result: The filename should remain unchanged and display as 示例文档.pdf.
Expected behavior
When sending a file (via attachment or upload) in Lark/Feishu, if the original filename contains non-ASCII characters (e.g., Chinese, Japanese, emoji, or special symbols), the file is received with a URL-encoded filename (e.g., %E6%B5%8B%E8%AF%95.txt) instead of the original human-readable name (e.g., 测试.txt).
Actual behavior
The backend receives the Content-Dispositionheader from the upload request, which contains the filenameparameter encoded per RFC 5987 (e.g., filename=UTF-8''%E7%A4%BA%E4%BE%8B%E6%96%87%E6%A1%A3.pdf).
Before storing the file or returning metadata to the frontend, the backend fails to properly decode the filename*value using decodeURIComponent(or equivalent).
As a result, the encoded string is passed through the system and displayed as-is to the end user.
OpenClaw version
2026.03.08
Operating system
Ubuntu 24
Install method
npm
Model
any
Provider / routing chain
openrouter
Config file / key location
No response
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response