I have a dump of our LDAP database, and i'm attempting to extract all images from it using PHP. The images seem to be stored in JFIF format (at least, according to https://www.rfc-editor.org/rfc/rfc2798#page-5). However, i can't figure out how to create a JPEG file from this; I attempted file_put_contents to dump everything in name.jpeg, imagecreatefromstring's output to imagejpeg and some variations on those. However, either I'm not using them correctly, or I'm just attempting this wrong alltogether.
So the question:
Here's a small part of the field:
jpegPhoto:: /9j/4AAQSkZJRgABAQAAAQABAAD//gA+Q1JFQVRPUjogZ2QtanBlZyB2Mi4wICh1c2lu
ZyBJSkcgSlBFRyB2NjIpLCBkZWZhdWx0IHF1YWxpdHkK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCww
ZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMi
EcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAh
QBkAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF
BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU
2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpq
eoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBA
QEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEH
YXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFl
aY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8
jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A8Kihad+OB3JrQhtI7aHzG
bdKTwMdBVKSGWFVc7lDZAPTOOv6H9aTzJlKMGO4gEH26VEk31Jaua8MkSpIHk3dSkWw854J/wDrUtzb
uCTuYkZDZH5VW06AMwIZss/DZweo5H51ptKzM6SYJGAGIwSMfr0rnk+WWhk9GYzR+Y4AJUgd/wDP0qN
2JVDjnOM5zjGP6VoXVsUl+Rcbjk4qg8Xlz5429Qf6VtGSaNYu6G4U5U9fX3qOJC7bTzn0qY5HDYwe9M
CxhnBYnP3QO9WO5s6aJmiZWUtDyN+/P4dfxrNu0PmH50ZckEgd+P8AGpYbkwxBInOxnVmU9Diku49jj
zBiQruYcdT/APqrKKtIhaMcZ43i+WLAJOVx9wdsEf1pXhLQbg4Y7QSBywHqR6VAYGNusq8ZBIGc8Vct
4WuLZsEJLHgq464zx/P9KTtHVCehmHGeKKVm3Mfl2kHBorY3jsWdRMEKGOJneRuGbOBjPYf/AK+vam2
tlLdyLwxiVdq5OOP/ANZps22/mSO1tyNueVyWfknp7AVq28epwsWS2i3MRjkg8e3+e1ZSbjHzM/IoXQ
MLGDYy7eg24I44/p+daFgwW32zKEf1GCT7/wCf14ANQgvzGHvhCsY2lvL6yAnO0n/PaqUTie9CQYCIy
sGkPcZOCB1qLc8bE8rehqXkYOShLBRg4B6+/wBax7iLazyj8P8A9da4a5ub1BbW7yuQobaOCP8AP/1q
dq+jXcFq13Gr+Wg/exsuMf4j/PvRTTjoy405JXsYEkxMYdMg+wquOVznOfyqxG0bNtyUXIxgZP06j3q
ybZJWaTgj2Xk/X9TmtnJRJvYrwMnlMGbkHg+3tUcmAzrnPINWBED90cDjgdO9VpF2kZ/A5oVmwRfi1R
CY4p4cQKclE7gdun07jv8AhM6IiGVZAVYlGMZ6Hg4+nPXJBrIVSwwqlvoKnVTDleOcdqlwS2BrsLduX
m5UAgAEgYz70UlzKJpdwHbH60VcdjWOxp6XbwQLGsvmi4c5UL2A5+b245/+tVmVxbhpd4jKrjaG3Yb2
Bz+ntWaLS4gKEzukh+UAgHr7/j+tPeBY5d8l0ZZEPCngZ9vzrBxTd7mbJUmvDbkGA7JRkFzyfr7U6zt
7iVfKikCTzsQ+G6jA5z781KLuWS3YDJRj90jA68gdv8imSSXNvcRvCoLOyhlByDk8fj2/GiL1sVDfU9
V8LaLb2C7owHkZeTj/AD71p+I4ra90qa0i8o3gQ7EOMsccqAeuRkcZ61y+jXV5d2PnJK0e1AeSOTzwR
+XXP4V12n3sE8C6jGIVkZR5xL7QTnGD2zzx9abR6KXNE8B1CzOnanNC8JTyzwrnkAgEdhngiq7yyAdw
pO4Cut+Jkksni5vMiVFWFFiIUjevXJz3ySPwrmI50jK52sw6Bl4z/hWvS5584pSaLCS/aIRKgzIG+cK
PTpx3qgFEtxtLYUscHHTPfnFXo7oOGJ2oBglF6OM8/T/P0MDQsZJXRVYcHkgZBGcgdSMA1MdGzNaGhG
La0AQMu44yxHJyM/4U0vZ3csSIzJJJxkDcF5PXpz9PWqwjkEZAJVXAZV3YJI6YqLbi2Y52FSGXOMmoU
FvcVht5C1vcGJ8ZUdqKhaV5jvkbc3rRWyTS1No7GjiYKMb2XuOo/T8D1rOl8yN2WQHd1DZ5q1He2+xV
k3E4AIU7fy61UuYcnzI2JU8hT1FTC6epmTwXsqbt7Ej07fX9KlzJhZBuVsgqehB7YrORlTaSoYA8qel
aJnjkhQlZELHK7W3ACiStshnTaP4nlN8ftigI6hXeLIYnsTnOfwr0fw1IpjZEkVo3fcnGHbBBPsPujO
PfivB5JXSdtpwQa9V8Bapb6lf2jhmNxbw7JVKgDnv+Yocep1UKjd0zpvGXgyx13w9e6jct9mu9Pt2lS
dcdByIzzyDz9D07g+ET2syMV3qccZx1r37x/q1paeC9QsC3+l3U0KBCP4QxYEev+rbP1HqK8Mnbr/eP
HStIJcpjVfvsqQpIkow544IHSpnt3WNpIvuA9DyQP64/Ckx5ZEajhRkn1NaEW1kaPsFweM0+VGRnO8j
wHzMkE8exzzUDFnQDJwoxirEdu8khhX53LHAAJJ96j8s4CnJIyMA1mrICuOFHT3opxG04oqjVbDRgdV
981AQ3r+tdRFBpkvEbJvcHLtFj8ODx+h96py6XaxzMSxIJJVVGDt/GslWj1MuYxNgK/Lk+uO1SRxnpn
rVu509Y2LwsXjxyW6g+lRABPvAYxg8VrFqWqGnchI5xmtTQtXuND1SK8t8krwy5IDDuOKp4VyBjB5pg
G0k4PB/CqsNOx7R4YUeLNJv9e8UXvlaNGzRiM7CsS9sZUnf8wAIw313AV5jqMNsNRmeyaQ2YlYwmXG8
Jn5d2OM46471r3vjyXUPDOmaAluLOztV2zeQ2RORjDFcDnO4nnljmsZxtLPC++MHrj8siqSE3cznbZM
The data is base64 encoded, decode it first and then save it to a file. See http://www.php.net/manual/en/function.base64-decode.php
Related
Am trying to create a video clip using .jpg images and ffmpeg, am creating .jpg images as below:
$str=$_REQUEST['data_array'];//gets the base64 encoded image data;
$count =$_REQUEST['count'];//gets number of images i've to create;
$edited_str=substr($str,23,strlen($str)-1);//
$edited_str=base64_decode($edited_str);
$f=fopen("Images/temp".$count.".jpg","w");//am creating temp.jpg file
fwrite($f,$edited_str);//placing my decoded data into file
fclose($f);
are the images am creating above different from normal .jpg images?
This line:
$edited_str=substr($str,23,strlen($str)-1);
makes it different. If this is the full base64 sting of the file, then this cuts it up and corrupts it. Maybe you are adding some stuff on the front.
If you are just removing stuff from the front that was added, then it should be the same as the original file that was encoded with base64.
If you want to get the information this way from another page, I suggest using $_POST as opposed to $_REQUEST for a number of reasons.
EDIT: I wouldn't say video manipulation in php is impossible. I think there is even a toolkit... here's one:
http://phpvideotoolkit.sourceforge.net/
which states:
It can perform video format conversion, extract video frames into separate image files, and assemble a video stream from a set of separate video images.
Haven't tested it, but plan to try it out one day.
EDIT2: On the php site, there were some issues that you could try, but to help more, there needs to be more information. Check with a file directly to make sure it's being sent and decrypted properly.
I haven't got to test any of these yet.
One piece of advice was for large files use:
$decodedstring=base64_decode(chunk_split($encodedstring));
Another was if you use javascript canvas.toDataURL() then you need to convert spaces back to pluses:
$encodedData = str_replace(' ','+',$encodedData);
$decocedData = base64_decode($encodedData);
http://php.net/manual/en/function.base64-decode.php
Ok, I'm hoping I can explain my situation rather than pasting lines and lines of code.
Currently, JSON sends positional info to my PHP file which in turn uses this data to generate an image, saves it and returns the filename via JSON back to browser. Javascript then refreshes the image on screen.
This all works fine at the moment, but I am wanting to optimise the process and look at the possibility of outputting the image file straight after it's created then save afterwards.
My ideal solution would be something like:
header('Content-Type: image/gif');
echo $this->canvas;
// Save user file
$this->canvas->writeImage( $this->userFile = 'user_img.gif' );
$this->canvas->destroy();
// encode everything and send to browser
echo json_encode(array('misc data back to the browser'));
(I still need to send data back to browser via JSON)
And in my HTML I would have the image laid out like this:
<img src='json-processing-script.php' />
But as usual nothing is ever that simple, so I'd like to hear if anyone can make any pointers.
In your example, the json would be added to the gif, messing up your image. If you want to return these two completely different things from your php script, you would have to encode the image, add it to the json and extract it in the javascript to get the source of your image.
See for example this question.
My PHP abilities are almost non-existent and I am trying to make a very simple REST webservice. The service at present queries a database and returns an image in a 'application/octet-stream' response. I am calling this webservice via ASIHTTP (a REST iPhone framework) which is returning the image perfectly fine :)
Is there any way to make the PHP service return an image AND an XML file? I am thinking the only way to do this is to write the image byte array directly into the XML file. If so - how do I do this with PHP?
Thank you
If ASIHTTP supports this, you could try embedding the image data in the XML, but you'd have to read the relevant documentation first. You can't simply dump a bunch of binary data into an XML file, you need to convert it to something like base64 first.
IMO, a better (more robust) approach is to send both files independently: make one request for the XML, which may contain an ID or something for the image, and then another request to get the image itself.
Apart from more robust code, you will also be able to parse the entire XML before the image is fully loaded. Seeing how images are typically much larger than XML messages, the difference is going to be noticable.
I think the only way would be to base64 encode your image data with PHP and decode it on your iPhone. See the base64_encode manual page - the first comment describes how to use it to read an image.
One method would be to take the binary data and (for example) base64_encode it, embed that in your XML, and then when you receive it you can base64_decode it using + (NSData *)decodeBase64WithString:(NSString *)strBase64 { from here:
NSData *data = [Base64 decodeBase64WithString:strBase64];
UIImage *image = [UIImage imageWithData:data];
Greetings !!
I have to insert a logo(image) on the row[0],column[0].I am using "Spreadsheet_Excel_Writer" for that.i tried its insertBitmap() methode ,program working fine but it doesn't show the bitmap image on xls sheet,instead blank row. what could be reason ? can you please let me know the exact string format for the argument. Is there any other way to insert image on xls sheet using PHP5.i am very new to php ,it will be a great help .
Have a nice time ahead !!
[edit]
Here is the code, as per Aman's comment below:
$sew =& new Spreadsheet_Excel_Writer ();
$worksheet =& $sew->addWorksheet (substr (strval ($name).strval ($sht), 0, 31));
$worksheet->insertBitmap ($row,$col,$image,$x,$y,$scale_x,$scale_y);
I never could get Spreadsheet_Excel_Writer to work properly with image insertions. Not sure if it's a bug in the library or what. But in any case, S_E_W is hideously outdated, you should switch to PHPExcel instead, which supports recent Excel formats (including .xlsx) for reading AND writing, whereas S_E_W is limited to BIFF 5.0, which is Excel '95 (or thereabouts) and only supports writing.
I've just ran a test using Spreadsheet_Excel_Writer. SEW saves the excel file using BIFF5 format. Open Office Calc will read images from BIFF8, but not from BIFF5 files.
EDIT
Further testing:
Setting SEW to write BIFF8 by using $workbook->setVersion(8); still doesn't write the bitmap image correctly as a BIFF8 file. It would seem that unless you want to rewrite SEW to store images correctly for BIFF8, then you won't see them when opening the file in OOCalc... without reading through the OOCalc or SEW code, I couldn't say what the problem is. Nor does Gnumeric read the image when the file is saved as BIFF5, but it will display the image correctly when the file is saved as BIFF8.
I've gotten this to work. The thing is, this writer is EXTREMELY sensitive to cell overwriting.
Your syntax is correct.
Things to look out for:
Make sure the file is 24 bit BMP. That's the only thing this writer supports.
Make sure nothing overwrites the cell where you place the image.
Make sure that the image path is correct.
And make sure the scale is set. If it's not set, it goes to 0 which doesn't display the image. The default is noted as 1, but it's not.
I am trying to display an image from a MySQL blob field. I have tried a few different things and none of them seem to work.
I have tried:
header("Content-type: $type"); img src = $blobData;
header("Content-type: $type"); echo($blobData);
<?php
header("Content-type: $type");
echo $blobData;
?>
This code looks perfectly OK. However, I heard a similar complain from another person and I was able to troubleshoot it by assuring that:
The php script does not output any extra character before or after sending the binary image data.
The php script is saved as a pure ASCII text file, not as a Unicode/UTF-8 encoded file. The Unicode/UTF-8 encoded PHP files might include a signature as the first bytes. These bytes will be invisible in your text editor but server will send these few extra bytes to the browser before the JPEG/GIF/PNG data. The browser will therefore find the wrong signature in the beginning of data. To workaround, create a blank text file in notepad, paste in the php code and save the file in ANSI encoding.
Another option you might consider (assuming you are on Apache):
Create an .htaccess file with a mod_rewrite for all image extensions (png, jpg, gif).
Have it redirect to a php script that looks up the image requested in the DB. If it is there, it echos out the header and BLOG. If it isn't there, it returns a standard 404.
This way you can have:
<img src="adorablepuppy.jpg" />
Which then gets redirected ala:
RewriteEngine on
RewriteRule \.(gif|jpg|png)$ imagelookup.php
This script does a query for the image, which (obviously) assumes that the requested image has a unique key that matches the filename in the URL:
$url = $_SERVER['REQUEST_URI'];
$url_parts = explode("/", $url);
$image_name = array_pop($url_parts);
Now you have just the image filename. Do the query (which I shall leave up to you, along with any validation methods and checks for real files at the address, etc.).
If it comes up with results:
header('Content-type: image/jpeg');
header('Content-Disposition: inline; filename="adorablepuppy.jpg"');
print($image_blog);
otherwise:
header("HTTP/1.0 404 Not Found");
FYI: I have no idea if this would be bad in terms of performance. But it would allow you to do what I think you want, which is output the image as though it were a flat image file on the server using a simple image element. I'm inclined to agree that BLOBs are not the best way to go, but this does avoid any cross-browser issues.
I believe that the issue that you are encountering is an issue with encoding. This resource claims that you can use the print function.
Just get the image from the database. And print it using the correct headers.
$image = mysql_fetch_array(...)
header("Content-type: image/jpeg"); // change it to the right extension
print $image['data'];
For performance reasons... this is not advisable. There are several reasons to put images in databases but the most common are:
a) keeping them indexed (duh!)
You can do this by storing the images flat on the server and just indexing the image filename.
b) keeping the image hidden/protected
Flickr and alike still store the images flat on the server and use a different approach. They generate a URL thats hard to find.
This link points to a protected image on my account. You can still access it once you know the correct URL. Try it!
farm2.static - a farm optimized for delivering static content
1399 - perhaps the server
862145282 - my username
bf83f25865_b - the image
In order to find all my secret images any user can hard hit Flickr with the above address and change the last part. But it would take ages and the user would probably be blocked for hammering the server with thousands of 404s.
That said there is little reason to store images on BLOBs.
Edit:Just a link pointing to someone that explained much better than I did why BLOB is not the way to go when storing images.