-
-
Notifications
You must be signed in to change notification settings - Fork 147
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
Decoding the subject with iconv_mime_decode() #410
Comments
Hi @freescout-helpdesk , Best regards & happy coding, |
@Webklex |
Hi @nuernbergerA , If the issue persists, please head over to https://github.com/Webklex/php-imap/issues/new?assignees=&labels=&projects=&template=bug_report.md and provide as much information as possible. Every little bit, even if it might seem unrelated could help to solve the mystery :) Best regards & happy coding, |
@Webklex i've opened a PR with a failing test for my issue ;) |
We've checked. This our function https://github.com/freescout-helpdesk/freescout/blob/dist/app/Misc/Mail.php#L883C8-L883C8 also successfully works for decoding headers and attachment names including your example:
|
@nuernbergerA thanks for your input and your pull request. Please update to v5.5 and give it another try :) @freescout-helpdesk how are you decoding attachment names / filenames? If you are relying on Best regards & happy coding, |
We are using the same our MailHelper::decodeSubject() function to decode attachment names - it works fine. |
I have a related problem. I received an email with an attachment, whose filename is "iso-8859-1''Elk%FCld%F6tt%20felsz%F3l%EDt%E1s%20ELK-F-24011370.pdf" The filename gets decoded as Elk�ld�tt felsz�l�t�s ELK-F-24011370.pdf After url decoding the string it should be converted to UTF-8:
It should be something like:
I am not sure of the implications, so I haven't done a pull request yet. |
Actually it seems that the first part of the code is not equivalent to the RFC 2231 Specification, where a string can be represented like
So I think, this:
may be replaced with:
|
My pull request did not pass the following test: The assertion in the test assumes that the output filename of Maybe I am missing something, but should this be the intended behaviour (leaving the original encoding as is), how can I get the encoding of the filename in the Attachment class, so I can convert it myself if needed? |
Describe the bug
Currently Webklex/php-imap by default uses 'utf-8' decoder and
\imap_utf8()
function to decode subject:php-imap/src/Header.php
Line 424 in abf080e
This approach does not always decode subjects properly.
For example
Subject: =?ISO-2022-JP?B?GyRCIXlCaBsoQjEzMhskQjlmISEhViUsITwlRyVzGyhCJhskQiUoJS8lOSVGJWolIiFXQGxMZ0U5JE4kPyRhJE4jURsoQiYbJEIjQSU1JW0lcyEhIVo3bjQpJSglLyU5JUYlaiUiISYlbyE8JS8hWxsoQg==?=
will be decoded into garbled string:�$B!yBh�(B132�$B9f!!!V%,!<%G%s�(B&�$B%(%/%9%F%j%"!W@lLgE9$N$?$a$N#Q�(B&�$B#A%5%m%s!!!Z7n4)%(%/%9%F%j%"!&%o!<%/![�(B
So it does not make much sense to use by default the approach which is not 100% reliable.
Some time ago we've switched to decoding the subject simply with
iconv_mime_decode()
:It works always and properly - freescout-help-desk/freescout#2965 (comment).
So maybe it worth making
iconv_mime_decode()
the default and the only approach for decoding the subject like this: https://github.com/freescout-helpdesk/freescout/blob/master/overrides/webklex/php-imap/src/Header.php#L208Function:
https://github.com/freescout-helpdesk/freescout/blob/dist/app/Misc/Mail.php#L909 (
decodeSubject()
)Related issue: Webklex/laravel-imap#295
The text was updated successfully, but these errors were encountered: