classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

character converter (Re: current work)


From: Takashi Okamoto
Subject: character converter (Re: current work)
Date: Mon, 25 Jun 2001 23:04:59 +0900
User-agent: Wanderlust/2.5.8 (Smooth) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)

At Sat, 23 Jun 2001 12:03:08 -0400,
Brian Jones <address@hidden> wrote:
> I'll take a look at the UTF8 patch later today since it's just a 4
> line change, probably just commit it.

Thanks, it works fine. 

BTW, I found my names in Changelog. I prefer address@hidden to
address@hidden here. (So, I'm Debian Developer.)


Well, I want to add other japanese encodings like EUC-JP ,Shift_JIS...
Does anyone implement them? If not, I would try that.

I have following two opinions for character converters that are iconv
converter and Java converter.


[iconv converter]
(1) In the first, search encoding class like EncodeXXX.class DecodeXXX.class.
    If it's found, convert character with it.
(2) If it can't be found, try ICONVEncoder.class which use iconv
    function. iconv provide character converter by glibc.

This approach is similler to libgcj's Input_iconv.java. I don't need to
implement a lot of converter for each character set. But it depend on
glibc or iconv. We can't use classpath other than glibc platform.

- advantage
    work fast (iconv is written with C).
    less memory.
    implement just one converter. It supports any iconv encodings.

- disadvantage
    depend on iconv.


[Java converter]
Implement converter classes like EncoderEUC-JP.java or
EncoderEUC-KR.java for each charset. We must implement each encoder
and decoder, but they don't depend on glibc because it's written with Java.

- advantage
    work any system.

- disadvantage
    slow.
    spend much memory.
    must implement each character converter.


I prefer implementing iconv converter for glibc 2.2. It is able to
implement Java converer which is priorer than iocnv converter
later. 

Does anybody have other opinion? Should I implement it?

regards.
---------------
 ^^     Takashi Okamoto     <tora at debian.org>
= ..=   Debian Project      http://www.debian.org/
 -o-      Key fingerprint:
            8B37 1FE6 76B2 7BA6 D59A  9BF7 E7F4 46C8 5293 6E17




reply via email to

[Prev in Thread] Current Thread [Next in Thread]