fI have the following code:
$ipaFile= '/path/file.ipa';
$iconFilePath = "Payload/myapp.app/AppIcon40x40#2x.png"; // the pathway to my image file if the ipa file is unzipped.
$iconFile = "AppIcon40x40#2x.png";
$iconSaveFile = '/path/';
if ($zip->open($ipaFile) === TRUE) {
if($zip->locateName($iconFilePath) !== FALSE) {
if($iconData = $zip->getFromName($iconFilePath)) {
file_put_contents($iconSaveFile.$IconFile, $iconData);
}
}
}
This code successfully pulls an image out of an ipa (zipped) file and puts it where I want it to be. The image displays properly in image viewing programs. However, when I want to view the image in a browser, the browser tells me that the image cannot be displayed because it contains errors.
Doing further research, I get that the file is somehow not being unzipped incorrectly. There are a lot of issues regarding images not displaying in browsers, but there are a wide variety of reasons and I'm just not sure which one is mine. I've tested a variety of ways to try and fix the problem (fread method of getting file, using PHP's image functions, using headers, etc) and I can't seem to make it work. Any help would be appreciated, thanks.
For any who will wonder, when Xcode (Apple) compiles an app, it modifies the PNG files within them and a standard browser will not render them as is.
http://echoone.com/filejuicer/formats/ipa
https://theiphonewiki.com/wiki/IPA_File_Format
Related
As an example, say I'm trying to download App Icons from the Google Play store for a service. Here is an example URL:
https://lh6.ggpht.com/1eVPA6Iukw-F4i5xq1ZWicaKBzmprLGw98YhdG20E-wlsHHg3PcKJqbY_fWLdJeGRw=w512-rw
There is no mime type associated with the data provided, and when the file is saved any image viewers (or at least the ones I've tried) will say the file is corrupt. They will show up in Chrome and a couple of other things, but when inspecting the data, it's clear there's simply no mime type. This is an issue, because I am further using these data streams in other scripts which require that they be recognized as a specific type. (namely PNG)
I've tried things such as:
imagepng(imagecreatefromstring($icondata), $finaldir.'/icon.png');
Where $icondata is simply a curl response for the image. This will return an error saying that the data is of an unknown format for the imagecreatefromstring function. Of course, I've also tried:
file_put_contents($finaldir.'/icon.png', $icondata);
To no avail. It creates the file, but as I said, the image is not recognized as an image in most applications and in various analyzing functions. Is there a way to specifically set the mime type of a given string of data? Or some other workaround I'm not quite seeing?
Edit: Also, to note, there is nothing wrong with the $icondata variable. I have tried manually saving the image to a file through my web browser, and the same problem arises.
I have developed a small CMS for myself and was facing the same issue. After trying a lot, I have found a solution. It is working for me and I hope you will find it useful for your project too.
Regarding the corruption of file, for Chrome user-agent, Google servers send icons as .webp format and you need a PHP library for handling images of this type. And for other user-agents (like Firefox), images are sent as PNG.
Now comparing the two URLs for a same icon in Firefox or Chrome, you will notice that image paths generated for Chrome contain -rw at the end while the same URL in Firefox doesn't contain that -rw.
Not digging very deeper, simply remove the -rw from the end of the URL and copy the image. You will get a PNG image. A hint is here for you:
<?php
$image_path = "https://lh5.ggpht.com/8PODwBXKk4L201m4IO1wifRDfbn4Q1JxNxOzj-5TXPJ85_S-vOqntLi7TsVyeFQM0w4=w300-rw"; // Firefox app on Google Play
$png_path = substr($image_path, 0, -3);
copy($png_path, 'file.png');
?>
This will save the image as PNG. Please note that I have used substr() function to remove -rw from the end. To make it precise, you may use any other way to fix that part of the path.
P.S. You may also try sending a custom user-agent (i.e. Firefox) with your CURL request to receive the PNG path so you will not need to fix it by yourself :)
You can use HttpResponse::getContentType to determine type of content you're getting from URL
This not a png, but WebP
You can use it in PHP with
imagecreatefromwebp( string $filename );
More information:
- https://developers.google.com/speed/webp/
- http://php.net/manual/function.imagecreatefromwebp.php
I actually want to upload an image to a server.
To achieve this, i want the user just paste the image into chrome (the image is a print screen in fact), and then i post the stream to a php page, convert the stream as an image, and then upload it.
How can i achieve this web application ?
Today i have develop some differents parts :
I used this script, and i create the Upload.php page which gets the post variable and try to Create and image.
The problem i have, is that when i post the data, i only get a blob. I would like to get a base64 stream.
Can you help me ?
Thanks in advance.
I'm not sure why you are specifically looking for a "base 64 stream". If you are sending the Blob to your server via ajax, as far as your server is concerned, it's a file. Treat it no different than any other upload server-side. A Blob is a File without a name property. That's perhaps a bit overly-simplistic, but my point is that, again, this is really nothing more than a file as far as your server knows.
Assuming you are sending a multipart-encoded request, I'd like to point out that most user agents will set the filename property of the item's Content-Disposition header in the request to "blob" when the item you are uploading is a Blob instead of a file. It is possible to change this value in some browsers via the 3rd argument in FormData's append method, but I wouldn't rely on this just yet.
Also note that, if you are interested in a library that handles all of this already, I maintain, Fine Uploader which natively supports uploading images via paste in Chrome.
To answer this old question: Posting an image from clipboard with chrome is pretty much the same as posting a dropped file - except that the image/blob doesn't have the properties "name" and "lastModified".
var entry = items[i].webkitGetAsEntry();
if (!entry) entry = items[i].getAsFile();
if (entry instanceof Blob) /** CHROME pastet Bilder als Blob **/
{
entry.isFile = true;
entry.lastModifiedDate = new Date();
entry.name = ""+new Date().getTime()+"."+entry.type.split('/')[1];
}
if (entry.isFile)
{
//handle dropped file
}
I have a PHP script that takes an images, checks type and filesize, then creates 2 resized copies of the master image, all 3 images are saved to the server. I was under the impression everything worked fine. I was testing out script and on one jpg image I got thrown the error "Content Encoding Error" by firefox. Doing some reading suggested this was a Firefox issue but testing in IE and Chrome resulted in similar errors.
The odd thing is that some .jpg files work, others don't. For those that don't work the error is occurring when the script comes to encode the second resized copy as the master, and first copy are outputted to specified folder. I have checked to see that the image itself isn't corrupt after doing some more reading. The only difference I could note between a .jpg that would allow the script to complete fully and one that wouldn't was that, when viewing the properties of the failing one within Windows it appeared to carry more data, such as camera used to, model number, etc.
Does anyone know what might be causing this error to be thrown?
EDIT
Here's the code I'm using.
$imgsrc = imagecreatefromjpeg($file);
imagecopyresampled($thbout,$imgsrc,0,0,0,0,$thbwid,$thbhei,$width,$height);
imagejpeg($thbout,$thbpath,80);
imagedestroy($thbout);
imagecopyresampled($optout,$imgsrc,0,0,0,0,$optwid,$opthei,$width,$height);
imagejpeg($optout,$optpath,80);
imagedestroy($optout);
Having played about a bit tonight I got it working, by switching the code to this. (Switch to create larger file first)
$imgsrc = imagecreatefromjpeg($file);
imagecopyresampled($optout,$imgsrc,0,0,0,0,$optwid,$opthei,$width,$height);
imagejpeg($optout,$optpath,80);
imagedestroy($optout);
imagecopyresampled($thbout,$imgsrc,0,0,0,0,$thbwid,$thbhei,$width,$height);
imagejpeg($thbout,$thbpath,80);
imagedestroy($thbout);
So I guess my new question becomes, why does it behave like this?
I am having trouble with the download helper in ie..basically I built a site that dynamically creates pdf invoices and pdf proofs in both cases the force download works great in firefox, chrome and opera. In IE it fails everytime and I get the following error:
Unable to download $filename from mysite.com
Unable to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.
To begin the force_download I have a anchor target _blank with a url that directs to the following controller:
function view_uploaded_file($order = 0, $name = NULL){
$this->load->helper('directory');
$params['where'] = array('id' => id_clean($order));
$data['order'] = $this->MOrders->get($params);
if($data['order']->id < 1){
redirect('admin/orders');
}
$name = db_clean(urldecode($name));
$map = directory_map('./uploads/customer_order_uploads/'.$data['order']->user_id.'/'.$data['order']->id, 1);
if(is_array($map) && in_array($name, $map)){
$this->load->helper('download');
$data = file_get_contents('./uploads/customer_order_uploads/'.$data['order']->user_id.'/'.$data['order']->id.'/'.urldecode($name));
force_download($name, $data);
} else {
redirect('admin/orders');
}
}
Originally I thought maybe a problem with MY IE but I am able to download PDFs on other sites. I then thought that it could be a problem with codeigniters download helper but I see they already made special provisions for IE in the helper.
If you have any ideas please let me know. Thank you.
Frankly I am not sure why we bothered with a helper for downloads in code igniter.
It's not entirely hard to do in pure php:
This Wonderful Question/Answer outlines how to do it quite nicely.
The real thing to remember is the content-disposition: attachment part of the headers. It's what tells the browser that the file should be downloaded & saved vs. trying to show it in the browser.
All browsers handle things differently, maybe you have something in your IE install that's overriding the behaviour but if you follow the instructions in the linked article, you should get files downloaded correctly in all browsers.
Essentially there are 3 things we need to tell the browser:
Content Type
File Name
How to treat the incoming data
(Optional Fourth, if you have it) File Size (Content-Length)
Then you just dump that data right out to the output buffer.
Response
In response to your replies, it's probably a security feature to not automatically download something in a popup window, probably one of the new things IE introduced to combat their previous security holes.
Well I have found atleast a temporary fix for the problem. All my links for force downloads were target _blank..once I created standard non pop out links the file downloads worked in IE. There is probably some type of work around but I just also realized there is really no need for a pop up window for the download anyway..the download dialog box already serves that purpose.
Last week I converted my page img src values from pointing at image files to using a PHP script to serve up the images. The primary reason was to accommodate both files and database BLOBs as the actual source.
Now when a user goes to a page, sometimes images show and sometimes not. If not, and the page is refreshed\reloaded, then the image appears. When images do not appear, sometimes it is an image the user has already accessed previously today.
I am stumped.
Here is the img tag:
<img src="../somedir/image_script.php?i=1234">
The image_script.php file figures out where to get the image from, then finishes up with:
header("Content-type: image/jpeg");
if($from_db){
print $image_blob;
} else {
$im = imagecreatefromjpeg($image_file);
imagejpeg($im,null,100);
imagedestroy($im)
}
I am using PHP 5.2.8 on IIS 6 using FastCGI. There are no cache headers on the image_script.php file nor on the directory it is in. Currently 99.9% of the images are file based, so I do not know if there is a difference in result between db-based and file-based images. When I go directly to image_script.php in my browser it returns the requested image (i=????) 100% of the time.
a> Any clue as to why the hit and miss with images being displayed? and,
b> what would be a proper way to actually cache the images served up by the PHP script? (they are very static)
Scott
Hmm. Can't tell for sure, but maybe your imagecreatefromjpeg is occasionally running out of memory? In that case, you'd serve an error message out as JPEG data and never see it, right?
Incidentally, wouldn't just grabbing the image file in as a string and shovelling it out without going through imagecreatefromjpeg/imagejpeg/imagedestroy be more efficient? It looks like you're reading a JPEG file, creating an internal PHP memory image from it, then reconverting it to a JPEG (at hefty 100% quality) then serving that data out, when you could simply read the JPEG file data in and print it, like you do from the database.
What happens if you do, say...
...
} else {
header ('Content-length: ' .filesize($image_file));
readfile ($image_file);
}