--===============0689981800==
Content-Type: multipart/signed;
  boundary="nextPart2475960.oe7CDbvT10";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart2475960.oe7CDbvT10
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 <=3D 255 (otherwise it w=
ould=20
set '?')
But as the input is an unconverted string (at least after I changed some=20
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 give=
n=20
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 deco=
ded=20
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=
=20
the new implementation would try to convert the latin1-representation seen =
as=20
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,=
=20
e.g. if an "encoding" attribute was given, it called local8Bit() ... which=
=20
used CodecForLocale and therefore did some arbitrary conversion ...

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

So the only problematic step might be this:
=2D          vCardLine.setValue( value );
+        } else {  // if charset not given, assume it's in UTF-8 (as used i=
n=20
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=
=20
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=20
sure that always latin1 strings (plain C byte arrays) are passed via the=20
given QString.

So for KDE internals it should not make any difference (except for a cleane=
r=20
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 t=
he=20
vcard data is passed around as QString, e.g. from VCardConverter to VCardTo=
ol=20
to VCardParser ... is it worth the effort for KDE3 ?

=2D-=20
Best regards/Sch=F6ne Gr=FC=DFe

Martin    ()  ascii ribbon campaign - against html mail=20
          /\                        - against microsoft attachments

--nextPart2475960.oe7CDbvT10
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBHgTtlUeHBRvgua64RAthjAJwKh/CGQ5N107DtrivT3ADku6gG3wCfX3P6
qhF/iA5BOyqs4/o1fFIdEvc=
=378N
-----END PGP SIGNATURE-----

--nextPart2475960.oe7CDbvT10--

--===============0689981800==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
--===============0689981800==--