Jim,
How is an applet suppose to pass double-byte characters (like chinese GB)
to a text value in an HTML form? JavaScript is used to call a method in
the Java applet.
Do we use Unicode or just GB?
The applet works fine when Netscape 4 is in the ISO-8859 mode; it pass GB
characters in 8-bits byte form back to the HTML form.
But once Netscape switch to GB2312 viewing mode when the applet runs, the
applet seems to pass garbage ???? back to the HTML form. Do we simply just
work with 16-bit Java character value? It doesn't seems to work that way
either.
Do we pass 8bit bytes or 16bit Java char? and in what charset?
On Thu, 30 Apr 1998, Jim Saunders wrote:
> The new release of JDK1.1.6 resolves this problem. If you are using JFC and
> JDK1.1.6 you
> will be able to enter CJK. This is off-the-spot support, no in-line support is
> available until the
> IM framework arrives.
>
> Jim
>
>
> Adrian Havill wrote:
>
> > >As in the note, the newer Swing/JFC JTextComponent (available by download
> > from the
> > >Sun java site) implements text editing in pure Java, and is not subject to
> > these
> > >limitations. I haven't really played around with it much, and so can't
> > speak to its
> > >features in general.
> >
> > If you use the current version of Swing with JDK 1.1, your JTextComponent
> > will be able to accept nothing but ISO-8859-1. The Input Method Editor for
> > CJK systems gets shut off.
> >
> > You'll either have to wait for JDK 1.2 (which, via the IM framework, allows
> > non-Latin1), or use standard 1.1 widgets.
> >
> > Note that this is only for _inputting_ Unicode into Java. The current
> > version of Java does most Latin and CJKV Ideographs in Unicode just fine.
> > (No BIDI, non-spacing marks, etc., yet)
>
>
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:40 EDT