| Re: Images retrives [message #175971 is a reply to message #175970] |
Fri, 11 November 2011 23:34   |
Robert Hairgrove
Messages: 19
Registered: September 2010
Karma:
|
Junior Member |
|
|
On 11/12/2011 12:22 AM, Thomas 'PointedEars' Lahn wrote:
> 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>
There are times when it is necessary to use something like C) ... for
example, to display on-the-fly generated captcha images. But these
wouldn't be stored in a DB, anyway.
If storing the JPEG data in a database is necessary, it could be saved
in base64 format in the first place ... this would save the extra
"computational effort" required on the server side, i.e. the PHP
function call to base64_encode(). The client browser, however, would
still need to parse the base64 data in order to display it.
Storing the link, or path to the file, is definitely the way to go for
images that don't change very often.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]