April 12th, 2012
SFTP protocol specification requires that client and server use UTF-8 encoding for file names. So if a server does not use UTF-8 encoding by default, but uses its local encoding instead, we can conclude that it is the server's fault. But it's not always the case. SFTP specification lower than version 4 has not required UTF-8 explicitly.
However, most SFTP clients operate in two modes to handle encoding. Either it expects that the local machine and the server use the same encoding (no conversion need to be done) or treats remote filenames as UTF-8 encoded.
But this may not work even when the local machine and the server use the same encoding. It's caused by a kind of communication issue between the client and server due to concrete implementations in unmatched strategies.
As follows is a typical case of this issue.
Assume that you're using such a client which prefers to use UTF-8 encoding if the server doesn't explicitly point out that it doesn't use UTF-8 encoding, and you're going to connect such a server which uses its local encoding if the client doesn't explicitly request to use UTF-8 encoding. Do you see the problem?
This usually happens for SFTP server whose version is lower than 4.
To solve this issue and avoid issues alike once and for all, if you’re the administrator/owner of the SFTP server, just simply upgrade your SFTP server to SFTP-4 or newer; if you’re a user of the SFTP server, try to find a SFTP client which compromises with legacy SFTP servers and perfectly handles this kind of issues .
|Comment||This entry was posted by BurningXFlame on April 12th, 2012 at 20:41, and is now filed under SFTP .|