Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 11 total
Thread Upload Image As Base64
Fri, Jul 22 2016 6:36 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

Hi,

I am trying to upload an image file that I have stored on a mobile
device (as Base64 data) to my server but the data is getting corrupted
somewhere along the way.

The data starts of looking like this (part of data only):

/9j/4AAQSkZJRgABAQEAAAAAAAD/2wBDAAkGBwgHBgkIBwgKCgkLDRYPDQwMDRsUFRAWIB0iIiAdHx8kKDQsJCYxJx8fLT0tMTU3Ojo6Iys/RD84QzQ5Ojf/2wBDAQoKCg0MDRoPDxo3JR8lNzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzf/wAARCAB/AM0DASIAAhEBAxEB/8QAHAAAAQUBAQEAAAAAAAAAAAAAAwIEBQYHAQAI/8QAQRAAAgEDAwIDBQUFBgUFAQAAAQIDAAQRBRIhBjETQWEHIlFxgRQykaHBI0JSsdEVFjNyktJic4Lh8AgXNUOiY//EABkBAAMBAQEAAAAAAAAAAAAAAAABAgMEBf/EACkRAAICAQMDAwQDAQAAAAAAAAABAhEDEiExBBNRFDJBBSNScRUiJEL
etc..

but comes out the other end like the attached image.

It appears to be a problem with Carriage Returns (or Line Feeds) being
stripped from the data, but I am unsure why.

I am sending the data like this:

PhotoRequest.Method := rmPost;
PhotoRequest.URL := Database.BaseURL;
PhotoRequest.Params.Add('method=photo');

PhotoRequest.RequestHeaders.Clear();
PhotoRequest.RequestContent.Clear();

PhotoRequest.RequestHeaders.Add('Content-Type:
application/x-www-form-urlencoded');
PhotoRequest.RequestHeaders.Add('Accept:'+'image/jpeg');

PhotoRequest.RequestContent.Add('name='+PhotoTable.Columns['Name'].AsString);
PhotoRequest.RequestContent.Add('description='+PhotoTable.Columns['Description'].AsString);
PhotoRequest.RequestContent.Add('data=' + imagedata);

PhotoRequest.ResponseContent.LineSeparator := #10;

PhotoRequest.RequestHeaders.Add('content-length:'
+IntToStr(Length(PhotoRequest.RequestContent.Text)));

PhotoRequest.OnComplete := PhotoRequestComplete;
PhotoRequest.Execute;


What am I doing wrong?

--
Chris Holland
[Team Elevate]



Attachments: Image Data.jpg
Fri, Jul 22 2016 9:22 AMPermanent Link

Matthew Jones

Chris Holland wrote:

> It appears to be a problem with Carriage Returns (or Line Feeds)
> being stripped from the data, but I am unsure why.

I've had this - and I'd say there is no good solution. IIRC, base64 is
supposed to be split into lines of a set length. However, not
everything complied, and some systems will modify it on the way
through. My web shop had a problem with one 3D-secure system which
added extra CR/LFs, and despite being told this was no problem,
manually coding to correct it made it work again.

So I think I'd say look carefully at the data you are getting, and hack
it to work. 8-)

--

Matthew Jones
Fri, Jul 22 2016 10:52 AMPermanent Link

Walter Matte

Tactical Business Corporation

This may or may not be helpful - another EWB user was using base64 for uploading a file and used this solution:

http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&page=1&msg=10113#10113

Walter
Mon, Jul 25 2016 5:24 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

I tried checking the data and it is very strange.

Comparing the data that I receive back from my EWB app with the correct
base64 encoding for the same image they match exactly upto char 349,525
(char count depending upon whether you include the CRLF)

Then the correct encoding looks like this:

......l8G1iJWOpwXJ1iZXr
ESugMfHgomRTqZlOthqKA5XXNZppzKdMOfXevCjV12A9boi9tPWRGr1kcLqAR6DApcPYtQtt7AWF
itQuNWsFDkFCqgXUlTXY1TVbDCa93QW3iFGZkoKivCl9nsG2/s7haGmOJtFMX7xrWx7HU7DLLcGL
WqBPY9iu4WUGx2o9ZazLqJQf4y1x2SmsP/XCm3WDh6vAl25gMXeLUGlFIRyvjF9vY9hVH7Gq6vKu
........

and the broken one looks like this:

......Ml8G1iJWOpwXJ1iZXr
EQ==K6Ax8eCiZFOpmU62GooDldc1mmnMp0w59d68KNXXYD1uiL209ZEavWRwuoBHoMClw9i1C23sBYWK1C41awUOQUKqBdSVN
...................

As you can see form this point on in the file they are completely different!

If I try and upload an image that is under 340K in size it works perfectly.

Any ideas on this?

Chris Holland
[Team Elevate]

On 22/07/2016 14:22, Matthew Jones wrote:
> Chris Holland wrote:
>
>> It appears to be a problem with Carriage Returns (or Line Feeds)
>> being stripped from the data, but I am unsure why.
>
> I've had this - and I'd say there is no good solution. IIRC, base64 is
> supposed to be split into lines of a set length. However, not
> everything complied, and some systems will modify it on the way
> through. My web shop had a problem with one 3D-secure system which
> added extra CR/LFs, and despite being told this was no problem,
> manually coding to correct it made it work again.
>
> So I think I'd say look carefully at the data you are getting, and hack
> it to work. 8-)
>
Mon, Jul 25 2016 9:33 AMPermanent Link

Matthew Jones

Chris Holland wrote:

> EQ==

The == is the normal ending isn't it, so perhaps implies some sort of
overlap in a buffer. But no idea...

--

Matthew Jones
Mon, Jul 25 2016 3:21 PMPermanent Link

R&D team @ Environment Canada

I had tried to do something similar, storing the base64 data in a (DBISAM) db. Some images worked, but for the most part, it did not work (corrupt data), and the DB got very big very fast. I never did get to the bottom of it, but I'm thinking your observations of size might be correct. In the end, I opted instead to save as files (see other post that Walter referred to if you want to see that), and to keep only a reference to the file location in the DB.


"Matthew Jones" wrote:

Chris Holland wrote:

> EQ==

The == is the normal ending isn't it, so perhaps implies some sort of
overlap in a buffer. But no idea...

--

Matthew Jones
Mon, Jul 25 2016 3:28 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Chris,

<< Comparing the data that I receive back from my EWB app with the correct base64 encoding for the same image they match exactly upto char 349,525 (char count depending upon whether you include the CRLF) >>

What happens if you run the same application in a desktop browser ?  Same problem ?

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Jul 26 2016 3:30 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

I was looking at testing it with a desktop version, but I cannot work
out how to get the file instead of just a path from the TFileComboBox so
that I can use the FileReader to extract the Base64 data.

Chris Holland
[Team Elevate]

On 25/07/2016 20:28, Tim Young [Elevate Software] wrote:
> Chris,
>
> << Comparing the data that I receive back from my EWB app with the correct base64 encoding for the same image they match exactly upto char 349,525 (char count depending upon whether you include the CRLF) >>
>
> What happens if you run the same application in a desktop browser ?  Same problem ?
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Tue, Jul 26 2016 7:14 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

Yes, just got it working and it is the same problem with a desktop
application.

Chris Holland
[Team Elevate]

On 25/07/2016 20:28, Tim Young [Elevate Software] wrote:
> Chris,
>
> << Comparing the data that I receive back from my EWB app with the correct base64 encoding for the same image they match exactly upto char 349,525 (char count depending upon whether you include the CRLF) >>
>
> What happens if you run the same application in a desktop browser ?  Same problem ?
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Tue, Jul 26 2016 11:12 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Chris,

<< Yes, just got it working and it is the same problem with a desktop application. >>

Can you email what you've got, or email me a link to use for debugging (please compile the application without compression, if so Smile) ?

Tim Young
Elevate Software
www.elevatesoft.com
Page 1 of 2Next Page
Jump to Page:  1 2
Image