Hi,

What I have seen with libcurl API is, a file pointer can be passed for a
local file (i.e) I provide the filepath on a ftp server through CURLOPT_URL.
CURL_READFUNCTION takes the FILE* to a local file.
Ex: if I want to upload a.txt from my local machine to a ftp site (
ftp://aa.com). I pass ftp://aa.com/a.txt as url and my call back function
takes FILE* to file on my local machine. Data is read from this file,
passed through FILE* and writes the data on to the ftp site. Similarly, for
downloading a file, we pass FILE* to a target file, where we want to get the
file to.

Curl internally reads the file on ftp site while downloading a file, and if
the file is in multi-byte character format and curl internally does not
support these characters, it fails to open the file. Similarly, while
uploading curl creates a file on ftp site.

This is just my observation. I am not sure if I have misunderstood
something. Please let me know if I am missing something or if I need to set
some values to get this done.

Thanks,
Nagasekhar

On 1/28/08, Stephen Collyer <scollyer_at_netspinner.co.uk> wrote:
>
> NAGASEKHAR BHUVANAGIRI wrote:
> > Hi,
> >
> > From http://curl.haxx.se/mail/lib-2005-03/0027.html, I see that as on 23
> Feb
> > 2005 there was no support of multi-byte character file names in libcurl.
> > Is the support for multi-byte character file names introduced in later
> > releases? If not, is there a plan to have this feature in future
> releases?
> > We need this feature to transfer files for Japanese/Chinese language
> > customers. Currently, we are encoding the file name to a hexadecimal
> format
> > before uploading and decoding back to multi-byte while downloading.
> >
> > Please give me some info on how this can be achieved using libcurl.
>
> Unless I'm misunderstanding the problem, I think all you have to do is
> to open a FILE*, using your code that can handle multi-byte file names,
> and pass that FILE* to CURL_READFUNCTION. The curl engine then needs
> to know nothing about the local file system whatsoever.
>
> --
> Regards
>
> Steve Collyer
> Netspinner Ltd
>
Received on 2008-01-29