Шпаргалко Сумасшедшего ПрограммЁра Waiting of summer

Водяной знак на PHP+GD

Собственно, совсем недавно была завершена некоторая работа - она была связана с программированием конвейера сборки большого числа изображений из отдельных картинок "конструктора". Для этого, само собой, пришлось накладывать полупрозрачные слои. При теоретических изысканиях данного вопроса - я обнаружил интересную особенность - при запросе "Водяной знак на PHP + GD" в сети нет нормальной, практической информации по этому поводу. Вас сначала погружают в дебри теоретических изысканий, вместо того, чтобы дать самодокументированный код. Я решил пойти иначе. Внизу - функция обеспечивающая наложение водяного знака на изображение. Из недостатков - то, что она работает только с изображениями формата PNG. Впрочем, программисту это исправить не проблема.

function watermark($_source_path, $_watermark_path, $_file='')
{
	/* Проверка - подключена ли библиотека GD - если её нет, вам необходимо либо самому подключить эту библиотеку
	* (В файле php.ini, секция extensions, необходимо прописать либо раскомментировать строку:
	*   extension=php_gd2.dll - в windows. */
	if (!extension_loaded('gd'))
	{
		return false;
	}
	if (!empty($_source_path) && !empty($_watermark_path))
	{
		$i_source    = imagecreatefrompng($_source_path);
		$i_watermark = imagecreatefrompng($_watermark_path);
		$result = imagecreatetruecolor(imagesx($i_source), imagesy($i_source));
		/* Координаты 0,0,0,0 - задают координаты соединения изображений.
		*  Поигравшись с ними можно изменить положение водяного знака (да и исходного изображения)
		*/
		imagecopy($result, $i_source, 0, 0, 0, 0, imagesx($i_source), imagesy($i_source));
		imagecopy($result, $i_watermark, 0, 0, 0, 0, imagesx($i_watermark), imagesy($i_watermark));
		imagedestroy($i_source);
		imagedestroy($i_watermark);
		if (!empty($_file))
		{
			imagepng($result, $_file, 4);
		}
		else
		{
			return $result;
		}
	}
}

Библиотечко для сохранения файлов по 300 штук в папке

Собственно говоря, посидел я тут на досуге, поразмышлял о нелёгкой судьбине веб-программиста. Часто приходится думать не только лишь о том, чтобы пообщаться с заливаемым файлом (ну или генерируемым - какова будет воля начальства либо заказчика), но и о правильном сохранении оного. Поясню, что я имею ввиду.

Как вам известно, просмотр одной папки с содержимым из 40 - 50 ТЫСЯЧ файлов любого формата операция достаточно ресурсоёмкая. В системные причины оного я не вникал, но подозреваю следующее. Перед выдачей файла на запрос, сервер лезет в папку указанную в адресе, и делает что-то вроде ls, ну или dir, что одно и то же. Просмотрев весь список файлов и найдя необходимый он выдаёт его юзеру. Тут впору загнуться и статическому веб-сайту, состоящему из одних html страниц. Так или иначе, решение было найдено многими поколениями программистов. В целевой папке (ну, допустим, uploads) создавать много подпапок, например по-номерам (1,2,3), и сохранять в них по фиксированному количеству файлов. Чаще всего по 300 штук.

Проблема по-большей части состоит в том, что каждый раз приходится сей алгоритм реализовать по-новой. Что совсем некошерно. Я в принципе реализовал его в виде универсального класса. Его достоинства в том, что там только два значимых метода: конструктор и функция save.

Работа тривиальна, создаём экземпляр класса FileSaver, в параметрах __construct() передаем:

1. Адрес родительской папки, к примеру /usr/bla/bla/domain.ru/www/uploads/, 2. максимальное количество файлов в подпапках, 3. создавать ли директорию, если она не существует, и 4. права на создаваемую папку.

Затем - каждый раз, когда нам надо сохранить в эту папку файл, мы вызываем метод save(), параметрами которого являются: 1. путь к перемещаемому файлу, должен содержать имя существующего файла, иначе метод вернёт false.

Второй параметр указывает, надо ли перезаписывать имя файла, либо оставить как есть у оригинала.

Третий параметр указывает на то, как формировать имя файла. При значении false он считает sha1-хэш файла, и именем файла ставит его, + расширение файла, если оно было. Этим мы обеспечиваем 1. уникальность имён, 2. уникальность файлов (если кто-то попробует поместить туда идентичный по содержимому файл, то хэши совпадут, и при условии сохранения в одну и ту же подпапку - ничего не выйдет, файл останется на месте). По умолчанию этот режим отключен, и имя файла формируется из текущего значения времени в unix timestamp + миллисекунды + случайное число из диапазона 1-10 + расширение оригинального файла.

ВНИМАНИЕ! Метод save осуществляет ПЕРЕМЕЩЕНИЕ файла со старого места в новое, если вам оно не надо, найдите в методе save участок (помечен комментарием), и измените там rename на copy. Возможно, в будущих версиях я сделаю более гибкую настройку модуля, но пока так.

Метод Save возвращает полный путь по которому был сохранён файл. Если вам надо иначе - в методе есть участок с комментарием, иллюстрирующим, как это сделать.

Вот, собственно, и всё. По мере наполнения структура директорий будет выглядеть так:

/uploads/

-- /1/

-- /2/

-- /3/

И так далее. По мере заполнения директории с крайнем индексом, создаётся новая, со следующим, и вперёд, с песней... Я сохранял туда 100 000 файлов, и потом благополучно делал обращение. Ничего, апач не загибался. Если попробовать сделать то же самое, когда они лежат в одной папке кучей - можно и не дождаться результата.

В заключение: ссылка на архив с модулем.