Re: Second byte of multibyte characters causing trouble
От | Karen Ellrick |
---|---|
Тема | Re: Second byte of multibyte characters causing trouble |
Дата | |
Msg-id | GAELLCMOCEGMDMHDMIILOEECCOAA.k-ellrick@sctech.co.jp обсуждение исходный текст |
Ответ на | Re: Second byte of multibyte characters causing trouble (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: Second byte of multibyte characters causing trouble
|
Список | pgsql-general |
> 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 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.) > 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!) > Assuming you could read/write Japanese, I recommend you subscribe > PHP-users list (http://ns1.php.gr.jp/mailman/listinfo/php-users). 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! :-) That's why I have been using English lists. But I know that most of the people on the English lists (maybe everybody except Ishii-san!) don't work with Japanese systems and can't answer questions about them, so when I have future questions of this type, I probably should try the php.gr.jp list. Thanks for the link. > 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? (I had assumed that I control the charset used for form data by the "charset" variable in the html header, but I haven't tested that theory!) Or do you mean that if the text in echo statements is in a different charset than the header (how could it even know?), it will convert it when sending it out to the browser? (That would be hard to believe, but wonderful if it's true!) I'm still unsure of what to do. I was just about to take your advice and switch all my PHP and Perl files to EUC, when I remembered that I have to consider other people. After I get the PHP/Perl code working, the webmaster cleans up my grammar and/or changes the wording to the way he wants it, and he never uses Linux but only Windows-based editors, which as far as I know all expect Shift-JIS. Maybe I can train him to always open files with the EUC->Shift-JIS preprocessor and save them with the Shift-JIS->EUC postprocessor, but I suspect he won't be happy about it. But if I can get answers to the above questions, I may be closer to a decision on which approach is better, all things considered. Regards, Karen -------------------------------- Karen Ellrick S & C Technology, Inc. 1-21-35 Kusatsu-shinmachi Hiroshima 733-0834 Japan (from U.S. 011-81, from Japan 0) 82-293-2838 --------------------------------
В списке pgsql-general по дате отправления: