PHPaul
asked on
Is it possible to get the content-type from a file represented as a byte-array?
I am storing images in a database and they can be in any of the generally accepted online formats (jpg, gif, png...).
I retrieve the images from online sources. I get them in as an array of bytes through the use of an inputstream and they are then stored in the database as BLOB's.
I would like to know if I can identify the content-type/mime-type from just the array of bytes. I know I could get the content-type when I retrieve the image by asking URLConnection for it, that is my back-up plan.
I've tried sending images to the browser without specifying the content-type and it works in the browsers I've tested with, but I realize this would essentially be incorrect.
What is actually stored anyway? Is it just the data that makes up the image (the data for the pixels), or is meta data also stored (like the mime-type).
I retrieve the images from online sources. I get them in as an array of bytes through the use of an inputstream and they are then stored in the database as BLOB's.
I would like to know if I can identify the content-type/mime-type from just the array of bytes. I know I could get the content-type when I retrieve the image by asking URLConnection for it, that is my back-up plan.
I've tried sending images to the browser without specifying the content-type and it works in the browsers I've tested with, but I realize this would essentially be incorrect.
What is actually stored anyway? Is it just the data that makes up the image (the data for the pixels), or is meta data also stored (like the mime-type).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
MortenSlotKristensen
But if you still would like to know. Try looking at how the unix command 'file' does it.
>>I know I could get the content-type when I retrieve the image by asking URLConnection for it, that is my back-up plan.
I'm wondering why you want the content-type?
I'm wondering why you want the content-type?
the format in an image file is the way the bits are stored in the byte array so I don't think there is a mime type saved with the bytes in the data base.
ASKER
To MortenSlotKristensen:
It seems I would have to look at patterns to figure out the mime-type. Not willing to do that :-).
To CEHJ:
I need the mime-type because these images are going to browsers. Therefore the Content-Type header needs to be set.
To javaexperto:
That is pretty much what I am finding out. There is meta data stored, I believe, but no mime-type.
I believe one elegant solution might be to create a special object that will hold the binary data as well as the mime-type and maybe more meta data if needed. You see I don't want to have multiple fields in my database describing one object (the image). That is bad design in my eyes.
What do you think?
Thanks for your answers so far.
It seems I would have to look at patterns to figure out the mime-type. Not willing to do that :-).
To CEHJ:
I need the mime-type because these images are going to browsers. Therefore the Content-Type header needs to be set.
To javaexperto:
That is pretty much what I am finding out. There is meta data stored, I believe, but no mime-type.
I believe one elegant solution might be to create a special object that will hold the binary data as well as the mime-type and maybe more meta data if needed. You see I don't want to have multiple fields in my database describing one object (the image). That is bad design in my eyes.
What do you think?
Thanks for your answers so far.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>I believe one elegant solution might be to create a special object that will hold the binary data as well as the mime-type and maybe more meta data if needed. You see I don't want to have multiple fields in my database describing one object (the image). That is bad design in my eyes.
I tend to disagree. Using a custom type on the db side to store your data is viable, but you make your model platform dependant to a larger extent. Plus, working with custom types through JDBC or other abstraction frameworks in JAVA creates an additional level of complexity that's not really needed. Adding extra fields to your table, or even better, normalize it by using two tables IS good design.
I tend to disagree. Using a custom type on the db side to store your data is viable, but you make your model platform dependant to a larger extent. Plus, working with custom types through JDBC or other abstraction frameworks in JAVA creates an additional level of complexity that's not really needed. Adding extra fields to your table, or even better, normalize it by using two tables IS good design.
A weakness here is *just* having the blob i think. It will would be stronger were you to store the file name too, in which case, getting the content type would be a piece of cake in most cases
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm going for the two table approach.
My existing table will hold a foreign key instead of the actual BLOB. The new table will hold the BLOB, mime-type and a primary key. I will retrieve the content-type from URLConnection when I initially retrieve the image and if needed I could even look at the extension or use the API that CEHJ mentioned.
Thanks all for your help. I'll divide the points later today.
My existing table will hold a foreign key instead of the actual BLOB. The new table will hold the BLOB, mime-type and a primary key. I will retrieve the content-type from URLConnection when I initially retrieve the image and if needed I could even look at the extension or use the API that CEHJ mentioned.
Thanks all for your help. I'll divide the points later today.
ASKER
Sorry for the long delay. Got side-tracked.
:-)