Philippe Verdy
Ты можешь:
- Либо создайте URL-адрес страницы PHP-запроса, который будет выполнять этот PHP-код, и используйте этот URL-адрес в атрибуте src стандартного тега HTML-изображения: браузер выполнит отдельный запрос к этому изображению по адресу PHP (убедитесь, что он доступен)
- Или если изображение небольшое (не более 8 КБ), используйте тег изображения, атрибут src которого использует URL-адрес с использованием схемы "data:", в которой вы можете кодировать содержимое изображения в Base64)
- Или вставки данных и URL-адрес изображения в CSS (есть примеры таких данных URL-адресов мелкие значки, встроенные в CSS таблица стилей, используемая на сайтах Викимедиа, такие как пользовательские маркеры, иконки для внешних ссылок; обратите внимание, что данные URL-адрес, также указывается ее тип носителя: она не ограничивается только JPEG или PNG, можно SVG-графики; в base64 является, вероятно, лучшей схемы кодирования для большинства растровых изображений; убедитесь, что вы сможете сжимать эти образы, чтобы удалить ненужные внутренние теги, или дополнительный пробел в SVG, прежде чем кодировать его в base64
There's a limit on the maximum size of "data:*" URLs accepted by browers, so it's probably not usable for embedding user profile images in JPEG/PNG formats that are larger than about 80x80 pixels; such compression should be made before storing the images in a Blob of your Postgres database; if images are larger, then you should better store them under a unique name based or your userid or on SHA1(content) in a filesystem (and use the first few bytes of the SHA1 as a directory folder to avoid having overclowded directories which may have long access time), and your your database to store a small text field containing the external filename. Here your example seems to be about storing a photo of a user in JPEG format, and such photos are frequently still too large to fit (once encoded in Base64 which expands their size by a factor of 4/3) in the limit of the "data:image/jpeg:*" url).
Note also that not all browsers support data URLs for images (especially old smartphones): you can mix the two approaches: embedded data URLs are fine for small images because they avoid additional delays, but they should still be cachable and they fit very well in reusable CSS stylesheets shared between users. But for individual user profiles it's probably preferable to use the external HTTP requests to your PHP script, and then use a URL parser to call the script with the relevant parameters; look for example how photos are stored and retrieved from Wikimedia Commons from a Wikipedia page, using a single script and an URL which is parsed to get the actual image name to retrieve (internally Wikimedia Commons indexes images by an internally generated unique ID specific to each image version, but images are retrieved by their name to query the database that returns the internal storage ID for specific versions, these images are then stored in a conventional filesystem using an hash of their ID and this hash is used to distribute the many files over a set of mounted disks and via a filesystem with a reasonnably cumfortable cache on the web server; the web server delivering the image is not necessarily the same as the werver for the database or the web server for your pages).
Some database servers also provide this mechanism for indexing and storing large blobs in an external fileserver directly, instead of actually storing these large blobs directly in indexed tables: I suppose you are using PostGresl use because of your code using "pg_connect()" and "pg_query()" to retrieve the bloc in PHP, but you may wonder if this is the best storage option if you need to store a lot of photos with possibly large resolutions (up to several MB per user photo). It may be faster and more efficient to store these photos on a separate mounted NFS folder where they will be served by something more efficient then a PHP script (directly using Apache capabilities), provided that you've configured the access rules for security or privacy (e.g. allowing such requests to be honored using unique access tokens in sessions coordinated between the file server and the main database server where access rights are managed).