openclaw - ✅(Solved) Fix [Bug]: Filename Becomes URL-Encoded String After Sending Files in Lark/Feishu [5 pull requests, 1 participants]

lijihua2017 · 2026-03-12T08:12:59Z

[openclaw] When sending a file via attachment or upload in Lark/Feishu, if the original filename contains non-ASCII characters e.g., Chinese, Japanese, emoji,… 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). # PR #43860: fix(feishu): preserve non-ASCII filenames for file uploads - Repository: openclaw/openclaw - Author: lynnzc - State: closed | merged: False - Link: https://github.com/openclaw/openclaw/pull/43860 ## Description (problem / solution / changelog) ## Summary - Problem: Feishu file uploads percent-encoded non-ASCII `file_name` values before upload. - Why it matters: recipients saw URL-encoded filenames like `%E7%A4%BA%E4%BE%8B.pdf` instead of human-readable names. - What changed: removed non-ASCII filename percent-encoding in Feishu upload path and preserved original `file_name` values. - What did NOT change (scope boundary): no changes to media type routing, upload transport, or non-Feishu channels. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #43840 - Related #31328 ## User-visible / Behavior Changes - Feishu/Lark file messages now keep original non-ASCII filenames (Chinese/special characters) instead of showing URL-encoded names. ## Security Impact (required) - New permissions/capabilities? (`No`) - Secrets/tokens handling changed? (`No`) - New/changed network calls? (`No`) - Command/tool execution surface changed? (`No`) - Data access scope changed? (`No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: macOS - Runtime/container: Node 22 + pnpm workspace - Model/provider: N/A - Integration/channel (if any): Feishu - Relevant config (redacted): default mocked Feishu account in test ### Steps 1. Send a file via Feishu path with non-ASCII filename (e.g. `测试文档.pdf`). 2. Inspect upload payload `im.file.create` `data.file_name`. 3. Verify filename passed to Feishu remains human-readable. ### Expected - Non-ASCII filenames are preserved as-is. ### Actual - Verified in tests: `data.file_name` equals original non-ASCII filename. ## Evidence - [x] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) - Verified scenarios: - `pnpm test extensions/feishu/src/media.test.ts` - Result: `1 passed`, `18 passed` tests. - Assertions now verify preserved Chinese and special-character filenames in Feishu upload call payload. - Edge cases checked: - ASCII filenames remain unchanged. - Special characters (em-dash/full-width brackets) remain unchanged. - What you did **not** verify: - Live Feishu API run in a real tenant. ## Review Conversations - [x] I replied to or resolved every bot review conversation I addressed in this PR. - [x] I left unresolved only the conversations that still need reviewer or maintainer judgment. ## Compatibility / Migration - Backward compatible? (`Yes`) - Config/env changes? (`No`) - Migration needed? (`No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: revert this PR commit. - Files/config to restore: `extensions/feishu/src/media.ts`, `extensions/feishu/src/media.test.ts`. - Known bad symptoms reviewers should watch for: Feishu upload failures for some non-ASCII filenames. ## Risks and Mitigations - Risk: Some environments may still require encoded multipart filename handling. - Mitigation: behavior is covered by focused Feishu media tests and rollback is one commit. ## Changed files - `extensions/feishu/src/media.test.ts` (modified, +5/-72) - `extensions/feishu/src/media.ts` (modified, +1/-21) --- # PR #1: fix(feishu): decode RFC 5987 filename for file downloads - Repository: guang384/openclaw - Author: guang384 - State: closed | merged: False - Link: https://github.com/guang384/openclaw/pull/1 ## Description (problem / solution / changelog) ## Summary Fixes #43840 ### Problem When sending files with non-ASCII filenames (Chinese, Japanese, emoji) in Lark/Feishu, the filename appears URL-encoded (e.g., %E6%B5%8B%E8%AF%95.txt instead of 测试.txt). ### Root Cause The backend receives the Content-Disposition header with RFC 5987 encoded filename (filename*=UTF-8...) but fails to decode it using decodeURIComponent before storing/displaying. ### Changes - Add decodeRfc5987Filename() helper function to decode percent-encoded filenames - Apply to file message display (line 437) - Apply to file download metadata

openclaw2026-03-12 08:12:59

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#43840•Fetched 2026-04-08 00:18:45

View on GitHub

Comments

Participants

Timeline

Reactions

Author

lijihua2017

Participants

lijihua2017

Timeline (top)

cross-referenced ×5referenced ×4labeled ×2

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).

Root Cause

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

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

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

extent analysis

Fix: Properly decode RFC‑5987 `filename*` values in the upload handler

The regression is caused by the backend passing the raw filename*= value (e.g.
UTF-8''%E7%A4%BA%E4%BE%8B%E6%96%87%E6%A1%A3.pdf) straight through to storage / API responses. The fix is to detect the filename* parameter, parse the charset, URL‑decode the value, and use that as the canonical filename.

1. Add a small RFC‑5987 decoder

/**
 * Decode a RFC‑5987 encoded header value.
 * Example input: "UTF-8''%E7%A4%BA%E4%BE%8B%E6%96%87%E6%A1%A3.pdf"
 * Returns: "示例文档.pdf"
 */
function decodeRFC5987(value) {
  // Split into charset, language (optional), and encoded part
  const parts = value.split("'");
  if (parts.length !== 3) return value; // not RFC‑5987, return as‑is

  const [, /*lang*/, encoded] = parts; // ignore charset/language for now
  try {
    // decodeURIComponent works for UTF‑8 percent‑encoding
    return decodeURIComponent(encoded);
  } catch (_) {
    // fallback – return original if malformed
    return value;
  }
}

2. Patch the upload middleware

Assuming you use multer, busboy, or formidable, the file metadata is available as file.originalname (or similar). Replace it with the decoded value when a filename* parameter is present.

Example with multer + custom file filter

const multer = require('multer');
const storage = multer.memoryStorage(); // or diskStorage as

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

#api #ssr #installation #tensor shape #autograd error #task chaining #parallel task #integration issue #index setup #retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: Filename Becomes URL-Encoded String After Sending Files in Lark/Feishu [5 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fixed

PR fix notes

PR #43860: fix(feishu): preserve non-ASCII filenames for file uploads

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #1: fix(feishu): decode RFC 5987 filename for file downloads

Description (problem / solution / changelog)

Summary

Problem

Root Cause

Changes

Test

Changed files

PR #43870: fix(feishu): decode RFC 5987 filename for file downloads

Description (problem / solution / changelog)

Summary

Problem

Root Cause

Changes

Test

Changed files

PR #43916: fix(feishu): decode URL-encoded filenames when receiving files

Description (problem / solution / changelog)

Summary

Changes

Test Plan

Changed files

PR #43983: fix(feishu): decode RFC 5987 filename for file downloads

Description (problem / solution / changelog)

Summary

Problem

Root Cause

Changes

Test

Changed files

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix: Properly decode RFC‑5987 filename* values in the upload handler

1. Add a small RFC‑5987 decoder

2. Patch the upload middleware

Example with multer + custom file filter

FAQ

Expected behavior

Still need to ship something?

Fix: Properly decode RFC‑5987 `filename*` values in the upload handler