After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 485677 - There's no need to be so hard on iconv
There's no need to be so hard on iconv
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Mailer
unspecified
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-10-11 09:50 UTC by Philip Van Hoof
Modified: 2021-05-19 11:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix (708 bytes, patch)
2007-10-11 09:51 UTC, Philip Van Hoof
needs-work Details | Review
Ignoring a check (584 bytes, patch)
2007-10-11 10:15 UTC, Philip Van Hoof
needs-work Details | Review

Description Philip Van Hoof 2007-10-11 09:50:57 UTC
In case iconv does not succeed in decoding for example the Subject header, it returns the base64 encoded one. That is is obviously not readable at all. The decoded one after base64 decoding (which did succeed in my test case) or whatever iconv could recover from it, sounds like a better option.

This changeset (patch) on camel-mime-utils.c deals with the error situation (in case iconv did not return -1) by returning what(ever) iconv could recover from the string:

http://tinymail.org/trac/tinymail/changeset/2830#file2

I attached:

svn diff libtinymail-camel/camel-lite/camel/camel-mime-utils.c -r 2829 > /home/pvanhoof/diff.diff

This is the Subject line of my test target:

Subject: =?ISO-2022-JP?B?GyRCM048QiRLOkdEY0Z8NWsbKEI=?=
        =?ISO-2022-JP?B?GyRCIzJLfDFfIUFGfEonJCQkRyQqRU8kN0NXJDckXiQ5ISMlYSE8GyhC?=
        =?ISO-2022-JP?B?GyRCJWslXiUsJTglcxsoQg==?=
Comment 1 Philip Van Hoof 2007-10-11 09:51:24 UTC
Created attachment 97043 [details] [review]
Fix
Comment 2 Philip Van Hoof 2007-10-11 10:15:23 UTC
Created attachment 97044 [details] [review]
Ignoring a check

This does not obsolete the first patch, this is yet another one
Comment 3 Jeffrey Stedfast 2007-10-11 15:17:19 UTC
it would probably be better to lift code from GMime as it solves these problems and more.

you'll want to look at gmime-utils.c:

decode_8bit()
quoted_decode()
rfc2047_decode_word()
g_mime_utils_header_decode_text()
g_mime_utils_header_decode_phrase()

you'll also want to check out gmime-charset.c for:

g_mime_user_charsets()
Comment 4 Philip Van Hoof 2007-10-12 12:11:25 UTC
The second patch removes too much. The len<8 check should not be removed, for example.
Comment 5 Srinivasa Ragavan 2007-11-01 12:45:59 UTC
mbarnes, can you get in here to see/do what is required? Does it make sense to push the first patch still? or we should lift the code from GMIME?
Comment 6 Philip Van Hoof 2008-01-22 20:14:25 UTC
Note that camel-mime-utils.c got ported from GMime very recently by Jeffrey. This fix will most likely not be valid anymore (please check with Jeffrey on this).
Comment 7 Srinivasa Ragavan 2008-02-01 08:43:27 UTC
Fejj, is this patch still reqd?
Comment 8 Philip Van Hoof 2009-01-06 22:49:13 UTC
Ping, what is the decision on this one?
Comment 9 Matthew Barnes 2009-01-07 01:19:24 UTC
My vote is to pull from GMime, if the issue hasn't already been addressed.

Best ping Jeff on IRC; looks like he removed himself from the CC list here.
Comment 10 Matthew Barnes 2009-11-19 22:36:32 UTC
Marking the first patch as "needs-work" to get it off our unreviewed list.
Comment 11 André Klapper 2021-05-19 11:03:49 UTC
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 ticket at
  https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/

Thank you for your understanding and your help.