| Re: Images retrives [message #175970 is a reply to message #175966] |
Fri, 11 November 2011 23:22   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
sritullimilli(at)gmail(dot)com wrote:
> i didn't get the images from mysql database through php script
> i am get this error
>
> <img src='���JFIF
You are trying to output the raw image data as a string (JFIF means "JPEG
File Interchange Format" [1]). This cannot work (at least not this way);
the `src' attribute value must be a URI [2].
> ...
> plz suggest me
There are several alternatives. For example:
A) Write and access a temporary file
<?php
$img_data = db_query(…);
if ($img_data)
{
/*
* Use the _correct_ filename suffix here; the server
* should take care of the proper Content-Type for that suffix
*/
file_put_contents("{$tmp}/foo.jpg", $img_data); // [3]
}
?>
…
<img src="tmp/foo.jpg" alt="…" …>
B)
<?php
/* foo.php */
$img_data = db_query(…);
if ($img_data)
{
/* declare the _correct_ type here */
header('Content-Type: image/jpeg'); // [4]
echo $img_data;
}
?>
bar.html:
<img src="foo.php" alt="…" …>
C)
<?php
$img_data = db_query(…);
if ($img_data)
{
?>
<img src="data:image/jpeg;base64,<?php
echo base64_encode($imgdata); // [5]
?>"
alt="…" …>
<?php
}
?>
A) and B) are more compatible than C) [6].
A) works well for images that do not change often and need to be retrieved
fast in short intervals (such as in an e-commerce shop); you only have to
write the file once, after which accesses are cached by the Web server's
filesystem, the server's HTTP server service/daemon and the browser's HTTP
client. There are no limits on the size of the file other than imposed by
the server filesystem.
B) is more flexible than A) and requires no additional server filesystem
resources, but is overall slower than A) even though it can be cached by the
browser. I am presently not aware of any limits to image file size.
C) requires fewer server filesystem resources than A) but it might not be
cacheable and it requires more computational effort on the server and
client-side instead. It is limited by the maximum URI length accepted by a
Web browser (2083 characters by Internet Explorer up to and including
version 9.x, at the time of writing [7]); in particular, base64 encoding
makes the encoded string about one third longer than the original. (By
contrast, URI percent-encoding can make the encoded string three times as
long as the original.)
Use A) or B) unless there is a compelling reason to use C).
I also recommend not to store image data or other BLOBs in the database
unless there is a compelling reason to do otherwise. Store the filename in
the database instead, and store the image data as a file in the filesystem;
that way, it is also easier to implement A).
PointedEars
___________
[1] <http://de.wikipedia.org/wiki/JPEG_File_Interchange_Format>
[2] <http://www.w3.org/TR/html401/struct/objects.html#edef-IMG>
[3] <http://php.net/file_put_contents>
[4] <http://php.net/header>
[5] <http://php.net/base64_encode>
[6] <http://en.wikipedia.org/wiki/Data_URI_scheme>
[7] <http://support.microsoft.com/kb/208427/en-us>
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]