[Kde-pim] decodeRFC2047String

[Ingo Klöcker]

On Monday 24 August 2009, Martin Koller wrote:
> On Monday 24 August 2009, Ingo Klöcker wrote:
> > > For the rest of your comments, I understood that there would only
> > > be a need for a change if one would change decodeRFC2047(), right
> > > ?
> >
> > Not really. Using KUrl::fromPercentEncoding() is superfluous in any
> > case. So the patch can be reduced to
> > -          contents.append( (*it).path() );
> > +          contents.append( KMime::decodeRFC2047String(
> > (*it).path().toUtf8() ) );
>
> I copied this snippet from kmails stringutil.cpp
> Does this mean that its function
>
> QString decodeMailtoUrl( const QString& url )
> {
>   QString result;
>   result = KUrl::fromPercentEncoding( url.toLatin1() );
>   result = KMMsgBase::decodeRFC2047String( result.toLatin1() );
>   return result;
> }
>
> is wrong, too ?

I suppose the method works for the use case it was written. Whether this 
makes sense or not really depends on what url is. Hmm, the API docs of 
this method are not really helpful because they say nothing about what 
url should be.

The usage in MailToURLHandler::statusBarMessage() might be correct for 
mailto-URLs created by KMail itself, but for mailto-URLs with query 
part included in HTML messages it might not do what it is expected to 
do.

Regarding the usage in KMail::StringUtil::parseMailtoUrl() the line
>   result = KUrl::fromPercentEncoding( url.toLatin1() );
is nonsense (because url is already decoded) and it might even break in 
case of international domain names.
The same problem exists for the usage in KMLineEdit::dropEvent(), 
KMMailtoComposeCommand::execute(), KMMailtoReplyCommand::execute(), 
KMMailtoForwardCommand::execute(), 
KMMailtoAddAddrBookCommand::execute(), 
KMMailtoOpenAddrBookCommand::execute(), and 
KMUrlCopyCommand::execute(). In all those methods the return value of 
KUrl::path() is passed to decodeMailtoUrl().

As far as I can tell the method can be replaced by
  QString decodeMailtoUrl( const QString& url )
  {
    return KMMsgBase::decodeRFC2047String( url.toLatin1() );
  }
and the usage in MailToURLHandler::statusBarMessage() should probably be 
fixed by passing url.path() instead of url.url() to decodeMailtoUrl().


> And it needs to use toUtf8() also ? 

I guess that's debatable. I would use toUtf8() instead of toLatin1(). In 
particular considering that the API docs for KUrl::url() read

  Returns the URL as string, with all escape sequences intact, encoded
  in a given charset. 
  This is used in particular for encoding URLs in UTF-8 before using
  them in a drag and drop operation.


> > BTW, discussing the patch would be much easier if it were on Review
> > Board (even if it seems to be overkill for such a short patch). ;-)
>
> If the standard KDE browser, konqueror, would be able to deal
> correctly with the reviewboard, I would use it.

Hmm, I hoped it would work with Konqueror 4.3.


> BTW: wouldn't is be much simpler in the end if you fix the function ?

Not really, since I haven't build KDE since Akademy. :-/


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090824/af6a1d50/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/