I've mentioned this problem to Thomas Habing before,
but I think it might be
a good idea to document it in the archives.
The VB binding which returns a raw data record returns
an 8-bit string in a
variant data structure using the following code :-
ptr = zoom_yaz_c_function_getting_pointer
RawData = CVar(CopyString(ptr))
where CopyString eventually calls lstrcpy.
All this is fine!
IDispatch and COM
and this converts the 8-bit character string into 16-bit
wchar Unicode by
calling an API function which assumes the string is
Windows 1252 (or even
worse 1250 et al.) and converts the characters in the
range hex 80 to 9F
into their Unicode equivalents (and they are NOT the
The effect is to totally screw up ISO5426 encoding.
server where I convert the Unicode back into 8-bit bytes
Windows1252), extract the MAB data (which is NOT the
same as ISO2709) or
Unimarc data convert the ISO5426 or other like 8898-1
into UTF-8 and build
an XML tree like in Marc21 (or with SUTRS just convert
to UTF-8), send back
to the browser for display (I'm actually using VB Zoom in
IE 6.0 using XML
I have placed a question in
Robert Sanderson wrote "...Z.39.50 is not hard..."
I'd agree, if it weren't for all the options, character set,
possibilites I have to watch out for!