This may sound familiar to a problem from last year...
We have data stored in ArcSDE which we are accessing with Mapserver.
Strings are encoded in NSTRING (wide, UTF-16 encoded, etc).
Last year we had an issue on Linux where there was differences in the
default endianness for the UTF-16 to UTF-8 transcoding: glibc was assuming
local processor endianness (Intel) and libiconv was assuming
network endianness. This was solved with a patch to Mapserver to detect
the endianness and specify the right little or big endianness to iconv().
http://trac.osgeo.org/mapserver/ticket/2878
We are now noticing the same behavior with ms4w where characters coming
from the database through ArcSDE are coming out all garbled. The same
mapfiles talking to the same ArcSDE and underlying data works fine with
our Linux mapserver, but fails with ms4w.
I had one of the Windows users here test with the latest stable ms4w
which upgraded his MapServer from v. 5.2.0 to 5.2.1. The ticket above
indicates that the patch was backported to the 5.2 stream, but I don't
know if there may be differences in the Windows libraries. The issue is
ensuring that the conversion from UTF-16 to UTF-8 happens correctly.
Any thoughts?
Thank you for any help.
--
Russell McOrmond, Internet Consultant: <http://www.flora.ca/>
Please help us tell the Canadian Parliament to protect our property
rights as owners of Information Technology. Sign the petition!
http://digital-copyright.ca/petition/ict/ http://KillBillC61.ca
"The government, lobbied by legacy copyright holders and hardware
manufacturers, can pry control over my camcorder, computer,
home theatre, or portable media player from my cold dead hands!"
_______________________________________________
mapserver-users mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapserver-users
