[Interest] QDateTime + QXmlStreamWriter on non-UTF8 compatible systems
Thiago Macieira
thiago.macieira at intel.com
Sun Dec 24 03:02:55 CET 2017
On sexta-feira, 22 de dezembro de 2017 19:30:39 -02 Scott Bloom wrote:
> Completely disagree. The documentation clearly states the encoding is
> written out, and its not. That is a problem. The assumption is that the
> QString will be the final destination, that assumption is not documented,
> and not always true.
What would you have it write?
> If its not true, the client of the call, will potentially have a bug in
> their code, depending on how the QString is used later on.
Right. And hence the problem: if we don't know how you'll encode it, what
would you have QXmlStreamWriter say the encoding is?
> Which is exactly what happened to me. There is no explanation why a QBuffer
> vs QString would produce different XML.
There is an explanation. I've already said it multiple times. I understand
you're frustrated and the documentation can be made clearer, but there is a
very logical reason.
> For QA purposes, our XML generating classes, always had the internal
> "generate XML to a string" function so that we didn't have to create any IO
> in our unit testing.
>
> I clearly see, to create proper XML that supports UTF-16 encoding, I needed
> to use a "Generate XML to an QIODevice*" methodology, since QIODevice
> create a proper XML file, and QString does not.. Not a problem, but
> completely undocumented.
Incorrect. The XML that QString generates *is* proper. It just doesn't say
what the encoding is, since it's already in Unicode and requires no decoding.
Wh'ats more, even if you convert to 8-bit, it's still valid and proper XML,
since there is a default encoding for it, which you have to use (UTF-8) or you
have to provide an external encoding mechanism. Writing that the encoding is
"utf-8" when it's in QString form would be factually incorrect; writing the
factually correct "utf-16" would be a hindrance if you tried to save to a file
as 8-bit.
I repeat: the problem is not QXmlStreamWriter, but how you parsed that
QString, including any transformations to 8-bit that you may have done.
If you had fed it directly to QXmlStreamReader or QDomDocument::setContent, it
should have decoded properly. If that didn't work, we have a bug and it needs
to be fixed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest
mailing list