Saving the content from Asp.NET fileupload with strtofile gives a lot of question marks 1

[RedLion]

Hi,

I use VS FoxPro 6.5

I have an ASP.NET page with a Fileupload control on it for uploading pictures.

I send the data via COM interop to a FoxPro COM object

using (StreamReader inputStreamReader = new StreamReader(myfile.PostedFile.InputStream))
{
        oVfp.SaveMyImage(inputStreamReader.ReadToEnd());
}

Within FoxPro I try to write the file to disk as:

strtofile(myFile, "myimage.jpg")

Displaying the image with windows image viewer doesn't work, when I open the file with a text reader I see a lot of question marks. Not all data gets converted from asp.net to FoxPro in the right way. How to fix this?
First line in jpeg:

???? JFIF 

  
 
  ?? ;CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 80

Question, how to fix this?

Going the other way around, using filetostr() I found out that I had to Encode the string send over from my FoxPro COM object to get a readable image in the browser. It has to do with the Unicodes and ANSI used with VFP6.5 but I don't know how to fix this. Anyone any ideas?

MemoryStream ms = new MemoryStream(Encoding.Default.GetBytes(cImage));
HttpContext.Current.Response.ContentType = "image/jpeg";
ms.WriteTo(HttpContext.Current.Response.OutputStream);

 

[GriffMG]

Have you tried writing the file within your ASP.net - to see if it has downloaded correctly?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[RedLion]

Thanks for your quick response!

I have tested it again but writing the file to disk from ASP.net goes without any problems.

The problem is really in the kind of data C# sends to VFP and VFP expect it to be. I've the idea that VFP expects double byte data and C# sends UNICODE 8 or so. But I have no idea and I don't know how to fix it? I have tried all 8 strconv options on the VFP side... But I have to know what kind of data VFP expects? Then I can search for a way to let C# send the data in a good format.

 

[GriffMG]

If you can write to a specific location from ASP.net, if you need VFP to do something else with it, why not just tell VFP where to find the file.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

VFP9 allows you to specify how COM transfers text via SYS(3101). VFP will usually expect ANSI, all 256 bytes are allowed, but if C# handles it as UNICODE, most of the byte combinations interpreted as Unicode characters not translatable to ANSI character are thus replaced by "?".

You should handle and transfer this as binary in ASP.NET already.

The only other thing VFP6 may have available is COMPROP. So eg COMPROP(THIS,"UTF8",1) within init code of the VFP COM Server class will prevent conversions. "UTF8" is misleading here, it doesn't mean your string needs to be UTF-8, it means no translation to ANSI takes place. The problem with binaries are 0 bytes, anyway, when they are interpreted as end of string.

So for easiest transfer, you would rather transfer the binary data base64 encoded and can decode on the VFP side with STRCONV.

Or you simply save to file in ASP.NET and pass in the file name to oVFP, I just second Griffs solution here.

Bye, Olaf.

 

[RedLion]

Thank you Olaf for clearing things up!!

Finally found a solution by putting all code into base64 on the .net side and reversing on the vfp side
Problem is that the VFP 6.5 strconv function doesn't support base64 but found the next workaround:

lParameters cSrc

DECLARE INTEGER CryptStringToBinary IN crypt32;
	STRING @pszString, LONG cchString, LONG dwFlags,;
	STRING @pbBinary, LONG @pcbBinary,;
	LONG pdwSkip, LONG pdwFlags

LOCAL nFlags, nBufsize, cDst
nFlags=1  && base64

nBufsize=0
= CryptStringToBinary(@cSrc, LEN(m.cSrc),;
	nFlags, NULL, @nBufsize, 0,0)

cDst = REPLICATE(CHR(0), m.nBufsize)
IF CryptStringToBinary(@cSrc, LEN(m.cSrc),;
	nFlags, @cDst, @nBufsize, 0,0) = 0
	RETURN ""
ENDIF

RETURN m.cDst

 

[RedLion]

Thanks for your support GriffMG!

It was an other option, but I didn't want .NET to write outside its web directory, out of security issues.

 

[Olaf Doschke]

Hm, the STRCONV() option to en/decode base64 may have been added with VFP7 or 8, indeed. But you found a good workaround.

Nevertheless, did you try to add COMPROP(THIS,"UTF8",1) into the Init? Since the class is used as com server in ASP.NET, that should work out, even though its meant for VFPs usage of external COM servers. Let me guess: Also not available.

AFAIK the file upload arrives as file in TEMP, so you could forward that file name instead of loading it in ASP.NET.

Instead of opening an InputStream, just forward the PostedFile.Filename, or is that only the direct file name? From PHP I know a $_FILES collection having the temp file name in $_FILES['userfile']['tmp_name'], where it already is put on hdd from the http server before calling the PHP script to process the $_POST, $_GET, and $_FILES. You check, whether it really just was uploaded with is_uploaded_file(). As IIS does so for PHP for Windows, wouldn't it also do so for ASP.NET?

In regard of security, you handle an uploaded file, that always has a risc, even if you are sure it's uploaded and the form isn't submitting data tricking your script to display some code or other system file content by faking a file name not uploaded but already present.

Bye, Olaf.

 

[Dan Freeman]

I believe comprop() is a late addition, unavailable in vfp6.

 

[RedLion]

Indeed COMPROP isn't available...

Interesting suggestion about referring the temp file. Will keep that in mind for the next time.

Thanks guys! Speak you later.