Java Mapscript with Japanese Encoding

[Umberto Nicoletti]

Mario,
if you send me a sample shapefile, map and search string to test
against QueryByAttributeUnicode I'm willing to look into this.
Also, file an issue to bugzilla.

Umberto

On 8/31/06, Mario Basa <mario.basa at gmail.com> wrote:
> Umberto,
>
> Nope.
>
> I use Emacs to write my programs and it always tells you what encoding
> it uses at the bottom task bar. There is absolutely no way that it can
> be in any other format than Shift_JIS. Also, if I don't use the
> -encoding parameter whenever I compile, javac will complain since it
> won't know how to handle double byte characters.  These are so basic
> for us who uses kanji characters (and its numerous encodings) every
> single day.
>
> Anyway, I'll look at how QueryByAttributeUnicode is compiled.
>
> mario.
>
>
>
> On 8/31/06, Umberto Nicoletti <umberto.nicoletti at gmail.com> wrote:
> > On 8/31/06, Mario Basa <mario.basa at gmail.com> wrote:
> > > Hello Umberto,
> > >
> > > As always, thanks for the quick reply.
> > >
> > > Unfortunately, even if I change both LANG and LC_ALL to Shift_JIS,
> > > layer.getAttributes still can not get a match. It is only when the
> > > shapefile is in UTF-8 and when the tomcat environment is also in UTF-8
> > > can a match be found.
> > >
> > > I have a funny feeling that the query value is always converted to
> > > UTF-8 first before doing a search. Just a hunch though.
> >
> > My opinion is that the Java source file where you defined the search
> > string is not Shift_JIS encoded.
> >
> > Checklist:
> > 1) check encoding of your Java source file
> > 2) convert it to Shif_JIS
> > 3) compile it and make sure to pass the -encoding option to javac
> > 4) run it and report success
> > 5) send me all your money ;-)
> >
> > If you look closely at how QueryByAttributeUnicode is compiled you
> > will notice that javac receives a special parameter (-encoding) to
> > tell it how the source file has been encoded.
> > Alternatively you can try to pass the search string as the second
> > command line arg to QueryByAttributeUnicode to avoid this encodin
> > issue altogether.
> > The section International language support in mapscript/java/README
> > has useful pointers that should help you in understanding more of what
> > is happening under the hood.
> >
> > Regards,
> > Umberto
> >
> > >
> > > Thanks.
> > >
> > > mario.
> > >
> > >
> > > On 8/30/06, Umberto Nicoletti <umberto.nicoletti at gmail.com> wrote:
> > > > Mario,
> > > > Java mapscript should support international charsets, only make sure
> > > > that the environment when you start tomcat (or the servlet container
> > > > of your choice) is configured with the wanted locale.
> > > > Also note that LANG has lower precedence than the LC_* variables and
> > > > in particular check LC_ALL. For example if you set LANG=it_IT and
> > > > LC_ALL=en_US then the setting in effect is en_US.
> > > >
> > > > There is an example using the german charset in the examples directory.
> > > >
> > > > HTH,
> > > > Umberto
> > > >
> > > > On 8/29/06, Mario Basa <mario.basa at gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > I have been testing the java mapscript of mapserver-4.10-beta1 and it
> > > > > seems that layer.queryByAttributes  only works with UTF-8 character
> > > > > encoded shape files and only if tomcat is started also in UTF-8
> > > > > (ja_JP.UTF-8) LANG environment.
> > > > >
> > > > > I tried using Shift_JIS encoded shape files (99% of all shape files
> > > > > here in Japan are Shift_JIS encoded) and tomcat restarted in  UTF-8
> > > > > and then Shift_JIS LANG environments, but I couldn't get it to work
> > > > > anymore, as in layer.queryByAttributes can not match query items
> > > > > anymore with the data.
> > > > >
> > > > > Is there a work-around for this.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Mario.
> > > > >
> > > >
> > >
> >
>