<br><font size=2 face="sans-serif">Hi all</font>
<br>
<br><font size=2 face="Arial">For experimental purpose I added a "UTF-8
-> ISO-8859-Conversion" </font>
<br><font size=2 face="Arial">in two functions of mapscript_wrap.c</font>
<br><font size=2 face="Arial">The functions are the JNI-Implementations
of mapObj.getLayerByName and </font>
<br><font size=2 face="Arial">layerObj.queryByAttributes.</font>
<br>
<br><font size=2 face="Arial">I testet with the QueryByAttribute-Program
Umberto send and with a Shapefile (no database).</font>
<br><font size=2 face="Arial">I tested to find the layer named "</font><font size=2><tt>ÜÄÖßäüö</tt></font><font size=2 face="Arial">"
and in this layer the regular-expression</font>
<br><font size=2><tt>"Süden</tt></font><font size=2 face="Arial">".</font>
<br>
<br><font size=2 face="Arial">On my Windows-machine the results seem to
be correct for the Command-Line-</font>
<br><font size=2 face="Arial">parameter-case and for the hardcoded-case</font>
<br>
<br><font size=2 face="Arial">The implementation is experimental only.
If strings are longer than 500 chars,</font>
<br><font size=2 face="Arial">unforeseeable things may happen. In practice
one should think twice wether to</font>
<br><font size=2 face="Arial">use this kind of implementation or to use
the build-in Java-encoders from JNI level.</font>
<br>
<br><font size=2 face="Arial">But the really difficult question is how
anything like this could be reasonably incorporated </font>
<br><font size=2 face="Arial">with swig. I have no idea!</font>
<br>
<br><font size=2 face="Arial">Umberto? What do you think?</font>
<br>
<br><font size=2 face="Arial">Norbert: To be honorable, I don't think it
is promising to change the Strings in the </font>
<br><font size=2 face="Arial">higher Java-level. </font>
<br>
<br><font size=2 face="Arial">For some days code with example can be dowloaded
from</font>
<br><font size=2 face="Arial">http://www2.hydrotec.de/webdemos/be/umlaute.zip</font>
<br><font size=2 face="Arial">(Compiled mapscript.dll is included. Other
dll's can be used from normal </font>
<br><font size=2 face="Arial">mapserver 4.8.2)</font>
<br>
<br><font size=2 face="Arial">Benedikt</font>
<br>
<br><font size=2 face="Arial">PS: I think of this as a bug in mapserver.
Should a bug in bugzilla be opened?</font>
<br>
<br><font size=2><tt>listuser HH <listuser@herzsys.de> schrieb am
19.04.2006 10:05:13:<br>
<br>
> Hi Benedikt,<br>
> <br>
> thanks for the interest. I have the encoding problem when I try to
<br>
> "getLayerByName()". I could get around the problem at this
point but I <br>
> think I will have the problem later again. So testing is easy - I
just <br>
> use a simple layer with the name "Regierungspräsidien".
When I use this <br>
> string to get the layer by name it doesn't work. To be sure I tried
to <br>
> check this string with the name of the layer which I get from <br>
> map.getLayer(0) - which is equal to the other.<br>
> <br>
> My thought was to convert the string before using it in mapscript
<br>
> functions. Java brings two things to convert strings - perhaps there
are <br>
> more.<br>
> <br>
> 1. make a new String from the old in a special encoding - e.g. -->
new <br>
> String(oldString.getBytes(), "ISO8859-1")<br>
> 2. convert chars to different encoding - e.g. [snip] --><br>
>                    
    CharToByteISO8859_1 conv4ISO = new <br>
> CharToByteISO8859_1();<br>
>                    
    char[] cs = layerName.toCharArray();<br>
>                    
    conv4ISO.convert(charArray, 0, charArray.length, <br>
> byteArray, 0, byteArray.length);<br>
>                    
    new String(byteArray);<br>
> <br>
> Because I'm not sure about which encodings are used at wich stpes
I <br>
> tried some combinations but without luck. I think my code from eclipse
<br>
> is CP1252. In the eclipse editor properties I changed this to UTF8
and <br>
> ISO which also didn't work. I tried to I'm not sure what happens when
<br>
> mapscript use JNI. Perhaps the string gets converted to UTF8. If this
is <br>
> right I see no chance for me to change the string in java because
it <br>
> gets converted even if it is already UTF8. I have to say that I'm
not <br>
> familiar with this encoding things. If someone has an advice I will
<br>
> going on testing.<br>
> <br>
> I think it will be a good thing to have "UTF-8 -> ISO-8859-Conversion"
<br>
> like you suggested. At the moment I can't do this because I have no
<br>
> possibility to compile the c code.<br>
> <br>
> Best regards,<br>
> <br>
> Norbert<br>
> <br>
> Benedikt Rothe wrote:<br>
> <br>
> >Umberto, Nicol, Norbert, Oliver<br>
> ><br>
> >Umberto wrote<br>
> >  <br>
> ><br>
> >>try to run the attached Java source. <br>
> >>    <br>
> >><br>
> >...<br>
> >  <br>
> ><br>
> >>"Südliche Weinstraße" as the second it will work!<br>
> >>    <br>
> >><br>
> ><br>
> >In my copy of your mail the queryByAttribute.java-program is not
<br>
> >attached.  Could somebody post program including testdata
(or <br>
> >download-url) ?<br>
> ><br>
> >I 'd like to study a running example, because I don't understand
<br>
> >how umlaut-conversion from Java to Mapserver-kernel can run <br>
> >properly anyway and I'd like to understand it :-)<br>
> >-----------<br>
> >It seems Norbert found a kind of answer to his question <br>
> >  <br>
> ><br>
> >>is there a way to do the converion in java dircetly?<br>
> >>    <br>
> >><br>
> >He suggested<br>
> >  <br>
> ><br>
> >>Try to convert the String before you set the expression in
your code(-> <br>
> >>    <br>
> >><br>
> >String( byte <br>
> >  <br>
> ><br>
> >>bytes[], String ) <br>
> >>    <br>
> >><br>
> >Could you be more precisly? I do not understand what must be converted
to <br>
> >what.<br>
> >How must this be applied to convert a Java-String to a proper
<br>
> >"Mapserver-String" (?)<br>
> >-----------<br>
> >Is somebody willing to try to add an "UTF-8 -> ISO-8859-Conversion"
in<br>
> >mapscript_wrap.c for testpurposes? (Even in the case it works,
this would <br>
> >not be a real solution because it bypasses swig.)<br>
> ><br>
> >Benedikt<br>
> ><br>
> ><br>
> >UMN MapServer Users List <MAPSERVER-USERS@LISTS.UMN.EDU>
schrieb am <br>
> >14.04.2006 15:23:51:<br>
> ><br>
> >  <br>
> ><br>
> >>Olivier,<br>
> >>I GOT IT!<br>
> >><br>
> >>try to run the attached Java source. If you pass it two arguments
the<br>
> >>first being the path to the map file and the second the string
to<br>
> >>search for and you pass<br>
> >>"Südliche Weinstraße" as the second it will work!<br>
> >><br>
> >>So why does it fail when "Südliche Weinstraße" is
inside the Java<br>
> >>code? That is a problem that only happens when javac compiles
the<br>
> >>source: javac translates all characters to unicode and in
doing that<br>
> >>it gets the german characters wrong.<br>
> >>To solve this give javac the following option: -source 1.4<br>
> >><br>
> >>For more see this link:<br>
> >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5046139<br>
> >><br>
> >>On 4/13/06, Umberto Nicoletti <umberto.nicoletti@gmail.com>
wrote:<br>
> >>    <br>
> >><br>
> >>>This is probably not related only to java mapscript, so
please read <br>
> >>>      <br>
> >>><br>
> >on.<br>
> >  <br>
> ><br>
> >>So I was wrong...but I'll leave the proof to the reader ;-)<br>
> >><br>
> >>Best regards,<br>
> >>Umberto<br>
> >><br>
> >>    <br>
> >><br>
> >>>On 3/30/06, Oliver Wesp <wesp@gdv.com> wrote:<br>
> >>>      <br>
> >>><br>
> >>>>Dear List,<br>
> >>>><br>
> >>>>I' struggling with queryByAttributes on an attribute
field with <br>
> >>>>        <br>
> >>>><br>
> >german<br>
> >  <br>
> ><br>
> >>>>umlauts using java mapscript.<br>
> >>>>The odd thing is that the same thing works fine with
php mapscript <br>
> >>>>        <br>
> >>>><br>
> >and<br>
> >  <br>
> ><br>
> >>>>when I use expressions in my  mapfile. I'm using
a shapefile as <br>
> >>>>        <br>
> >>>><br>
> >>datasource.<br>
> >>    <br>
> >><br>
> >>>Could someone of the other mapserver developers shed some
light on<br>
> >>>      <br>
> >>><br>
> >>this issue?<br>
> >>    <br>
> >><br>
> >>>I have a clue to give: php mapscript is using a different
regex<br>
> >>>library and this explains why the match does not happen
for Java<br>
> >>>mapscript, while it does happen in php mapscript. If I
am right also<br>
> >>>the mapserver cgi should be affected and possibly all
other mapscript<br>
> >>>too.<br>
> >>><br>
> >>>It would be very interesting if someone could report on
similar<br>
> >>>experiences with the cgi-bin version of mapserver.<br>
> >>><br>
> >>>Thanks,<br>
> >>>Umberto<br>
> >>><br>
> >>>      <br>
> >>><br>
> >>>>Here is what I do:<br>
> >>>><br>
> >>>>layer.queryByAttributes(map,"KREIS_NAME",
"/Südliche Weinstraße/",<br>
> >>>>mapscriptConstants.MS_MULTIPLE);<br>
> >>>>layer.open();<br>
> >>>>System.out.println( "Result Count: " +layer.getNumResults()
);<br>
> >>>>layer.close();<br>
> >>>><br>
> >>>>The result is always null while replacing the qstring
with something<br>
> >>>>that doesn't contain special characters (e.g.<br>
> >>>>'Mainz-Bingen') works fine.<br>
> >>>><br>
> >>>>As noted above the following layer definition in a
mapfile works <br>
> >>>>        <br>
> >>>><br>
> >fine<br>
> >  <br>
> ><br>
> >>>>LAYER<br>
> >>>>     NAME kreis<br>
> >>>>     STATUS DEFAULT<br>
> >>>>     TYPE polygon<br>
> >>>>     DATA "/tmp/subset"<br>
> >>>>     TEMPLATE "kreis.html"<br>
> >>>>     CLASSITEM KREIS_NAME<br>
> >>>>     CLASS<br>
> >>>>       NAME Boundary<br>
> >>>>       COLOR 128 128 0<br>
> >>>>       OUTLINECOLOR 0 0 0<br>
> >>>>       EXPRESSION /Südliche Weinstraße/<br>
> >>>>     END<br>
> >>>>END<br>
> >>>><br>
> >>>><br>
> >>>>but this does not:<br>
> >>>><br>
> >>>>layer.setClassitem("KREIS_NAME");<br>
> >>>>classObj cl = new classObj(layer);<br>
> >>>>cl.setName("Classname");<br>
> >>>>cl.setExpression("/Südliche Weinstraße/");<br>
> >>>><br>
> >>>>I use Mapserver 4.8.1 on W2k, Tomcat 5.0.28.<br>
> >>>><br>
> >>>>I can provide some sample data, just in case someone
likes to <br>
> >>>>        <br>
> >>>><br>
> >reproduce.<br>
> >  <br>
> ><br>
> >>>>Any help is appreciated.<br>
> >>>><br>
> >>>>best regards<br>
> >>>>Oliver<br>
> >>>>--<br>
> >>>>Dipl.-Geogr. Oliver Wesp<br>
> >>>>Gesellschaft fuer geografische Datenverarbeitung<br>
> >>>>Binger Strasse 49-51<br>
> >>>>D-55218 Ingelheim<br>
> >>>>fon: +49 6132 714818<br>
> >>>>fax: +49 6132 714828<br>
> >>>>http: www.gdv.com<br>
> >>>><br>
> >>>>        <br>
> >>>><br>
> ><br>
> >  <br>
> ><br>
> <br>
> <br>
</tt></font>