tags:

views:

219

answers:

5

I want to be able to send an image from HTML page to a XML file using C#.

The image should be sent along with some text, the problem is how do I store the image in the XML file efficiently, so it can be sent over the wire and how do I store the position of the image on the HTML page, so it can be restored later in the original position?

I was originally going to keep a hyperlink in my XML file to an image and load it that way on the HTML page, using ASP.NET, but I wondered if there's better ways?

EDIT:

So how do I keep the coordinates of the picture in the page in relation to all other objects. What ways can I save it to the XML file and how do I get the coordinates? Using ASP.NET, HTML and or JavaScript?

+4  A: 

You can do it but its a really bad idea. If this is in an ASP.Net context then the hyperlink method sounds much more reasonable.

However, if you insist on encoding images in XML, then have a look at base64 encoding or ASCII 85.

Phil Nash
So why is it a bad idea to encode the image inside the XML file? What are the advantages/disadvantages?
Tony
The biggest disadvantage is the overhead. You're probably going have at least a 100% size overhead.The second disadvantage is that you'll need to encode and decode. You can't just examine the image in a normal viewer until its decoded. The client site would have to know what the encoding is and being capable of decoding it.
Phil Nash
If you can guarantee that both sides can deal with unicode, with no reinterpretation along the way, you may be able to optimise further. On the downside, if you do encode in an ascii based format, but end up transferring as, say, ucs-16 or ucs-32 anyway, you could be adding another 100-200% overhead!
Phil Nash
I get it, so I'll just stick to what I was doing then, using a hyperlink to reference it. Will that store position of image on the page?
Tony
Well, not 100%: Base64 only has a 33% overhead over the original binary, as it represents every 3 bytes with 4. But the encoding and decoding overhead is indeed a pain. XML really is supposed to be text; embedding big binaries just isn't what XML was designed for.
jk
100% overhead is stretching it a bit. with base64 encoding every 6 bits source, becomes 8 bits in the destination. So a picture will inflate to 1.333 it's size (or 1/3 bigger).
Toad
@jk, well ok - the pure overhead is 33% - which is still a lot. But that's assuming that the transport encoding is ASCII or UTF8
Phil Nash
@Phil Nash, granted. I didn't even think of using something other than UTF-8. Compression on the transport, if available, helps with UTF-16 or UCS-4, though.
jk
@jk good point, compression would help there - but we're adding more and more unknowns :-)
Phil Nash
A: 

There are binary xml specifications out there for sending of such data via xml, but these don't cater to your specific "position of the image" issue.

I would simply keep the image URL and use that.

Oded
A: 

I wouldn't recommend doing this (better add a link on the serverside that you can reference a < img />, like http://yourhost/someGuid maybe, and leave the serialization to your webserver and the browser), but base64 would be an easy option for your usecase.

Benjamin Podszun
A: 

Follow the KISS principle.

Do what you were originally going to do, and keep the link in the file.

Matt Joslin
A: 

You could encode the image as a data URI, which most browsers seem to support now. It's still base 64, and so less compact than a separate binary file, but it is a standard way of inlining small images.

Pete Kirkham