Manual:Image administration/ja

この記事ではMediaWikiがどのように画像を取り扱い保存するのかについてと設定に関する情報を説明します.

アップロードされるファイルの他のタイプにも同じことが当てはまります. すべてのファイルは画像の名前空間に対応する記事で保存され、画像としてのみ参照されます.

アップロードと画像の使用
Help:Imagesをご覧下さい

画像のアップロードを有効にする
画像をアップロードするために、以下の条件を満たさなければなりません:


 * 1) MediaWikiのアップロードが有効になっている. $wgEnableUploadsをtrueに設定します.
 * 2) ファイルタイプが許可されなければなりません. 詳細は$wgFileExtensionsを参照.
 * 3) ユーザがログインしていなければなりません.

Specialpage Uploadでアップロードがなされます.

Manual:Configuring file uploads, Manual:Mime type detectionをご覧下さい

画像を取り扱うための関連パラメータ
以下のパラメータが関連しています:


 * Image configuration
 * Path configuration
 * Upload configuration

画像のサムネイル
MediaWikiの拡張された画像の構文によって画像を自動的にサムネイルすることが出来ます(ファイルのアップロード上に関する一般的に役立つ情報はManual:Configuring file uploadsをご覧下さい)

ビットマップ
ImageMagickの方がよりよいサムネイルを生産するのでこちらの方を推奨されます; ImageMagickはimagemagick.orgからダウンロードすることが出来ます. GDはboutell.com/gd からダウンロードすることが出来ます. どちらもデフォルトのMediaWikiインストーレションの一部ではありません.

画像のサムネイリングを有効にするためには、LocalSettings.phpで$wgUseImageResizeと$wgUseImageMagickをtrueに設定して下さい. $wgImageMagickConvertCommand変数が コマンドの適切な位置を指定し、コマンドはウェブサーバプロセスによって実行可能であることを確認して下さい.

SVG
MediaWikiはSVG画像のレンダリングをサポートしています: 有効にした場合、SVGは他の画像ファイルのように使用されます; それらは要求に応じて自動的にPNGファイルにレンダーされます. SVGサポートを有効にするためには以下のようにします:

最初に、SVGファイルのアップロードを出来るようにLocalSettings.phpで を設定して下さい. セキュリティ上の理由からMediaWikiはJavascriptを含むSVGは拒否することを留意して下さい. 誤検出(false positive)を避けるために、$wgAllowTitlesInSVG = true;を設定して下さい. ファイルが不正であるというエラーを取得する場合、mime type detectionが適切に動作していることを確認して下さい.

次に、$wgSVGConverterを使いたいレンダラに設定します. 利用可能なオプションはImageMagick、sodipodi、 inkscape、batik、とrsvgです. デフォルトはImageMagickですが、可能な場合他のレンダラの一つを使用することを推奨します. コンバータプログラムがシステムパスにない場合、$wgSVGConverterPathを使用してプログラムを含むディレクトリを指定しなければなりません.

画像の削除
画像はシスオペによってのみ削除できます(ユーザの権限が変更されていない限り).

このセクションにおいて"/images"フォルダ内のファイルの削除を説明します. 対応する記事は削除され他のMediaWikiの記事と同じようにリストアされます.

デフォルトの振る舞い
$wgSaveDeletedFilesパラメータはデフォルトでfalseに設定されています.

画像のリビジョンの削除
画像ファイルが変更された場合、画像記事に表示される画像ファイルのリビジョンの履歴が存在します. ノート: 画像記事リビジョンは画像リビジョンは個別のものです.

それぞれのリビジョンは"削除"のリンクを持ちます. これがクリックされると、リビジョンとファイルは恒常的に削除されます.

すべてのリビジョン/記事の削除
"すべてのバージョンを削除する"リンクを使用するもしくは記事を削除することが出来ます. 両方とも同じ結果です:


 * 記事が削除されます(リストア可能).
 * オリジナルの画像は削除されます(リストア可能ではない). (ちょっとしたバグがあります: MW 1.9.2に関してはサムネイルディレクトリが削除されません)
 * すべてのサムネイルが削除されます(リストア可能ではない).
 * dbテーブルにあるすべての対応する情報: image、imagelinkとoldimagesが削除されます

$wgSaveDeletedFiles = true;
すべての削除したファイルをアーカイブに保存するためには、$wgFileStoreをご覧下さい. この設定によって画像を復活させることが可能にします.


 * MediaWikiデータベースのFilearchive tableは削除した画像
 * /imagesDeleted フォルダは削除した画像を保持します.

データストレージ
画像がアップロードされたときはいつでも、次のものが作成されます:


 * 1) ファイルの正確な名前で画像の名前空間にある記事、例えばImage:MyPicture.png. この記事が保存され他の記事と同じように振る舞います.
 * 2) ファイル自身はホスティング(unix)システムのフォルダに保存されます
 * 3) ファイルの幅が800px以上もしくは高さが600px以上である場合、サムネイルは800pxの幅もしくは600pxの高さが作成されます. サムネイルはフォルダ(/images/thumb/x/xy/MyPicture.png/MyPicture.png)に保存されます. それぞれのサムネイルは独自の画像名によって独自のフォルダを取得します. サムネイルもしくは記事の範囲内でリサイズされた画像を作成するたびに、他のサムネイルが作成されそこに保存されます. 名前には例えば800px-MyPicture.pngといった幅とpxによる接頭辞が付けられます.

MediaWikiはimagesフォルダにいくつかのサブフォルダを作成します: x/xyなど:
 * x: 0からF
 * xy: xは受けのフォルダと等しい. y: 0からF.

このサブフォルダは$wgHashedUploadDirectory = true(デフォルト)の場合のみ現れます. xyは最後の画像ファイル名のmd5ハッシュの文字列の最初の2つです.

フォルダ
すべての画像ファイルは個別のフォルダに保存されます. デフォルトはpathofwiki/images/x/xy/MyPicture.pngです. 詳細については$wgUploadPathをご覧下さい.

/imageサブフォルダの説明:

注意: $wgHashedUploadDirectory = trueの場合、MediaWikiは/a/ab/foo.pngディレクトリ構造を使用します. falseに設定されている場合、これらのフォルダは作成されずすべての画像はimageディレクトリ自身に保存されます(これは約3MBのディスク上のスペースに保存します).


 * 0-f/x0-xf: これはオリジナルの画像ファイルのための保存場所です(最新のバージョン).
 * archive/0-f/x0-xf: これは新しいバージョンによって置き換えられるオリジナルの画像ファイルの保存場所です.
 * temp/0-f/x0-xf: 画像のアップロードのために使用されます. 不利ファイルはそのままです. (スペースの理由から)通常は削除されます. (Bug description: 画像をアップロードするとき、最初にtempに保存され移動します. 画像が既に保存されている場合、ユーザは警告されます. キャンセルのクリックをするとアップロード処理は停止しますが、画像はtempフォルダに残ります)
 * thumb/0-f/x0-xf: 0-fに対応します: 0-fにある画像のためにサムネイル(自動的に生成). これらが失われた場合、自動的に生成されます. フォルダ全体のサムネイルを削除する場合、it will build itself up.キャッシュ問題を体験するかもしれません.

データベーステーブル
注意: 削除された画像はここには保存されず、永久に削除されます.
 * Image:MyPicture.pngの記事: はページ、テキスト、リビジョンなどにある記事として保存されます.
 * table image: 画像のサイズといったメタデータを保持します. これはファイルへのリンクを含みません. ファイルの名前によっておそらくは計算され、画像の名前空間で記事を移動させることができない理由です.
 * table imagelinks: 画像が使用される記事の情報を保持します. (ページリンクに保存することが出来ますが、異なるテーブルを作成するために決定されました)
 * table oldimage: より新しいバージョンで置き換えられた画像のためのアーカイブです.
 * table filearchive: 削除された画像に関する情報を保持します.

スペースの使用
画像は記事よりもかなりのスペースが必要です. 次の計算はLinux/Unixサーバで4KBのブロックサイズを前提としています.

デフォルトの設定は$wgHashedUploadDirectory = trueです.

すべてのディレクトリに要求されるスペースです:


 * image ディレクトリ: 0-f/x0-f: max. 16*16 = 256 ディレクトリ = 256*4 KB = 1024 KB
 * archive : 0-f/x0-f: max. 16*16 = 256 ディレクトリ = 256*4 KB = 1024 KB
 * thumb ディレクトリ: 0-f/x0-f: max. 16*16 = 256 ディレクトリ = 256*4 KB = 1024 KB
 * temp ディレクトリ: 0-f/x0-f: max. 16*16 = 256 ディレクトリ = 256*4 KB = 1024 KB

それゆえ、アップロードされる画像無しのスペースの基本量は4MBです.

それぞれの画像のために必要なスペース:
 * オリジナル画像ファイルのサイズ + 平均2KBのオーバーヘッド

600ピクセル以上の高さもしくは800ピクセル以上の幅を持つ画像のために必要なスペース:
 * 作成されたサムネイルのサイズ + 平均2KBのオーバーヘッド(それぞれ)
 * サムネイルのためのディレクトリ(4KB) (それぞれの画像は独自のサムネイルディレクトリを持ちます)

例:
 * 20778バイトのpng画像(スモールサイズでサムネイル無し): 画像のために24KB: 合計24KB
 * 123.000バイトのjpeg画像(ビッグサイズ、自動サムネイル): 画像のために124KB、サムネイルディレクトリのために4KB、サムネイルのために64KB: 合計: 192KB

ファイルアクセス
アップロードされたファイルは一般的にはMediaWikiではなくウェブサーバによって提供されます. パスの暗号化(例えば、/c/c4/...)による曖昧化を通して最小限のレベルでのセキュリティがある一方で $wgHashedUploadDirectoryが設定されている場合、 パスはファイル名から簡単に計算でき本当の意味での保護ではありません.

認証ユーザへのアクセス制限については、Image Authorisationをご覧下さい

ライセンス
MediaWikiの機能はSpecial:Uploadページが画像のライセンシングを効率化することを可能にします. Wikipediaのアップロードページは画像要約の下のドロップダウンボックスのライセンシング機能を持ちます. この機能はデフォルトではoffになっています. この機能を有効にするために、シスオペはMediaWiki名前空間でLicensesページを編集する必要があります. 例です: MediaWiki:Licenses

ライセンスはwikiリストで特定のフォーマットを要求します.


 * subst:license 1|license 2|License text
 * Header 1:
 * cc-by-sa-2.5|Attribution ShareAlike 2.5

1行目は"License text"を作り画像ページでlicense 1のテンプレートを代用し license 2をトランスクルードします.

2行目はwikiテキストの"Header 1:"で無効された(grey out)ヘッダを表示します

3行目は"Attribution ShareAlike 2.5"を作り出し、画像ページ上でcc-by-sa-2.5テンプレートをトランスクルードします

実例については、http://en.wikipedia.org/wiki/MediaWiki:Licenses をご覧下さい

MediaWikiバージョン
以下の条件に当てはまります:


 * MediaWiki 1.9.x以降
 * 他のバージョンは検証されていません