On 5/5/2011 00:38, Adam Martinson wrote:
dlls/msxml3/domdoc.c | 85 +++++++++++++++++++++++++++++-------------------- 1 files changed, 50 insertions(+), 35 deletions(-)
You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding.
Also will it preserve existing document or will really create empty one on error is a question.
On 05/04/2011 05:56 PM, Nikolay Sivov wrote:
You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding.
This is to avoid calling domdoc_loadXML() from domdoc_load(). When we need almost identical behavior from 2 separate interface functions having a common internal function they both call makes sense to me...
Also will it preserve existing document or will really create empty one on error is a question.
Yes, that's something we should add tests for in the future.
On 5/5/2011 18:09, Adam Martinson wrote:
On 05/04/2011 05:56 PM, Nikolay Sivov wrote:
You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding.
This is to avoid calling domdoc_loadXML() from domdoc_load(). When we need almost identical behavior from 2 separate interface functions having a common internal function they both call makes sense to me...
My point is that we already have doparse(This, str, len, "UTF-8"); that does exactly what you need. Side effects like setting creating xmlDocNew(NULL) are handled later in ::load() too. Also ::loadXML() takes BSTR that's always UTF-16, and we don't do it right now - cause it's possible to avoid conversion it seems. Adding load_utf8 will mean we stick to the utf16 -> utf8 conversion in loadXML.
On 05/05/2011 09:21 AM, Nikolay Sivov wrote:
On 5/5/2011 18:09, Adam Martinson wrote:
On 05/04/2011 05:56 PM, Nikolay Sivov wrote:
You don't need a separate helper for that. doparse() should do fine with "UTF-8" encoding parameter to force encoding.
This is to avoid calling domdoc_loadXML() from domdoc_load(). When we need almost identical behavior from 2 separate interface functions having a common internal function they both call makes sense to me...
My point is that we already have doparse(This, str, len, "UTF-8"); that does exactly what you need. Side effects like setting creating xmlDocNew(NULL) are handled later in ::load() too. Also ::loadXML() takes BSTR that's always UTF-16, and we don't do it right now - cause it's possible to avoid conversion it seems. Adding load_utf8 will mean we stick to the utf16 -> utf8 conversion in loadXML.
My logic for having this function: domdoc_load() is basically a more flexible version of domdoc_loadXML() that takes a VARIANT instead of a BSTR, and treats its input as a file of some sort. But VT_ARRAY|VT_UI1 case is just a non-null-terminated string, which is more like what domdoc_loadXML() does. To me it makes sense to merge this case with the internal domdoc_loadXML() implementation.
I vaguely remember trying to avoid the conversion in domdoc_loadXML() and just passing the BSTR to doparse() with encoding="UTF-16", and running into some quirk in libxml... If memory serves it was that when there's a <?xml encoding="foo"?> declaration in the string that doesn't match the actual encoding, libxml had a fit if the actual encoding wasn't UTF-8. eg, passing a UTF-16 string that contained <?xml encoding="UTF-8"?> caused an error, but passing a UTF-8 string that contained <?xml encoding="UTF-16"?> did not. It's been a while though, it may be worth another look.
-
Adam Martinson -
Nikolay Sivov