Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #3756 > unrolled thread

Images retrives

Back to article view | Back to comp.lang.php

Contents

  Images retrives sritullimilli@gmail.com - 2011-11-11 03:45 -0800
    Re: Images retrives "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2011-11-11 13:19 +0100
    Re: Images retrives The Natural Philosopher <tnp@invalid.invalid> - 2011-11-11 13:02 +0000
    Re: Images retrives Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-11 09:10 -0500
    Re: Images retrives Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-12 00:22 +0100
      Re: Images retrives Robert Hairgrove <nobody@hogwash.com> - 2011-11-12 00:34 +0100
        Re: Images retrives Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-12 00:49 +0100
        Re: Images retrives Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-11 19:37 -0500

#3756 — Images retrives

i didn't get the images from mysql database through php script
i am get this error

<img src='���JFIF 
...
plz suggest me 

thx&regs

[toc] | [next] | [standalone]

#3757

El 11/11/2011 12:45, sritullimilli@gmail.com escribió/wrote:
> i didn't get the images from mysql database through php script
> i am get this error
>
> <img src='���JFIF
> ...

The usual way to insert images in web sites is to use the <img> tag and 
write the picture's URL in the src attribute. E.g.:

<img src="picture.jpg">

https://developer.mozilla.org/En/HTML/Element/Img

While you can actually paste the full picture into your HTML document, 
it's not as simple as that: you'd have to add a prefix, escape the image 
properly and wait for IE users to complain:

http://es.wikipedia.org/wiki/Data:_URL

I guess you want to use the traditional approach. You have to write two 
different scripts: one that generates the HTML and one that generates 
the picture.


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[toc] | [prev] | [next] | [standalone]

#3758

sritullimilli@gmail.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&regs

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.
.

[toc] | [prev] | [next] | [standalone]

#3759

On 11/11/2011 6:45 AM, sritullimilli@gmail.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&regs

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3760

sritullimilli@gmail.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@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#3761

On 11/12/2011 12:22 AM, Thomas 'PointedEars' Lahn wrote:
> sritullimilli@gmail.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.

[toc] | [prev] | [next] | [standalone]

#3762

Robert Hairgrove wrote:

> Thomas 'PointedEars' Lahn wrote:
>> sritullimilli@gmail.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).

[toc] | [prev] | [next] | [standalone]

#3763

On 11/11/2011 6:34 PM, Robert Hair grove wrote:
> On 11/12/2011 12:22 AM, Thomas 'PointedEars' Lahn wrote:
>> sritullimilli@gmail.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@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web