openclaw - ✅(Solved) Fix [Bug]: Feishu plugin: Chinese filenames in attachments display as garbled (Latin-1 encoding issue) [2 pull requests, 1 participants]

Official PRs (…)
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.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59409Fetched 2026-04-08 02:24:09
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×2labeled ×2referenced ×1

When receiving files with Chinese filenames via Feishu webhook, the filenames are displayed as garbled text (e.g., "六大组件全解析.md" shows as "å_å_ç_ä_å_è_æ.md"). Server locale is correctly set to UTF-8, but the filename appears to be decoded using Latin-1 during inbound message processing.

Root Cause

When receiving files with Chinese filenames via Feishu webhook, the filenames are displayed as garbled text (e.g., "六大组件全解析.md" shows as "å_å_ç_ä_å_è_æ.md"). Server locale is correctly set to UTF-8, but the filename appears to be decoded using Latin-1 during inbound message processing.

Fix Action

Fixed

PR fix notes

PR #59431: fix(feishu): correct Chinese filename encoding in attachments

Description (problem / solution / changelog)

Fixes #59409

Summary

When receiving files with Chinese filenames via Feishu webhook, the filenames were displayed as garbled text (Latin-1 decoded UTF-8 bytes).

Root Cause

  • HTTP headers are typically parsed as ISO-8859-1 (Latin-1)
  • UTF-8 encoded filenames get misinterpreted as Latin-1 characters
  • Example: 六大组件全解析.md shows as å_å_ç_ä_å_è_æ.md

Solution

  • Added fixMisdecodedUtf8() function to detect and correct the encoding
  • Re-encodes Latin-1 chars back to bytes and decodes as UTF-8
  • Applied to both Content-Disposition header and API response file_name field

Test Plan

  1. Send a file with Chinese filename via Feishu chat
  2. Check the saved file in ~/.openclaw/media/inbound/
  3. Verify filename is preserved correctly (e.g., 六大组件全解析---<uuid>.md)

🤖 Generated with ClawHub

Changed files

  • extensions/feishu/src/media.ts (modified, +55/-2)

PR #59467: [codex] Fix Feishu attachment filename decoding

Description (problem / solution / changelog)

Summary

This fixes Feishu inbound attachment filenames being decoded as Latin-1 mojibake when the server returns UTF-8 bytes through the plain filename= path.

Root Cause

The download metadata path already handled RFC5987-style filename*= values, but plain filename= values were passed through as-is. When Feishu returned UTF-8 bytes that had already been interpreted as Latin-1, OpenClaw preserved the mojibake instead of recovering the intended UTF-8 filename.

Changes

  • keep filename*= as the highest-priority decode path
  • add a conservative Latin-1 -> UTF-8 recovery path for plain filename= values
  • avoid rewriting ASCII names or already-correct Unicode names
  • add regression coverage for ASCII, RFC5987, mojibake recovery, and already-correct Unicode filenames

Validation

  • pnpm exec vitest run extensions/feishu/src/media.test.ts

Fixes #59409

Changed files

  • extensions/feishu/src/media.test.ts (modified, +74/-0)
  • extensions/feishu/src/media.ts (modified, +21/-3)
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When receiving files with Chinese filenames via Feishu webhook, the filenames are displayed as garbled text (e.g., "六大组件全解析.md" shows as "å_å_ç_ä_å_è_æ.md"). Server locale is correctly set to UTF-8, but the filename appears to be decoded using Latin-1 during inbound message processing.

Steps to reproduce

  1. Send a file with Chinese filename (e.g., "六大组件全解析.md") via Feishu chat to the OpenClaw bot
  2. Check the saved file in /root/.openclaw/media/inbound/ directory
  3. Observe the filename is garbled (Latin-1 decoded)

Expected behavior

Chinese filenames should be preserved correctly in UTF-8 encoding. The file should be saved as "harness-六大组件全解析.md" or similar readable Chinese name.

Actual behavior

The filename is garbled due to Latin-1/ISO-8859-1 decoding of UTF-8 bytes. Example: "harness-å_å_ç_ä_å_è_æ---b06a5805-c48b-49f4-9807-37478b7b24bc.md" instead of "harness-六大组件全解析.md"

OpenClaw version

2026.4.1

Operating system

Linux 6.8.0-49-generic (x64)

Install method

npm (global install)

Model

N/A - Bug occurs before model inference (in webhook parsing)

Provider / routing chain

feishu (inbound webhook handler)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Impact: Affected: All Feishu users who receive files with non-ASCII filenames Severity: Medium - data is accessible but filenames are unreadable

Additional information

The outbound filename handling (sanitizeFileNameForUpload) was fixed in v2026.3.2 according to code comments in media.d.ts, but the inbound path (webhook message attachment parsing) still has this encoding issue. This suggests the fix was only applied to the upload path, not the download/receive path.

extent analysis

TL;DR

The issue can be resolved by ensuring that the inbound message processing correctly decodes filenames using UTF-8 encoding instead of Latin-1.

Guidance

  • Review the Feishu webhook handler code to identify where the filename decoding is happening and ensure it's using UTF-8 decoding.
  • Verify that the sanitizeFileNameForUpload function or its equivalent for inbound messages is correctly handling non-ASCII characters.
  • Check the character encoding settings in the Feishu webhook configuration to ensure it matches the expected UTF-8 encoding.
  • Test the fix by sending a file with a Chinese filename via Feishu chat to the OpenClaw bot and checking the saved file in the /root/.openclaw/media/inbound/ directory.

Example

No code snippet is provided as the issue does not include specific code references that can be modified.

Notes

The fix applied in v2026.3.2 for outbound filename handling may serve as a reference for resolving the inbound filename issue.

Recommendation

Apply a workaround to correctly decode filenames using UTF-8 encoding in the inbound message processing, as the root cause seems to be related to incorrect decoding.

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?
Loading…

FAQ

Expected behavior

Chinese filenames should be preserved correctly in UTF-8 encoding. The file should be saved as "harness-六大组件全解析.md" or similar readable Chinese name.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING