getRawBuffer gives garbled characters
I am trying to read Japanese String in an English locale.
The node contains Japanese characters is sent to this function.
As soon as I use getRawBuffer, the output contains garbled characters.
What is missing in the code? I want the original characters to remain same
void Node2String
{
DOMImplementation *impl =
DOMImplementationRegistry::getDOMImplementation(0);
DOMWriter* serializer = ((DOMImplementationLS*)impl)-createDOMWriter();
try {
MemBufFormatTarget *target = new MemBufFormatTarget();
serializer-writeNode(target, *node);
const XMLByte *output = target-getRawBuffer(); //here the
characters are garbled
target-flush();
serializer-release();
}
}
The original text has Japanese characters but after using getRawBuffer() the
output observed in debug mode is as follows
トップニューã
Re: getRawBuffer gives garbled characters
Hi Parag, Lele, Parag [EMAIL PROTECTED] writes: MemBufFormatTarget *target = new MemBufFormatTarget(); serializer-writeNode(target, *node); const XMLByte *output = target-getRawBuffer(); // here the characters // are garbled The original text has Japanese characters but after using getRawBuffer() the output observed in debug mode is as follows ããã?ã?ã??¥ã??¼ã The result in the buffer will be in whatever XML character encoding you have specified and if you didn't specify anything, then it will be UTF-8. Perhaps what you are seeing are your Japanese characters encoded in UTF-8? Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with libtool convenience libraries (3.0.0)
Hi Boris, from what I recall, convenience libraries are used because the sources are split into separate folders. On the other hand, we put in each convenience library sources coming from multiple folders (e.g. libdom.la contains files from xercesc/dom and xercesc/dom/impl; libutil.la contains files from xercesc/util and xercesc/util/regx; libframework.la from xercesc/framework and xercesc/framework/psvi; libvalidators.la from all the subfolders under xercesc/validators), defeating their purpose. As a side effect, this structure prevents Xerces from building on Cygwin with MS compilers, as the lib tool used to build convenience libraries doesn't behave like ar (it preserves the path used in the object file names, so that the linker will not find all the object files in a single folder after extracting the libraries). In the past I have tried to split the src/Makefile.am into one Makefile.am per folder, but everytime something broke; I have never attempted to get rid of the convenience libraries altogether, so I support the attempt to remove them and ask libtool to generate the final libraries in one step. Alberto Boris Kolpackov wrote: Hi, I just realized that the libtool/automake convenience libraries that are heavily used in the new build system have one major drawback: when both PIC and non-PIC objects are being built, the convenience library only contains the PIC versions. As a result, later, when the main library (libxerces-c in our case) is built, these PIC objects are used for both shared and static versions. This seems to me like a bad way to do it: the code in the static version is slower than it could be and a lot of time is wasted building the non-PIC objects which are then simply thrown away. I am by no means an autotools expert, but it appears that automake can handle sources in different directories just fine. In fact, sources for some of the convenience libraries are split into several sub-directories and therefore already rely on this feature. I am then wondering what is the purpose of all these convenience libraries? Since all of them but one (libcompat.la) are built from a single makefile (src/Makefile.am), there does not seem to be anything convenient about them. They also have the big drawback mentioned above. Does anyone (James?) see any potential problems in getting rid of them? The only thing that I can think of is the command line length limit on some platforms but then the build system in 2.x.y does not seem to have this problem plus the ar command line has all the objects listed explicitly. Any feedback would be very much appreciated. Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with libtool convenience libraries (3.0.0)
Alberto Massari [EMAIL PROTECTED] writes: I have never attempted to get rid of the convenience libraries altogether, so I support the attempt to remove them and ask libtool to generate the final libraries in one step. Ok, the code is in SVN. The build is now also quite tidy without all these intermediate libraries. Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp
Scott Cantor [EMAIL PROTECTED] writes: On Mac OS X, libcurl is present in the base system going back 2-3 major releases, so in this case no extra dependencies are dragged in. If you're taking votes (not that you are), +1 for libcurl on OS X. Ok, I've moved the curl net accessor up to take priority over socket. Now that the ICU message loader does not result in a separate library, I also made it take priority over inmemory when ICU is available. Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Xerces-C 2.9?
Hi Ozgur, Sahoglu, Ozgur [EMAIL PROTECTED] writes: Are we branching for 3.0 and 2.9? What is the version of the trunk? The 3.x.y code base is in the trunk. 2.x.y is in the xerces-2 branch: http://xerces.apache.org/xerces-c/source-repository.html Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp
Ok, I've moved the curl net accessor up to take priority over socket. Now that the ICU message loader does not result in a separate library, I also made it take priority over inmemory when ICU is available. There probably should also be a strong warning somewhere that not using ICU as a transcoder will give you problems on 10.5. My suggestion would be to make sure that any downstream packagers (e.g. macports) use ICU and not the CF calls. I don't know what the best way to do that is, but making ICU the default might be the simplest way. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp
Hi Scott, Scott Cantor [EMAIL PROTECTED] writes: There probably should also be a strong warning somewhere that not using ICU as a transcoder will give you problems on 10.5. You mean in case the application forks or are there other cases? My suggestion would be to make sure that any downstream packagers (e.g. macports) use ICU and not the CF calls. I don't know what the best way to do that is, but making ICU the default might be the simplest way. ICU will be used by default now for both transcoder and message loader if ICU is present on the machine. I remember somebody saying that ICU is installed on OS X by default so this should work out ok, right? Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r630254 - in /xerces/c/trunk: configure.ac m4/xerces_msgloader_selection.m4 m4/xerces_netaccessor_selection.m4 src/xercesc/util/PlatformUtils.cpp
You mean in case the application forks or are there other cases? I'm not about to conclude that there's only one system call that prevents them from being used. I don't take kindly to OS vendors breaking my code like that, so that tells me not to use their APIs. ICU will be used by default now for both transcoder and message loader if ICU is present on the machine. I remember somebody saying that ICU is installed on OS X by default so this should work out ok, right? It's installed but without headers. You have to use your own ICU. The one they include is for Apple use only. If it will use ICU by default if it's present (meaning the headers I assume), I think that's good. My opinion is that failing if it's missing would be even better. I'd rather have to manually tell the build to use broken APIs than have it do so silently. If somebody's packaging it and wants the CF calls, they can certainly do so. That's just MHO anyway. Either way, this is an improvement, thanks. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reconf problem
Hi all, I've been trying to test on various platforms for the 3.0 release. One recent issue I've noticed is that we require Autoconf 2.60: configure.ac:26: error: Autoconf version 2.60 or higher is required More recent Linux distributions are probably OK, but Solaris 10 x86 has 2.59, as does my Linux distribution at work. Is this a hard requirement? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
