Re: Second byte of multibyte characters causing trouble

> > Use "kon" command.
> This was a wonderful tip - thank you, Ishii-san!  I didn't know about the
> command, and it seems to be trying to do what it is designed to do.  It
> doesn't display Shift-JIS correctly, but it does work for EUC.  Since I seem
> to be moving in the direction of converting everything to EUC, that should
> be okay.  But in vi, how do I input Japanese?  Is there a key combination
> that does what IME does in Windoze?

I've heard that there is a vi crone called "nvi-canna" having a IME
called "canna". In nvi-canna, "set canna" + CTRL-O should initiate the
Japanese input mode.

> I also noticed that vi is still not aware of the multi-byte characters - for
> example, when moving around in the text, I have to type h or l twice to get
> to the next character, and if I want to copy or delete characters I have to
> pretend that there are twice as many.  Typing "x" just once (or an odd
> number of times) is really entertaining - all the characters in a whole word
> or sentence change to obscure kanji as kon tries to process the second byte
> of one character and the first byte of the next as a character.  Is there a
> way to make vi aware of multibyte characters?  (This is not an absolute
> necessity, but would help.)

Hmm. Maybe locale problem? In my case (I'm using Vine Linux), the
correct locale is "ja_JP.eucJP", but may be different on RH6.2J.

> > Again why not emacs?
> I had never used it - in fact, it wasn't even installed on my system.  After
> you seemed to be recommending it, I installed the "no X" version (I don't
> have any graphical interfaces on these machines) and invoked it once to see
> what it is like, but it looks like it would be miserable to learn to use
> without a mouse, if it would work at all for some features (I had to dig
> real deep in the docs to figure out key commands - they constantly refer to
> the mouse).  It would be no problem to add a mouse to the server that
> resides at my desk (well, maybe a bit of a desk space shortage...), but much
> of my work is done through ssh to two other servers, and I doubt a mouse
> would work in that environment - am I wrong?  (Zero experience with mice in
> Linux!)

I've never use a mouse with Emacs even in the X environment.

> I do read and write Japanese if I work hard enough at it (lots of copy/paste
> to/from a software dictionary - I've lived in Japan 5 years), but reading
> and contributing to a mailing list in Japanese could consume my whole work
> day! :-)

I understand. Same thing can be said for me with English:-)

> > Are yo using PHP? Then I strongly recommend upgrade to PHP 4.0.6 or
> > higher. It supports Japanese very well. It aumatically guess the input
> > charset, does the neccessary conversion.
> Input from where and conversion to what?  Do you mean data typed into forms?

Yes.

It seems most browsers use same encoding as the one used for the the
page (you could view the page's charset using "property" or whatever
menu in the browser). PHP4.0.6 is clever enough to automaticall guess
the chaset of data put in a form, and do a conversion between the
encoding and EUC-JP (that is the recommended internal encoding of
PHP).

In PHP4.0.6's php.ini there are entries to control the behavior of the
encoding handling:

mbstring.internal_encoding = EUC-JP
mbstring.http_input = auto
mbstring.http_output = SJIS

Theses are read:

o the internal encoding in PHP is EUC-JP (this is recommended)
o charsets of any input from forms etc. are automatically determined
o charsets for all final pages produced by PHP are SJIS

Interesting?:-)
--
Tatsuo Ishii