Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expose filename* #790

Open
bejito opened this issue Oct 15, 2019 · 7 comments
Open

expose filename* #790

bejito opened this issue Oct 15, 2019 · 7 comments

Comments

@bejito
Copy link

bejito commented Oct 15, 2019

In the Content-Disposition header spec, there is a field called filename* that allows to stransmit utf8 characters.
Neither fieldname not originalname expose that field.
Is it possible to get the value in that field from the multer execution ?

@bejito
Copy link
Author

bejito commented Oct 15, 2019

Actually, originalname seems to read it, but the value it exposes just contains bunch of � for non ascii charactes

@jonchurch
Copy link
Member

jonchurch commented Jan 15, 2020

Hmmm, this interesting.

Can you send a minimal reproduction of this issue? Specifically the non ascii character issue. Multer uses Busboy to deal with handling file uploads under the hood.

I'm not entirely sure if the originalname field is messed with anywhere along the way that could reproduce this issue. But if you can send an example maybe we can step through it and find out what's happening.

Thanks!

@ryhinchey
Copy link

This might have something to do with file encoding. See #434

#399 might solve this

@erano067
Copy link

erano067 commented May 17, 2022

After some debugging, the problem is in Busboy:

image

In my example the header of 'content-disposition' is set to:
form-data; name="doc"; filename="��פס101.pdf"; filename*=UTF-8''%D7%98%D7%95%D7%A4%D7%A1101.pdf
making a double filename fields.

Then in the for loop it takes the ugly first filename and convert it to utf-8, in that stage the filename variable looks good.
but then it makes another iteration and overwrite filename with the result of this function:
filename = decodeText(parsed[i][1], 'binary', 'utf8');

when we call that function in the second time we send it a 'utf-8' string, and tells it to decode the text from source = 'binary' to target = 'utf-8'.
And that makes the ugly � �question � � marks � �.

I will open an Issue in busboy and then we need to bump multer's busboy dependency.

for now as a workaround I managed to send the filename alongside the file itself like this:

image

hope it helps!

@erano067
Copy link

After some more investigation multer uses busboy version ^0.2.11 which gives 0.2.14.
as for now busboy have a 1.6.0 version and by the looks of it it seems busboy implements the filename*=UTF-8''... feature of content-disposition.

so to solve this issue we just need to migrate to higher version of busboy.

@erano067
Copy link

I created a PR #1092 to bump up busboy version, please approve

@LinusU
Copy link
Member

LinusU commented May 29, 2022

Version 1.4.4-lts.1 is released with the latest version of Busboy. Does this solve this problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants