..
PERALTA ANDRES.pdf
PE??ALOZA JORGE.pdf
..
The fpc program is a CGI, which runs in a FreeBSD system.
The fpc program is a CGI, which runs in a FreeBSD system.
Make sure that your main program uses either cwstring or fpwidestring. If that's not enough please provide the output of the locale (at least I hope that also exists on FreeBSD).
The fpc program is a CGI, which runs in a FreeBSD system.
Make sure that your main program uses either cwstring or fpwidestring. If that's not enough please provide the output of the locale (at least I hope that also exists on FreeBSD).
Hi PascalDragon, how can I tell which type of strings?.
cwstringor
fpwidestringdoesn't change the result.
with TStringList.Create do begin LoadFromFile(Dir + SR.Name); // <-- Unable to open file.... end;
I did an: ls /directory/file|hexdump -C to see the actual ascii codes of the filename and found the Ñ is replaced to the hex a5, then I did this:
lFile := AnsiReplaceStr(lFile, 'Ñ', chr($A5)); lPdfStream.LoadFromFile(lFile);
But still I can't open the file with LoadFromFile.
The ASCII code of 'Ñ' in ISO-8850-1 is D1, not A5. So, if your settings are as you said, they translate the wrong code page.Code for Ñ is $A5 in CP437 and CP850, which are used for Windows console in USA or Western Europe. As I understand, Windows uses console CP for network mounts.
var lFile: RawByteString; ... lFile:= ... ... SetCodepage(lFile,Windows.GetConsoleCP,false); lFile:=Utf8Encode(lFile);
martinrame is on FreeBSD, so using the Windows unit is not an option.
Code for Ñ is $A5 in CP437 and CP850
Implements a memory stream which supports file names with UTF-8 encoding
TmemorystreamUTF8 is a nonsense. A stream is a stream and always byte sized.
I would have fired the author. Simply because of proven lack of knowledge.
In Pascal, you read files with AssignFile/Reset/Read. You do not need classes for that
The file name, not the content...... < sigh> and even that is nonsense. That class has no right to live....
I tried everything, it looks like an issue related to Apache and/or the CGI, because the same program from command line works without issues.
I tried everything, it looks like an issue related to Apache and/or the CGI, because the same program from command line works without issues.
So to clear that up: if you run the program without any involvment of Apache you can correctly open the file with the non-ASCII characters? And if you do it inside Apache you can't?