Hello Atsuhiko,
it's interesting to learn about versions of the sftp
protocol and that UTF-8 was added only later.
I still find your proposed solution problematic, because
in case the server reports a version > 3, the client
will have NO CHANCE changing the encoding for filenames.
But in draft-ietf-secsh-filexfer-13 section 6. "File
Names"[1] it says exactly what I've been saying:
* There may be conditions where the server does not
know the desired remote encoding, or is otherwise
unable to convert to UTF-8
* Conversion to UTF-8 may not be reversible
Therefore, the draft standard allows servers to send the
preferred encoding as part of its version packet. And,
the protocol does allow clients to disable the UTF-8
translation.
Because of all this, I think that
1. Jsch should allow clients to read the desired remote
encoding that was set during version handshake
2. Jsch should allow clients to disable UTF-8 translation
when supported by the server
3. Jsch should allow clients to do their own encoding
when EITHER protocol version <= 3 OR UTF-8 translation
has been disabled in (2)
When these are implemented, our application will present
the server's recommended charset we read in (1) to the
user, and if user overrides it we will send the override
command in (2) and specify our own encoding in (3).
Would that be possible?
[1] http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-6
Thanks,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
JSch-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jsch-users
