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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
