| Images retrives [message #175966] |
Fri, 11 November 2011 11:45  |
sritullimilli
Messages: 13
Registered: November 2011
Karma: 0
|
Junior Member |
|
|
i didn't get the images from mysql database through php script
i am get this error
<img src='���JFIF
....
plz suggest me
thx®s
|
|
|
|
|
|
| Re: Images retrives [message #175968 is a reply to message #175966] |
Fri, 11 November 2011 13:02  |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
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
> ...
> plz suggest me
>
> thx®s
First you need a script like this:
send_picture.php
<?php
open_database(); // some routine to open your picture database..
$id=$_GET['id'];
$query="select picture, picture_filename, picture_size from product
where id='".$id."'";
//echo $query;
$result=mysql_query($query);
if(($result>0) && (($rows=mysql_numrows($result)) == 1)) //got some data
{
$name=mysql_result($result,0,'picture_filename');
$content=mysql_result($result,0,'picture');
$size=mysql_result($result,0,'picture_size');
}
else die();
if ($name="") die();
$mtype=get_mime($name); // if you KNOW what type the picture is, you
dont need this
header("Content-Type: ".$mtype);
header("Content-Disposition: inline; filename=\"".$name."\"");
header("Content-Transfer-Encoding: binary");
header("Content-Length: ".strlen($content));
print $content;
// looks up mime type in /etc/mime.types and returns the type, or a
default if unmatched
// makes no attempt to interrogate the file content as such.
// THIS NEEDS MORE WORK!!! it doesn't get all types..espcially DWG/DXF!!
// Mind you we don't want to inmvoke plug-ins for these..
function get_mime($filename)
{
$default="application/force-download";
// first extract the extension
$array=explode(".",$filename); // split the name into the bits
separated by periods
$count=count($array);
if ($count<2) // if there IS NO extension..
return $default; // and let the user sort it out.
$ext=$array[$count-1]; // it will be the last element in the array..
$fp=fopen("/etc/mime.types", "r");
if(!$fp) return ($default); // no /etc/mime.types file
while (!feof($fp))
{ $buffer = fgets($fp, 128);
if (ctype_space($buffer{0}) || $buffer{0}=='#' || $buffer{0}=='\n')
continue; // skip empty lines. or lines starting with spaces
or hashes sscanf($buffer, "%s %s %s %s %s %s
\n",$mime_type,$extension, $extension1, $extension2, $extension3,
$extension4);
if ($ext==$extension || $ext==$extension1 || $ext==$extension2 ||
$ext==$extension3 || $ext==$extension4 )
{
fclose ($fp);
return($mime_type);
}
}
fclose($fp);
return $default;
}
?>
Then in your main php script
printf("<IMG src=\"send_picture.php?id=%d\" >",$id);
where id is the picture id in the database.
..
|
|
|
|
| Re: Images retrives [message #175969 is a reply to message #175966] |
Fri, 11 November 2011 14:10 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/11/2011 6:45 AM, 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
> ...
> plz suggest me
>
> thx®s
The <img ...> tag requires a resource (typically a file). It looks like
you're trying to send the image itself, which doesn't work.
It's really not had to send an image from a database. Basically you
need code similar to (example code for clarity - no error handling and
untested):
file: showimage.php
<?php
$imageId = intval($_GET['image']));
$link = mysql_connect('server', 'userid', 'password');
$result = mysql_select_db('database');
$result = mysql_query("SELECT image FROM imgtbl WHERE id=$imageId");
$img = mysql_fetch_assoc($result);
header('Content-type: image/jpeg');
header('Content-length: ' . strlen($result['image']));
echo $result('image');
mysql_close($link);
}
You would use this with something like:
<img src="showimg.php?image=5">
In this example the image id is assumed to be an integer. Strings work
also with appropriate changes to the code.
Also the image is assumed to be a jpeg; if you have something else, you
need to change the Content-type line to the appropriate type (i.e.
image/png, etc.).
The Content-length line isn't strictly required, but it will help some
Apache installations to optimize sending the image. It's nice to have.
Hope this helps.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| 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: 0
|
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>
|
|
|
|
| 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: 0
|
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.
|
|
|
|
| Re: Images retrives [message #175972 is a reply to message #175971] |
Fri, 11 November 2011 23:49 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Robert Hairgrove wrote:
> 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
>>
>> […]
>> 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].
>> […]
>> 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).
>> […]
>> [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.
That is appropriate if you do not have to support IE 7 [^6]. Unfortunately,
we have to.
Please trim your quotes to the relevant minimum next time, and use a proper
`From' header field value.
<http://www.netmeister.org/news/learn2quote.html>
<http://www.interhack.net/pubs/munging-harmful/>
As I suspect you might understand German, you should consider these:
[de] <http://www.afaik.de/usenet/faq/zitieren/>
[de] <http://www.gerlo.de/falsche-email-adressen.html>
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| 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: 0
|
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
]