Ahh, thanks. All I saw was NS_ConvertUTF8toUTF16() in nsString.h. The "Mozilla String Guide" does not reference the functions in nsStringAPI.h. I suppose I need to do a better job of grep-ing the include directory of the SDK.
Yeah, the string guide (http://www.mozilla.org/projects/xpcom/string-guide.html) is mainly written for mozilla developers, less so for embeddors... See also the note it has at the top:
" If you are a Mozilla embedder or if you are writing an XPCOM component that will be distributed separately from the Mozilla code base, then this string guide is most likely not for you! Provided you are developing against Mozilla 1.7 or later, you should instead be using the new minimal Mozilla string API and in particular the nsEmbedString class."
(which links to http://lxr.mozilla.org/mozilla/source/xpcom/string/public/nsStringAPI.h and http://lxr.mozilla.org/mozilla/source/xpcom/string/public/nsEmbedString.h)
Hm... darin: isn't nsEmbedString replaced by other string classes (nsString) on trunk?
Anything that's two-byte is UTF-16 in Mozilla. This means all AString and all wstring and all PRUnichar* is in UTF-16.
Thanks. I suppose I should know that from the above-mentioned String guide.
I hope the guide mentions it, although I find it possible that it doesn't :-)
Ah, it does, Chapter 7: "A 8-bit string can be in one of many character encodings while a 16-bit string is always in UTF16."
When I come across them, I will. I don't remember off-hand where I've run into confusion
Thanks.
Ahh, wasn't aware of that. I was looking at NS_NewURI().
Ah, yes. NS_NewURI is just a fancy wrapper around nsIIOService::NewURI :) There's also a NS_NewURI variant taking a wide string, but all that does it convert it to UTF-8 and pass that to the other version.
To be honest, a function that created it from a UTF-16 string would be better, but I can just do the conversion myself :)
Yeah, I dunno, I guess for some people UTF-8 is better while for some UTF-16 is... and offering two versions that only differ in the charset is probably not worth it.
This is actually better than doing the string conversion/comparison myself, as when the URI is built, it appears to replace 'space' with %20 so my comparison was failing (I was using system libraries on mac to convert from UTF-8 to UTF-16 and then compare. Of course I'd rather use the platform-independent solution).
Ah, yes. There's also another question: Are http://foo:80/ and http://foo/ equal? Since it's the default port, they really are. I think the nsIURI functions handle this.
_______________________________________________
mozilla-embedding mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-embedding
