Page 1 of 1
libURLDownloadToFile with non ASCII file names
Posted: Tue Sep 17, 2013 5:34 pm
by hliljegren
I have implemented FTP-upload and download in a program and it work for all files as long as they don't contain any non ASCII characters. As I try to download a file call "Föräldrabrev 1.pdf" I can't get it to work. I've tried to urlencode the file name, uniencode to both UTF16 and UTF8 and uniencode AND urlencode but I always get "can't open file". Anyone got a solution?
Re: libURLDownloadToFile with non ASCII file names
Posted: Tue Sep 17, 2013 6:07 pm
by FourthWorld
It won't be possible to suggest enhancements to you code without seeing your current code.
Re: libURLDownloadToFile with non ASCII file names
Posted: Wed Sep 18, 2013 10:28 am
by hliljegren
Ok Let's say we have these definitions first:
Code: Select all
put "my.Server.com" into tServer
put "myUser" into tUser
put "myPass" into tPswd
put "/my/folder/path/" into tFTPPath
put "/my/local/folder/path/" into tLocalPath
put "Föräldramöte 1.pdf" into tFile
My first try was to do just
Code: Select all
libURLSetLogField the long id of field "log"
put "ftp://" & tUser & colon & tPswd & "@" tServer & tFTPPath & tFile into tURL
libURLDownloadToFile tURL, (tLocalPath" & tFile), downloadComplete
This works for all files as long as they don't include Swedish characters. For the case above it does creates an empty file on the local disk but in the log field I see that the server responds with status "550 Failed to open file"
I then tried to:
Code: Select all
libURLSetLogField the long id of field "log"
put "ftp://" & tUser & colon & tPswd & "@" tServer & tFTPPath & urlencode(tFile) into tURL
libURLDownloadToFile tURL, (tLocalPath" & tFile), downloadComplete
and as I know the server works with UTF8. (Sent the ftp "FEAT" command and got UTF8 among the features back) I tried:
Code: Select all
put "ftp://" & tUser & colon & tPswd & "@" tServer & tFTPPath & unidecode(uniencode(tFile), "UTF8") into tURL
Same result so I tried:
Code: Select all
put "ftp://" & tUser & colon & tPswd & "@" tServer & tFTPPath & urlEncode(unidecode(uniencode(tFile), "UTF8")) into tURL
with the same result. I've also found that if I use urlencode and have a filename with space like "my file.txt" the server responds 550 if I send it like "my+file.txt" but not if I send it like "my%20file.txt" or just like "my file.txt"
Well I also tried:
Code: Select all
macToIso(tFile)
urlencode(macToIso(tFile))
urlencode(macToIso(tFile))
replace "+" with "%20" in tFile
to ensure that it was not a mac-encoding problem.
Note! If I run ftp via the terminal I have no problem to download the file.
Re: libURLDownloadToFile with non ASCII file names
Posted: Wed Sep 18, 2013 10:58 am
by hliljegren
Further notes: Even if I do raw FTP commands like:
Code: Select all
get libURLFtpCommand("PASV", tServer, tUsername, tPswd)
get libURLFtpCommand("CWD " & tServerPath, tServer, tUsername, tPswd)
get libURLFtpCommand("OPTS UTF8 ON", tServer, tUsername, tPswd)
put unidecode(uniencode("Föräldramöte 1.pdf"), "utf8") into tFile
put libURLFtpCommand("RETR" && tFile, tServer, tUsername, tPswd)
I still get the 550 error. I've tried various versions (same as above) of encoding the file name, but I can't get it to work! When doing the "OPTS UTF8 ON" command I get a response that the server is always in UTF8 mode.
Re: libURLDownloadToFile with non ASCII file names
Posted: Wed Oct 09, 2013 3:41 am
by icouto
This issue may have to do with the fact that LiveCode is not yet able to handle unicode - and UTF8 text - natively. There are several native functions and commands that break, if you need them to handle international characters. Most of the file-handling routines are not international-text savvy yet. My understanding is that pervasive and transparent unicode is coming - it's part of the Kickstarter goals - but it's not quite there yet...
Re: libURLDownloadToFile with non ASCII file names
Posted: Wed Oct 09, 2013 3:08 pm
by hliljegren
Yes that's probably the case here. Usually there is at least a work-around, but for this I haven't found one so I will consider it a bug till then... But thanks anyway.