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

the mime format problem #170

Open
lofonder opened this issue Jul 14, 2024 · 3 comments
Open

the mime format problem #170

lofonder opened this issue Jul 14, 2024 · 3 comments

Comments

@lofonder
Copy link

lofonder commented Jul 14, 2024

the
string_t mime::parse_header_value_attribute(const string& attr_value) const
only parsed the first line of the Content-Disposition

the mime data example:
`
Content-Type: application/pdf;

name*0*=UTF-8''py%E5%8E%BF%E7%BA%A7%E6%9C%BA%E6%9E%84%E7%A7%91%E6%8A%80;

name*1*=%9C%7D%E5%6A%A1%E9E7%BA%A7%E6%9C%BA%E6%9E%84%E7%E6%E6%8A%80.pdf

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename*0*=UTF-8''py%E5%8E%BF%E7%BA%A7%E6%9C%BA%E6%9E%84%E7%A7%91%E6%8A%80;

filename*1*=%E5%9D%8D%E5%8C%E7%BA%A7%E6%9C%BA%E6%9E%84%E7%A7%91%E6%8A%80;

filename*2*=pdf

`
the filename 1 and filename2 was recoginzed as the url code.
is it a bug?

I think it would be better if decode the filename in the function of the mime::merge_attributes?
cause I founded that the filename0 part was the nomal text decoded ,and the filename1 part was the text encoded.

@karastojko
Copy link
Owner

Let me check it.

@karastojko
Copy link
Owner

You are right, there is a bug. I am fixing it...

@karastojko
Copy link
Owner

Please try the latest commit. It should fix your problem although it is still not complete by the specification.

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

No branches or pull requests

2 participants