Hello,
the client which doesn't work with UTF-8 is Total Commander (
http://www.ghisler.com/). But what is worst, total commander connected from
different country (with different locale) works with different charset.
Clients from Macintosh don't make it easer. Providing the charset as a
configuration of FtpServer doesn't help (but it would be good - just to
specify the default FtpServer charset), because the charset have to be
changed after user login. FTP protocol does have nothing to specify client
charset (as far as I know), so it have to be per user configuration setting.
I have found two places of interest in FtpServer:
1) ProtocolCodecFactory used in NioListener. For example, the exception
during "STOR ěščřžýáíé-win.txt" (using FtpServer SVN trunk, total commander
encoding is cp1250) is
org.apache.mina.filter.codec.ProtocolDecoderException:
java.nio.charset.MalformedInputException: Input length = 2 (Hexdump: 53 54
4F 52 20 EC 9A E8 F8 9E FD E1 ED E9 2D 77 69 6E 2E 74 78 74 0D 0A)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:180)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:414)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:49)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:832)
at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:60)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:551)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:543)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:487)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.nio.charset.MalformedInputException: Input length = 2
at java.nio.charset.CoderResult.throwException(CoderResult.java:260)
at
org.apache.mina.core.buffer.AbstractIoBuffer.getString(AbstractIoBuffer.java:1122)
at
org.apache.mina.filter.codec.textline.TextLineDecoder.decodeAuto(TextLineDecoder.java:207)
at
org.apache.mina.filter.codec.textline.TextLineDecoder.decode(TextLineDecoder.java:138)
at ftp.ProtocolDecoderWrapper.decode(ProtocolDecoderWrapper.java:33)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:170)
it is simply - decoder expects text in UTF-8 but it isn't. The hexdump is in
attached file cp1250.txt.
The factory is used for commands USER and PASS, thus the decoder and encoder
is already in ftp session and the factory is not asked for codecs any more
(org.apache.mina.filter.codec.ProtocolCodecFilter). Codecs in ftp session
have to be changed (their charset) after user login to decode correctly
incomming subsequent commands.
And another limitation is obvious - characters in user names and passwords
HAVE to be from lower half of ASCII table (in multi charset environment),
because we have no information of client encoding before user login.
2) LIST command, since file names on a file system can be encoded using
UTF-8, sending UTF-8 string to a client with different charset breaks those
file names (ěščřžýáíé-win.txt looks like L?TLLlA?A?AA-win.txt), this is in
org.apache.ftpserver.impl.IODataConnection.transferToClient(String).
I can modify these two places to store and list files correctly for total
commander, but after storing any file, the communication is frozen and I
have to reconnect. I don't know why yet (without my modifications it is ok).
Maybe I don't know enought of MINA and FtpServer internals, thus any help
would be appreciated.
Jiří Kuhn.
2008/10/30 Niklas Gustavsson <[EMAIL PROTECTED]>
> On Thu, Oct 30, 2008 at 3:31 PM, Jiří Kuhn <[EMAIL PROTECTED]> wrote:
> > if I want to use another ProtocolCodecFactory to use it within
> > ProtocolCodecFilter in NioListener I have to copy and paste
> > NioListener.start() method body and change just one line of code. That's
> not
> > too friendly. The hardcoded FtpServerProtocolCodecFactory (and FtpServer
> as
> > well) uses utf-8 charset for communication with clients. But not all
> clients
> > are UTF-8 aware. But non-utf-8 communication is another issue. To solve
> it,
> > it would be nice to be able easily extend NioListener to use another
> > protocol codec factory.
>
> Since UTF-8 "extends" ASCII, is there another charset you like to use?
> Maybe we could provide the charset as a configuration in the core
> code?
>
> Can you suggest a client which does not work with UTF-8, I would like
> all clients to work with FtpServer so this would be important for us
> to fix!
>
> /niklas
>
STOR ìèøýáíé-win.txt
