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).
LVL 2
PHPaulAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MortenSlotKristensenCommented:
If you would like to get the content type from the byte array it would be a painful process.. Why not just go for the plan b? It would be, as you say, quite easy to implement anyway. :)
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
MortenSlotKristensenCommented:
But if you still would like to know. Try looking at how the unix command 'file' does it.
0
CEHJCommented:
>>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?

0
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

javaexpertoCommented:
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.
0
PHPaulAuthor Commented:
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.
0
pellepCommented:
There is no reliable way to determine content type from the data itself (ie, the byte array). Some formats have a "header" section in the actual content that you can parse, but you cant really rely on that.

I would get the content-type from the URLConnection, like you mentioned, and store that information associated with the actual byte data in the database (your plan B). In the table where you have your BLOB column, add a foreign key column that can reference an entry in a lookup-table where you have entries describing content and mime types. This has already been suggested by other posters, I'm just chiming in with them.
0
pellepCommented:
>>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.
0
CEHJCommented:
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
0
CEHJCommented:
As it happens, you can use the API here:

https://jmimeinfo.dev.java.net/
0
PHPaulAuthor Commented:
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.
0
PHPaulAuthor Commented:
Sorry for the long delay. Got side-tracked.
0
CEHJCommented:
:-)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.