Commit Graph
1 Commits
Author SHA1 Message Date
Xinmin ZengandGitHub 132adac3bb fix(daemon): preserve non-ASCII filenames on multipart upload (#166)
* fix(daemon): preserve non-ASCII filenames on multipart upload

multer@1 hands callers latin1-decoded multipart filenames, and
sanitizeName() then collapses every non-ASCII character to '_'. A
Chinese DOCX uploaded as 测试文档.docx therefore landed on disk as
____.docx, while the response shipped a latin1-mangled originalName
back to the client. The chat composer compared that to the UTF-8
File.name from the picker, missed the match, and reported "some
files could not be stored" even though the bytes were already on
disk.

Add decodeMultipartFilename() that round-trip-checks latin1->utf8
so genuine latin1 names aren't corrupted, and switch sanitizeName()
to keep \p{L}\p{N} (Unicode letters/digits) while still stripping
path separators, control characters, and Windows-reserved
punctuation. Apply the decoder to all three multer storage filename
callbacks so /api/upload, /api/import/claude-design, and
/api/projects/:id/upload all return UTF-8 originalNames.

Closes #144

* fix(daemon): address review feedback on filename decoder

Three changes from review:

1. decodeMultipartFilename now bails out early when any code point in
   the input exceeds 0xFF. multer can hand us an already-decoded UTF-8
   string when the client uses the RFC 5987 `filename*` parameter, and
   the previous round-trip-only check would corrupt those names — for
   example, a properly decoded `测试文档.docx` could be re-mangled into
   `KՇc.docx` because the latin1-encoded bytes happened to form a
   valid UTF-8 sequence. Code points above 0xFF can never appear in a
   genuine latin1-decoding-of-utf8 input, so they're an unambiguous
   signal that no further decoding should run.

2. decodeMultipartFilename now handles null/undefined defensively (it
   was relying on multer always populating originalname; this just
   makes the helper safer to reuse from other call sites).

3. The inline sanitiser regex in the `upload` and `importUpload`
   multer instances is replaced with a direct `sanitizeName()` call,
   matching what `projectUpload` already did. This keeps a single
   source of truth for the allowed character set so future tweaks
   only have to land in one place.

Adds two more tests to the existing sanitize-name suite covering the
above-0xFF early return and the null/undefined inputs (13/13 in that
file, 58/58 across the daemon).
2026-04-30 19:49:43 +08:00