[Kde-pim] [patch] vcard parsing in KDE3.5

[Martin Koller]

Hello,

On Sunday 06 January 2008, Kevin Krammer wrote:
> On Sunday 06 January 2008, Tobias Koenig wrote:

> > Well, in KDE4 the input for the vCard parser is a QByteArray, in other
> > words plain data without previous convertion. In KDE3 the vCard parser
> > expects a QString, so you always need at least one convertion from the
> > raw data (QCString) to QString. From your patch it looks like to always
> > use latin1. Are you sure that doesn't remove any information from the
> > input data?

To make sure it will work, I had a look into QString::latin1()

In fact it loops over each QChar and checks if its <= 255 (otherwise it would 
set '?')
But as the input is an unconverted string (at least after I changed some 
QTextString::setEncoding from UTF8 to Latin1), this must be the case.
(And if it's not, the vcardparser would not work anyway, as a probably given 
CHARSET could not be handled)
So I see this as a safe operation.

The only problem would arise if some application would pass an already decoded 
string as unicode string and no CHARSET attribute is given in the vcard.
Then the previous code (sometimes) would have used the string as given, but 
the new implementation would try to convert the latin1-representation seen as 
UTF-8 into unicode again - which would of course result in wrong data.

On the other side, such a situation would have not worked up till now also, 
e.g. if an "encoding" attribute was given, it called local8Bit() ... which 
used CodecForLocale and therefore did some arbitrary conversion ...

And if "utf-8" was given as CHARSET the old implementation assumed the same as 
I do now with latin1() (it used ascii() which is the same if no 
codecForCString was set)

So the only problematic step might be this:
-          vCardLine.setValue( value );
+        } else {  // if charset not given, assume it's in UTF-8 (as used in 
previous KDE versions)
+            vCardLine.setValue( QString::fromUtf8( output ) );

and if you really see this as needed, I could add the following workaround:
Convert given QString to latin1(), convert back to QString, check if still 
equal with given string. If so, use "fromUtf8", else use given string.

> > The right fix would be to use QCString as input data for vCard parser,
> > however that's not possible because it's SIC/BIC. (I know, bad design
> > in 3.x cycle...)

> Since the methods in VCardParser are not virtual but static, it should be
> BC to add another set of static methods which take QByteArray or QCString
> as their argument and implement them properly.
>
> Any code under our control (e.g. thumbnailer, KAddressBook) can then be
> ported to this new methods, thus fixing the bug, while the two older
> methods keep their current functionality, thus keeping any programs which
> use them unchanged as well.

As I already changed the places where the file content was read, I can now be 
sure that always latin1 strings (plain C byte arrays) are passed via the 
given QString.

So for KDE internals it should not make any difference (except for a cleaner 
API) ... but who cares as KDE4 has already solved it in a clean way ?

To change it in a cleaner way would require a hell lot of more changes as the 
vcard data is passed around as QString, e.g. from VCardConverter to VCardTool 
to VCardParser ... is it worth the effort for KDE3 ?

-- 
Best regards/Schöne Grüße

Martin    ()  ascii ribbon campaign - against html mail 
          /\                        - against microsoft attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080106/9d3d3782/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/