Feishu Non-ASCII Filenames: Chinese Content Uploads Fixed

The problem sounds niche until you hit it: You're coordinating a Chinese social media campaign. Your AI agent generates Xiaohongshu (小红书) carousel drafts, packages them as 小红书_20260320_carousel.zip, and uploads to Feishu for team review.

Your team opens Feishu and sees: ___20260320_carousel.zip

All the Chinese characters? Gone. Replaced with underscores or question marks. Your carefully named file—which clearly indicated "Xiaohongshu March 20 carousel"—is now a cryptic mess. Your team has no idea what this file is without opening it.

This is the non-ASCII filename problem, and OpenClaw v2026.3.13-1 finally fixes it for Feishu uploads.

Why Non-ASCII Filenames Break

The ASCII Legacy

File upload systems were built in an era when ASCII (American Standard Code for Information Interchange) was the only encoding anyone cared about. ASCII supports:

• English letters (A-Z, a-z)
• Numbers (0-9)
• Basic symbols (- _ . ! @ # $ etc.)

That's it. No Chinese. No Japanese. No Korean. No accented European characters.

When you try to upload a file named in Chinese:

Original filename: 小红书_carousel_draft.zip
ASCII conversion attempt: ???_carousel_draft.zip
Result: Broken/corrupted/lost characters

The HTTP Multipart Form-Data Problem

File uploads use the multipart/form-data encoding specified in RFC 2046. The original spec assumed ASCII filenames.

Legacy upload header:

Content-Disposition: form-data; name="file"; filename="小红书.zip"

Problem: 小红书 contains non-ASCII bytes. Different systems handle this differently:

• Some replace with underscores: ___.zip
• Some drop the characters: .zip
• Some reject the upload: Error 400
• Some mangle them: Ð_ÁÎÏéÊé.zip (mojibake)

The RFC 2231 Solution (That Most Systems Ignore)

In 1997, RFC 2231 introduced proper support for non-ASCII filenames using percent-encoding:

Content-Disposition: form-data; name="file";
    filename*=UTF-8''%E5%B0%8F%E7%BA%A2%E4%B9%A6_carousel.zip

This works! The filename* parameter (note the asterisk) tells the server:

1. Encoding is UTF-8
2. No language tag (the empty '' part)
3. Filename is percent-encoded (Chinese characters as %XX%XX%XX byte sequences)

The catch: Not all servers support RFC 2231. Some only look at filename, ignore filename*, and still corrupt your upload.

How OpenClaw Solves It for Feishu

OpenClaw's Feishu integration now uses dual-header encoding—sending both ASCII-safe and RFC 2231 headers to maximize compatibility:

The Technical Fix

Before (broken):

// Simple filename (ASCII-only)
Content-Disposition: form-data; name="file"; filename="小红书.zip"
// Feishu receives garbled characters

After (fixed):

// Dual encoding approach
Content-Disposition: form-data; name="file";
    filename="xiaohongshu.zip";
    filename*=UTF-8''%E5%B0%8F%E7%BA%A2%E4%B9%A6.zip

// If Feishu supports RFC 2231 → uses UTF-8 encoded filename
// If not → falls back to ASCII transliteration

The fallback layer: OpenClaw also transliterates Chinese/Japanese/Korean characters to pinyin/romaji when generating the ASCII filename parameter:

• 小红书 → xiaohongshu (pinyin)
• いいね → iine (romaji)
• 댓글 → daesgeul (romanization)

This way, even if RFC 2231 isn't supported, you get xiaohongshu.zip instead of ___.zip—which is at least human-readable.

Implementation Details

OpenClaw's file upload function now handles this automatically:

// OpenClaw Feishu upload
await feishu_upload({
  folderToken: "fldcnXXXXXXXXXX",
  filePath: "/path/to/小红书_carousel.zip",
  fileName: "小红书_20260320_carousel.zip"
})

// Behind the scenes:
1. Detect non-ASCII characters in fileName
2. Generate RFC 2231 encoded header (filename*)
3. Generate ASCII fallback (transliterate to pinyin)
4. Send both in multipart request
5. Feishu receives original Chinese filename ✅

Real-World Impact: APAC Content Workflows

Use Case 1: Xiaohongshu Carousel Automation

The Workflow:

1. AI agent generates 8-slide Xiaohongshu carousel (1080×1440 images + copy)
2. Packages as 小红书_[topic]_[date].zip
3. Uploads to Feishu shared folder for designer review
4. Designer downloads, edits, re-uploads final version

Before the fix:

• Filename uploaded as ___.zip or xiaohongshu_topic_date.zip (AI had to manually avoid Chinese chars)
• Designer couldn't tell which file was which without opening
• Had to maintain separate naming spreadsheet
• Time lost: ~10 minutes per file (opening, checking, renaming)

After the fix:

• Filename appears in Feishu as 小红书_职场新人避坑指南_20260320.zip
• Designer immediately knows: Xiaohongshu, topic "workplace newcomer pitfall guide", March 20
• No spreadsheet needed, no guessing, no wasted time

Use Case 2: Multi-Platform Content Localization

The Setup: Marketing team coordinates content across 4 platforms:

• 小红书 (Xiaohongshu) - Chinese lifestyle platform
• 即刻 (Jike) - Chinese Twitter-like platform
• TikTok抖音 - Short video content
• 微信公众号 (WeChat Official Account) - Long-form articles

Naming convention:

小红书_[campaign]_[date].zip
即刻_[campaign]_[date].txt
抖音_[campaign]_[date].mp4
微信_[campaign]_[date].docx

Why Chinese filenames matter:

• Team is Chinese-speaking → English names feel unnatural and slow down workflow
• Platform names are Chinese → transliterating "Xiaohongshu" adds cognitive load
• Campaign names are Chinese → full localization required for clarity

Before the fix: Had to use romanized names (xiaohongshu_campaign_date.zip), which felt disconnected from the actual Chinese content inside the files.

After the fix: Files named in Chinese appear correctly in Feishu, matching the team's natural workflow language.

Use Case 3: Japanese TikTok Content Coordination

The Challenge: Agency managing TikTok accounts for Japanese brands. Content files named in Japanese hiragana/katakana:

• いいね_コメント_キャンペーン.mp4 (Like + Comment Campaign)
• 新商品紹介_ショート動画.mp4 (New Product Introduction Short Video)

The Problem: Upload to Feishu → filenames become _________.mp4 or iine_komento_kyanpen.mp4 (romanized, loses original readability).

After OpenClaw's fix: Japanese filenames preserved correctly. Team can work entirely in Japanese without worrying about file upload encoding issues.

Beyond Feishu: The Broader Problem

Feishu isn't unique—many platforms struggle with non-ASCII filenames:

Platform Compatibility Matrix

Platform	RFC 2231 Support	Fallback Behavior
Feishu/Lark	✅ Yes (as of 2026)	UTF-8 preserved
Google Drive	✅ Yes	Full Unicode support
Dropbox	✅ Yes	Full Unicode support
Slack	⚠️ Partial	Some chars replaced
Discord	✅ Yes	UTF-8 preserved
Email (SMTP)	⚠️ Varies by client	Often breaks

OpenClaw's approach: Implement RFC 2231 encoding for all file uploads, regardless of platform. Future-proof and maximizes compatibility.

Technical Best Practices

1. Always Use UTF-8 Encoding

When generating filenames in code:

// ✅ Good: Explicit UTF-8
const filename = Buffer.from('小红书_carousel.zip', 'utf8').toString()

// ❌ Bad: Default encoding (may vary)
const filename = '小红书_carousel.zip'  // Encoding depends on system locale

2. Sanitize Filenames Before Upload

Even with RFC 2231, some characters are problematic across filesystems:

// Characters to avoid in filenames
const forbidden = ['/', '\\', ':', '*', '?', '"', '<', '>', '|']

function sanitizeFilename(name) {
  return name.replace(/[/\\:*?"<>|]/g, '_')
}

3. Test with Edge Cases

Before deploying, test your upload system with:

• Chinese: 测试文件.zip
• Japanese: テストファイル.zip
• Korean: 테스트파일.zip
• Emoji: test_🎉_file.zip
• Mixed: 小红书_TikTok_Campaign_2026.zip

4. Provide ASCII Fallbacks

Even with RFC 2231, always include a readable ASCII fallback:

// Original: 小红书_职场指南.zip
// ASCII fallback: xiaohongshu_zhichang_zhinan.zip

// Users on old systems see: xiaohongshu_zhichang_zhinan.zip
// Users on modern systems see: 小红书_职场指南.zip

What ButterGrow Does With This

Every ButterGrow automation workflow that uploads files to Feishu now includes:

Automatic Filename Handling

• Chinese content: Preserved as-is (e.g., 小红书_carousel.zip)
• Mixed content: Full Unicode support (e.g., TikTok_抖音_Campaign.mp4)
• Emoji: Preserved where supported (e.g., launch_🚀_campaign.pdf)

Client Onboarding

When setting up workflows, we ask:

1. What language does your team work in? (Chinese, Japanese, English, etc.)
2. What naming convention do you currently use?
3. Do you need ASCII fallbacks for legacy systems?

Then configure file uploads accordingly—no more "use English names to avoid encoding issues."

Conclusion: Localization Goes Beyond Translation

When people talk about "localization," they usually mean translating UI text or adapting content for local markets. But true localization goes deeper—it means respecting local languages at the infrastructure level.

Filenames are infrastructure. When your Chinese team has to name files in English because your automation tool can't handle Chinese characters, that's not just inconvenient—it's a subtle form of linguistic colonization.

OpenClaw's fix for Feishu non-ASCII filenames is a small technical detail with a big cultural impact: your team can work in their native language without worrying about what the computer can handle.

That's what production-ready international automation looks like in 2026.