Earlier this week, I posted a demonstration of how to use ColdFusion to programmatically create zip files and then embed those zip files secretly inside of JPG image files. I also demonstrated how to use ColdFusion to extract this hidden, embedded data from the resultant JPG file. In the comments to the blog post, Gary Fenton asked how to use the resultant file without using ColdFusion. On my machine, Windows XP, it's simply a matter of renaming the file extension. To make sure that we're all on the same page, I put together a quick little demo:
| || || || || |
| || |
| || || |
I can't say that this works on other versions of Windows, but XP handles it nicely.
Looking For A New Job?
- Sr. Cold Fusion Web Developer at Vemma Nutrition
- Senior .NET Software Developer with API Experience at Marketing Holdings
- ColdFusion & AngularJS Web Developer for rapidly growing startup - at Intuvo
- Senior Coldfusion Web Developer (UK - Kent) at EPG Health Media
- Web Developer at Bridge Catalog
Thanks Ben. I believe you now. :-D I'll run the code locally to generate the merged jpeg. Maybe IE did something to the image when I right-clicked and saved it from your previous blog.
That still seems crazy to me that it works so nicely :) Really cool though.
It should be noted that the reason this kinda thing is possible is due to the way some file formats are structured.
JPEG (as well as the various MPEGs, including MP3s) allows junk data to be included with the file - any applications designed to read those files just ignore anything that's not part of a JPEG.
Similarly programs that handle ZIP files will ignore the JPEG portion - what appears to be junk to them.
In Windows you can get away with this sort of thing, just by using file extensions - if it's a .jpg, Windows will try to use your associated image application to read it; but if it's a .zip, it'll use your default compression app.
When it comes to systems that use the actual content to try to identify file types, this may not work so well.
Various Linux frontends (like gnome/KDE) for example will probably identify the first part of the file - an image - and open it using an image editor, even if the extension is .zip (I have yet to test this - probably won't get a chance to touch my Linux boxen in the near future)
Of course, if you choose to open the file using the specific application in question, it shouldn't be a problem.
I'd be interested to see what happens if you use two different file types which can be read by the one application - for example, concatenating a raw WAV file after an mp3 or something, and seeing how winamp/media player handles it (or jpg/png for a smaller test).
Ben - Just one more post till your 1000th Cold fusion post :)
BTW, I was a big WinRAR fan too, but it's time to move to 7-Zip ( http://www.7-zip.org/ ).
Cool. I didn't know that it handled RAR files also. I'll have to see how much quicker it is that WinRAR.
@Gareth: It can only un-rar a .rar file. Can't create.
Looks cool. Anything in particular that I should know about it?
Thanks for pointing that - that's kind of cool. Maybe today :D
@Ben: It's free? It doesn't nag you like winrar does? :) It's also open-source. I've seen mixed results between 7-Zip files (.7z) and Winrar (.rar), majority of the times 7-Zip won in the compression size. The max compression is still .zip (which 7-Zip still handles). Otherwise, it will un-rar, un-zip, un-7z, etc.
Sounds good to me. I do like free :) I'll give it a look-see.
And, if you don't like the 7z interface, you could use jZip ( http://www.jzip.com/ ) - which uses the 7z compression engine and basically gives it a better facelift.
Thats interesting info.!!
If you were to use "Open With..." and select 7zip, you wouldn't even need to change the extension. :)
nothing to download, all webbased