From 766f02ae5dfd113ab5b214f784f44dce21c19c81 Mon Sep 17 00:00:00 2001 From: ScreenTinker Date: Tue, 12 May 2026 11:57:54 -0500 Subject: [PATCH] docs(upload): correct misleading defParamCharset comment The previous comment claimed defParamCharset:'utf8' fixed multipart filename header decoding. It doesn't - that option only fires for the RFC 5987 encoded filename*=utf-8''... form, which clients rarely send. The actual UTF-8 recovery happens in the storage.filename callback (added in d679ca8) via Buffer.from(name,'latin1').toString('utf8'). The option is kept set for the rare RFC 5987 case but the comment no longer overclaims what it does. --- server/middleware/upload.js | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/server/middleware/upload.js b/server/middleware/upload.js index faa96a5..fbd953c 100644 --- a/server/middleware/upload.js +++ b/server/middleware/upload.js @@ -41,9 +41,12 @@ const fileFilter = (req, file, cb) => { } }; -// `defParamCharset: 'utf8'` makes busboy decode multipart filename headers as UTF-8. -// Default is latin1, which mangles umlauts and other non-ASCII characters -// (e.g. "Größe.jpg" arrives as "Größe.jpg" and gets stored that way). +// `defParamCharset: 'utf8'` only takes effect for RFC 5987 encoded +// `filename*=utf-8''...` params. Most real clients (browsers, curl, programmatic +// HTTP) send the plain `filename="..."` form, where busboy still reads the bytes +// as latin1 regardless of this option. The actual UTF-8 recovery happens in the +// storage.filename callback above via Buffer.from(name,'latin1').toString('utf8'). +// Kept here as defense-in-depth for the rare RFC 5987 case. const upload = multer({ storage, fileFilter,