| Re: Images retrives [message #175973 is a reply to message #175971] |
Sat, 12 November 2011 00:37  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 11/11/2011 6:34 PM, Robert Hair grove wrote:
> 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.
Storing a JPEG in base64 is the WORST THING you can do. There is no
need to call base4encode() to disp;lay the image - and, in fact, will
result in a broken image.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]