> Hello, > > I need to know if FTP has support for multibyte > languages. > > Meaning, if the locale is set to be multibyte > languages like Japanese/ > Chinese, does FTP/FTPD in solaris support it? > > With Regards, > Shilpa.
What sort of support? AFAIK, the ftp protocol transfers either raw binary data, or ASCII, or optionally EBCDIC, or perhaps optionally deals with nonstandard byte sizes. I don't see anything in RFC 959 about code conversions other than to/from ASCII; converting multibyte to ASCII would be very lossy (or else fail), I imagine, so I don't think it even tries. The ftpd (server side) has no way of knowing about the locale the client is using, as far as I know. So it can hardly be expected to adapt its behavior. All you can do to get the transfers right is be sure to issue the ftp command binary OR type image OR type binary to be sure that neither end is trying to convert text to/from ASCII. Solaris ftp assumes (and last I checked) only supports "file" as the struct, and "stream" as the mode, and may complain if struct or mode commands are issued at all. Those settings, together with type image, are adequate for arbitrary byte stream data between systems that agree on how to interpret it. The only thing left would be localizing the human-readable messages produced by the client ftp program. I don't see any gettext() calls in the source for ftp, so I don't think that's been done. I could argue that there are enough folks that try to script ftp (not a good move, except maybe using "expect" to deal with success or failure of individual ftp commands; better to use perl CPAN code that lets one test the result of each ftp command individually), that localizing ftp might break something. But assuming that as it appears to me, it wasn't localized, I don't know if that was the reason. -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
