[
https://issues.apache.org/jira/browse/VFS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920614#action_12920614
]
Benoit Maisonny commented on VFS-302:
-------------------------------------
I like Nikos' solution: it's simple and to the point. In case people want more
control, however, a more involved solution would be to allow configuration of
the client via org.apache.commons.vfs.provider.ftp.FtpFileSystemConfigBuilder.
This is how VFS users can externally configure other properties such as
timeout. FtpFileSystemConfigBuilder would then need new getter/setter for
"controlEncoding".
Please consider either solution in a future release. The current situation
makes VFS unusable outside US-ASCII-encoded file names, even though the
underlying FTP library supports it.
> FTP Filename Encoding
> ---------------------
>
> Key: VFS-302
> URL: https://issues.apache.org/jira/browse/VFS-302
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.1
> Environment: Linux, vsftpd
> Reporter: Oliver Tupran
> Attachments: Modified_FtpClientFactory.java
>
>
> I tried to copy a file like "münchen.jpeg" using VFS to a remote ftp server,
> which resulted in a wrong encoded filename on the server.
> See also a similar issue from the commons-fileupload project:
> http://issues.apache.org/jira/browse/FILEUPLOAD-56.
> Forgive my newbieness on VFS, but I would really appreciate a solution.
> I tried something that worked, but it really seems like a dirty trick:
> String encodedFilename = new String(filename.getBytes(), "ISO-8859-1");
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
