GNOME Bugzilla – Bug 556369
Replying an email, the Content-Type header is not the right one
Last modified: 2021-05-19 11:56:23 UTC
Replying an ASCII email with this header: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT give this result on the new email : Content-type: text/plain Content-transfer-encoding: 8BIT That means ISO-8859-1 charset setting is lost.
Created attachment 120629 [details] The test case for iconv
This is caused due to the different behavior between Solaris iconv and GNU iconv. I attached a test case which you can use to see the error result of iconv in Solaris and Linux. This test case comes from the man page of iconv. You can also run the test case in Linux and you can find that the bug doesn't exist on Linux. The content of data.txt should be able to be encoded to ISO-8859-15 successfully. But the fact is sometimes it can also be encoded to US-ASCII, which is not correct. How to run the test case: Save the attachment test_case.tar to your home directory. extract the tar file: tar xvf test_case.tar, all files are under $HOME/test-case run a.out on x86: ./a.out utf-8 us-ascii < data.txt, convert the file data.txt from utf-8 to us-ascii. Please note, the output result is related with the length of the in buffer length and out buffer length for the function iconv on Solaris. If 'in buffer' length is 1024, iconv returns -1 and errno is 7, which causes the bug. But if 'in buffer' length is 256, iconv return 4 and the conversion failed. Hence, the conversion of iconv is related with the length of the buffer lengths. This behavior doesn't happen on Linux. On Linux, an illegal character or sequence will occur and the conversion stops.
Created attachment 120630 [details] [review] This patch disables the conversion to US-ASCII like Thunderbird.
perhaps a better fix would just be to not use iconv for ascii testing? it should be trivial to write a function to check if a string of bytes is us-ascii
Jeff Cai, May be Fejj's solution seems appropriate. Can you rework on that?
Okey. Shuai will rework the patch.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.