Fix multer latin1 mis-decode for non-ASCII filenames
Mor1arty's fork patches `upload.ts` to re-decode `req.file.originalname` from latin1 to UTF-8, fixing the mangled-filename bug that hits anyone uploading files with Chinese (or any non-ASCII) characters. Ten lines against multer's multipart parsing default.
Multer inherits Busboy's default behavior of treating the multipart filename header as latin1. For ASCII filenames this is a no-op. For anything outside that range - Chinese, Arabic, Cyrillic, accented Latin - the filename arrives garbled. The fix is the standard recipe: Buffer.from(name, "latin1").toString("utf-8") applied in the singleFileUpload middleware on the success path, before next() is called.
The change is 10 LOC, in one file (backend/src/lib/upload.ts), and only runs when req.file?.originalname is truthy. ASCII users see no behavioral change; the round-trip is a no-op for correctly encoded ASCII bytes.
One caveat: the fix applies unconditionally rather than checking the filename* RFC 5987 parameter first. A client that correctly sends UTF-8 in a filename* field will still get the latin1 re-decode applied - which is safe because the round-trip produces the same string, but a stricter implementation would inspect the encoding directive. For practical purposes in a web upload context this is fine.
The PR was merged from Mor1arty/feature/CN-file-support into main. The merge commit (533a4ed) carries no additional code.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?