Manual:Image administration/ru

Данная статья содержит сведения о том, как MediaWiki хранит файлы и о том, как настроить этот функционал.

Это относится к изображениям так же, как и к любым другим типам файлов, которые могут быть загружены (uploaded). Все файлы хранятся с соответствующей статьёй в пространстве имён "File:" ("Файл:"). MediaWiki до версии 1.14 использовали пространство имён "Image:" вместо "File:". "Image:" до сих пор поддерживается как псевдоним для обратной совместимости.

Загрузка и использование изображений
Смотрите: Help:Images

Включение функции загрузки файлов
Для загрузки файла должны совпасть три условия:


 * 1) Функция загрузки файлов в MediaWiki должна быть включена. Установите $wgEnableUploads в true.
 * 2) Тип файла должен быть разрешенным. Подробности: $wgFileExtensions.
 * 3) Пользователь должен входить в группу с правом "upload". По умолчанию это право дано всем авторизованным пользователям.

Загрузка файлов выполняется с помощью Special:Upload.

Смотрите Manual:Configuring file uploads, Manual:Mime type detection

Параметры, относящиеся к работе с файлами
Следующие параметры имеют отношения к функционалу работы с файлами:
 * Конфигурация изображений
 * Конфигурация путей
 * Конфигурация загрузок

Создание миниатюр изображений
Расширенный синтаксис изображений MediaWiki позволяет автоматически создавать миниатюры изображений (см. Manual:Configuring file uploads/ru по общей помощи по загрузке файлов).

функция создания миниатюр (Image thumbnailing) требует наличия ImageMagick или библиотеки GD. Рекомендуется использовать ImageMagick для получения миниатюр лучшего качества, загрузить его можно с imagemagick.org. Библиотека GD доступна для загрузки с libgd.org.

Ни один из этих компонентов не является частью mediawiki, хотя GD может идти как расширение PHP.

В старых версиях МедиаВики (до 1.10.0) для того, что бы включить создание миниатюр, требуется установить $wgUseImageResize в true. В новых версиях этого не требуется.

Если вы используете ImageMagick, установите $wgUseImageMagick в true в файле LocalSettings.php. Убедитесь что $wgImageMagickConvertCommand указывает на абсолютное положение команды конвертации и что команда выполнима для веб-сервера.

Для пересоздания старых файлов миниатюр, созданных до использования ImageMagic, используйте $wgThumbnailEpoch.

GIF
Для создания миниатюр для анимированных GIF-файлов ы среде Windows, вам потребуется установить ImageMagick согласно описанию выше.

SVG
MediaWiki поддерживает возможность рендеринга изображений в формате SVG: если такая возможность включена, изображения в формате SVG могут использоваться так же, как и любые другие — они будут автоматически растеризоваться и отображаться в виде файлов в формате PNG, с генерацией миниатюр «на лету», по мере необходимости.

Для включения поддержки SVG необходимо:


 * 1) Разрешите в LocalSettings.php возможность загрузки файлов SVG: $wgFileExtensions[] = 'svg'; Обратите внимание, что по соображениям безопасности MediaWiki откажется обрабатывать SVG-файлы, содержащие JavaScript. Чтобы избежать ложных срабатываний, установите $wgAllowTitlesInSVG = true;. Если вы получаете сообщение об ошибке, где говорится, что файл повреждён, убедитесь, что определение типа MIME работает нормально.
 * 2) Установите $wgSVGConverter, который вы хотите использовать для растеризации.
 * Можно выбирать из ImageMagick, sodipodi, inkscape, batik, rsvg, и imgserv.
 * 1) * Если путь к выбранному программному конвертеру не содержится в переменной окружения system path, то нужно явно задать папку этой программы посредством параметра $wgSVGConverterPath.
 * 2) * librsvg быстр, но не очень аккуратен. Этот пакет включён в весьма сложную цепь зависимостей, в которой вы можете и не захотеть разбираться, если только у вас нет под рукой содержащего эту программу репозитория, который разрешит все эти зависимости за вас. Проекты Викимедиа используют rsvg 2.14. Замечание: Начиная с версии 2.22.3, есть ошибка в вызове локальных параметров (locale handling) — см. сообщение об ошибке в багтрекере Викимедиа и сообщение об ошибке в багтрекере GNOME). Доступна заплатка для инструмента.
 * 3) * Batik обеспечивает наиболее точную отрисовку SVG среди доступных решений, хотя подчас недостаточно хорошо справляется со сглаживанием (anti-aliasing). У него более строгие правила разбора SVG, что заставляет его отвергать «почти правильные» SVG-файлы, принимаемые другими конвертерами (например, ). Батик основан на Java, и гораздо медленнее, чем rsvg, хотя это не может быть большой проблемой, если только вы постоянно не добавляете SVG-файлы. См. сравнительные тесты SVG. Требуется много усилий, чтобы заставить его работать, если только он не входит в ваш дистрибутив.
 * 4) * Inkscape также не слишком аккуратно обрабатывает SVG-файлы, и примерно в два раза медленне, чем rsvg. При этом он был спроектирован для интерактивной работы с графигой, поэтому требует, чтобы у запускающего его пользователя была на сервере домашняя папка (home directory) с правами на запись. Поскольку он будет работать как пользователь www или кто-то подобный, он будет пытаться создать папки .inkscape/ и .gnome2/ в соответствующей домашней папке, и молча сломается, если это ему не удастся. Inkscape предпочтительнее, чем rsvg, в случаях (а) если используется среда Windows (если говорить об отдельном пакете) или (б) если у вас имеются важные SVG-файлы, нарисованные в Inkscape, которые некорректно обрабатываются в rsvg. Inkscape связан сложной цепью зависимостей с librsvg &mdash; используйте, только если эти компоненты есть в вашем дистрибутиве или доступны в качестве полностью автономного пакета.
 * 5) * Sodipodi — это ответвление от Inkscape. Применимо всё то же самое, что и к Inkscape. Sodipod в настоящее время активно не разрабатывается.
 * 6) * ImageMagick обрабатывает SVG-файлы, но с массой ошибок. Кроме того, крайне медленно. Это значение по умолчанию, но избегайте его, если только это возможно.
 * 7) * Библиотека GD не способна преобразовывать изображения SVG в формат PNG, по крайней мере, согласно записи Джоя Асмуссена (Joen Asmussen) в блоге NoScope от июня 2008.
 * 8) * Многие современные веб-браузеры, за исключением Internet Explorer, умеют отображать файлы SVG напрямую — быстро, но неаккуратно (примерно так же, как ImageMagick). Использование librsvg для растенризации SVG и преобразования его в формат PNG даст гораздо более аккуратный результат. Прямое отображение SVG в MediaWiki по умолчанию не поддерживается.

JPEG (с использованием GD)
Об ошибках, связанных с созданием миниатюр JPEG-файлов, см. JPEG (с использованием GD).

TIFF

 * 1) Разрешите в LocalSettings.php возможность загрузки файлов TIFF: $wgFileExtensions[] = 'tif';
 * 2) Добавьте в LocalSettings.php параметр $wgTiffThumbnailType</tt> и установите его значение в jpg или png в зависимости от того, какой из этих форматов вы предпочитаете для создания миниатюр.
 * 3) Изготовление миниатюр для файлов TIFF может потребовать дополнительных системных ресурсов помимо тех, которые необходимы для миниатюр JPEG, GIF и PNG. Соответствующие настройки для этого — $wgMaxImageArea</tt> и $wgMaxShellMemory</tt>.

Удаление изображений
Файлы, как и вики-страницы, могут удалять только участники с правами « (delete)» (по умолчанию — ). Удаление файла вызывает также и удаление ассоциированной с ним вики-страницы с описанием (то же достигается, если перейти по ссылке «» в таблице «»).

Удаление отдельных версий файлов
Если файл был изменён, то история его изменений отображается на странице его описания. Каждая версия сопровождается ссылкой «». Перейдя по ней, можно навсегда удалить данную версию файла вместе с записью в истории изменений.

История версий файлов отличается от истории изменений страниц с их описанием.

Информация о старых версиях файлов хранится в таблице «oldimage».

Восстановление файлов
Вплоть до версии MediaWiki 1.8, удаление изображений/файлов было невосстановимым (могли быть восстановлены только связанные с файлами страницы описаний).

Начиная с версии MediaWiki 1.8 и вплоть до 1.10, архивирование удалённых изображений/файлов (и, следовательно, их восстановление) по умолчанию отключено, но может включаться через настройку $wgSaveDeletedFiles = true.

Начиная с версии MediaWiki 1.11, эта функция по умолчанию включена, и $wgSaveDeletedFiles считается устаревшим. Вместо этого, поведение в отношении файлов находится под контролем$wgFileStore.

Информация об удалённых файлах хранится в таблице «filearchive».

Хранение данных
Whenever an image is uploaded, several things are created:


 * 1) An article in the namespace image with the exact name of the file, e.g. Image:MyPicture.png. This article is stored and behaves like any other article.
 * 2) The file itself is stored in a folder of the hosting (unix) system.
 * 3) If the file is wider than 800px or higher than 600px, a thumb with either 800px width or 600px height will be created. The thumb is stored in the folder pathofwiki/images/thumb/x/xy/MyPicture.png/MyPicture.png. Each thumb gets its own folder by the name of the original picture. Any time you create a thumb or resized image within an article, another thumb is created and stored here, prefixed by its width in px, e.g. 800px-MyPicture.png.

MediaWiki creates several subfolders in the folder images: x/xy, where:
 * x: 0 to F
 * xy: with x equals the x of the upper folder and y: 0 to F.

This subfolders only appear if you have $wgHashedUploadDirectory = true (default). xy are the two first characters of the md5 hash of the final image filename.

Папки
Все изображения хранятся в отдельных папках. По умолчанию это pathofwiki/images/x/xy/MyPicture.png. Смотрите $wgUploadPath.

Note: If $wgHashedUploadDirectory = true, MediaWiki uses the /a/ab/foo.png directory structure. If set to false, these folders are not created and all pictures are stored in the image directory itself (this saves about 3 MB of space on disks).

Description of /image subfolders:


 * 0-f/x0-xf: This is the storage place for the original image files (most recent version).
 * archive/0-f/x0-xf: This is the storage place for the original image files, that have been replaced by newer versions.
 * temp/0-f/x0-xf: used for image uploading. Often old files remain here. They should be deleted regulary (for space reasons). (Bug description: When you upload a picture, it is first stored in temp and then moved. If the image already exists, the user gets a warning. If he then clicks on cancel, the upload process is halted, but the image remains in the folder temp.)
 * thumb/0-f/x0-xf: corresponds with 0-f: Thumbnails (automatically generated) for the pictures in 0-f. If these get lost, they are automatically regenerated. If you delete the whole folder thumb, it will build itself up. You may experience some cache problems.

Depending on the configuration, there may be additional /image subfolders:
 * math/0-f/x0-xf: Folder to store your rendered TeX input, see also Manual:Enable TeX or Math.
 * gnuplot: Used by Extension:Gnuplot to save your gnuplot graphs.

Таблицы базы данных

 * The article Image:MyPicture.png: is stored as any article in page, text, revision etc.
 * table image: Holds some meta data like the size of the image. It does not contain the link to the file. This is probably calculated by the name of the file and the reason why it is not possible to move articles in the namespace image.
 * table imagelinks: Holds the information in which article an image is used.
 * table oldimage: This is the archive for pictures that have been replaced with newer versions. Note: Deleted pictures are not stored here, they are permanently deleted (or, in newer MediaWiki versions, moved to the filearchive).
 * table filearchive: holds the information on the deleted images.

Использование дискового пространства
Pictures need considerably more space than articles. The following calculations assume a block size of 4KB with Linux/Unix servers.

Настройка по умолчанию выглядит как $wgHashedUploadDirectory = true.

Требуемое дисковое пространство для всех папок:


 * image directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * archive directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * thumb directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * temp directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB

Therefore, the basic amount of space needed without any images uploaded is 4 MB in theory (although the directories are created only when needed).

Для каждого изображения необходимо:
 * size of the original image file + 2 KB average overhead

Для изображений высотой более 600 пикселей или шириной более 800 пикселей:
 * size of the created thumbnail(s) + 2 KB average overhead (each)
 * directory for thumbnail (4KB) (each image has its own thumbnail directory)

Примеры:
 * image 20778 Byte png (small size, no thumb): 24 KB for the image: Total 24 KB
 * image 123.000 Byte jpeg (big size, auto thumb): 124 KB for the image, 4KB for the thumb directory, 64 KB for the thumb: Total: 192 KB

Доступ к файлам
Uploaded files are generally served directly by the web server, not through MediaWiki. While there may be a minimal level of security through obscurity with path encryption (eg. /c/c4/...) if $wgHashedUploadDirectory is set, the path can be calculated easily from the file name and does not provide true protection.

For limiting access to authorized users, see Image Authorization

Лицензирование
A feature of MediaWiki allows the Special:Upload Page to streamline licensing of images. Wikipedia's Upload Page has a Licensing drop down box below image summary. This feature is turned off in default MediaWiki. To turn this feature on a sysop needs to edit Licenses in the MediaWiki namespace. Example: MediaWiki:Licenses

Licenses expects a certain format in a wiki list.

Line 1 will produce "License text" and substitute the license 1 template in the image page and transclude license 2.

Line 2 will show a greyed out header with text "Header 1:"

Line 3 will produce "Attribution ShareAlike 2.5" and transclude template cc-by-sa-2.5 on the image page.

For detailed real world example, see http://en.wikipedia.org/wiki/MediaWiki:Licenses

Внешние хранилища
It is possible to access files stored in foreign repositories, without needing to upload them to the wiki, by setting the $wgForeignFileRepos array. This feature offers several possibilities:
 * ForeignAPIRepo accesses files from a remote MediaWiki installation, such as Wikimedia Commons, through its API
 * ForeignDBRepo accesses files through a database, and is useful for creating wiki families
 * FSRepo accesses files from a local folder

In all cases, one would be able to embed files into a page using ordinary image syntax and specifying the name of the file in the foreign repository. Note that some of the above implementations are still experimental, and might not be suitable for high-traffic sites.

If one merely wants make a file accessible from one's site, an alternative to implementing all of the above is:
 * 1) Place the file in e.g., images/
 * 2) Link to it in wikitext via [/images/lawnmower.png My lawnmower]

Версии MediaWiki
Применимо к версиям:
 * MediaWiki 1.9.x и выше
 * другие версии не проверялись