Detection of the image from OBD

[Cleofas]

There is a request for OBD:

$result = mysql_query ("SELECT * FROM $userstable WHERE `id`=$counter", $db);   
$years_life = mysql_result($result,0,1);

$full_name = mysql_result($result,0,2);

$temp_content = mysql_result($result,0,3);

$image = mysql_result($result,0,4); // а вот тут сидит картинка из blob'а

Then html+php: <img align='left' class='img' src='".$image."' height='300' width='400'>

But it turns out the file, not the image itself (the browser doesn't understand this data set, because the browser still needs to expand the file to identify the data, the blob-pole stores only the data, not the expansion of the files, and the browser on the title of the file can't determine its type. And why does the headline contain data like a file if they're still unfit without expansion? No OS, no browsers on the headlines of the files themselves. They need to hand over Header-Al, extension.

Let's go back to the theme of the picture.
Reading in forums that the removal of the OBD image (MySQL) stored in blob-field does not exist as a direct request. And we need to write a separate php processor with a headline transfer.
Why does this field even exist in the OBD-MySQL? It's confusing. And from a more rational and convenient programming path (to put a FS file on the server and to keep an address in the OBD system).
And is it true that in my example, without an outside php processor, the images will not cost?

[simrah]

The src parameter at the current img implies that it would be the url of pictures. http://yousite.ru/image.php?id=$id And then your image.php will get the picture out of the blob and hand it over to the browser in two ways (as it is) without forgetting the right Content-type. header('Content-Type: image/jpeg');

Either, second option, you can all give the picture straight away, and IMG SRC has to use a special type reference starting begins. data:with the picture coded in base64. Details https://ru.wikipedia.org/wiki/Data:_URL ♪ But there are substantial restrictions in this way, such as in most cases such URL should not exceed 4CB. And this is base64, with this coding, the amount of information is increased by 1/3, so that the picture of about 3 KBayth can be as close as possible.

With regard to MySQL, it is an altogether DSB that has been developed for many purposes and is far from being used in the PHP when it is on the web pages. That's why it's not right to talk about her potential in "why this is not necessary on the web." No one prevents writing a program on the C++, which will tell scan the images of books, recognize them, put in the MySQL OBD contents and keep the original image in blob in case. And this OBD will be used in an annex, reading books written in Java and working on the reading of such books without any browser.

And with the file headlines, you're wrong, the browsers on the file's headline understand what this is, you can give the file an extension.jpeg, and there'll be a png and browser picture. The headings inside the file themselves are for this, and it is necessary that the contents can always be correctly determined without looking at the expansion curve. And by the way, if you give the picture as I wrote in option 1 for the browser, it's gonna be a file with expansion .php, but it won't stop him from painting that picture. And LOs, except windows, work exactly on the contents of the files. And in windows, expansion is only used as a waste. I don't have LOs know all the files in the world. You'll do your imaging format tomorrow, you think all the DS will know about it and start to understand the contents that it's a picture?