Manual:$wgAllowExternalImages/zh

是否允许行內显示外部网站的图像有时被称作直接链接.

详情
当设定为 时，用户可以从外部 URL 直接插入图片. 用户可以直接将指向其他网站图片的 URL 全文直接插入 wiki 文本中（而不需要其他标记包裹）.

当设定为  时， URL 全文会显示为指向该图片的文字链接.

请注意如果您只需要允许受信任的单独来源（例如您自己的域名），那么请将此变量设置为 false ，并使用.

外部图像的缩图
縮圖是使用 MediaWiki 資料庫中的尺寸信息從上傳的圖像生成的. 由於外部圖像在 MediaWiki 資料庫中沒有條目，因此無法創建縮圖.

如果這些圖像已經上傳到另一個 MediaWiki 或者它們在您網站的某個地方並且您想讓 MediaWiki 製作它們的縮圖，您可以設置： 為真並設置 與  而不是啟用外部圖像.

为什么要允许外部图像？
知道如何獲取圖像的 URL 的用戶可能會發現這是一種非常有用的方法，可以使用網絡上其他地方提供的圖像資源向 wiki 文章添加插圖.

如果沒有此功能，用戶將「被迫上傳」他們想要直接嵌入到文章中的任何圖像. 上傳圖像在許多方面更加繁瑣和耗時. 當然，它還使用 wiki 網路伺服器上的硬碟空間和頻寬. 行內圖像有許多合法用途.

此外，這允許嵌入不時「更改」或根據請求生成的外部圖像，例如來自監控軟件（如 Cacti）的圖形——如果圖像可以通過其副檔名識別為圖像檔案. 如果啟用了嵌入，還可以使用語法 [Link_URL Embedded_Image_URL] 製作嵌入的圖像鏈接，這將導致對圖像的點擊鏈接到 Link_URL.

(MediaWiki 將只識別帶有圖像檔案副檔名的圖像 URL；您可能需要在某些 URL 的末尾添加一個「偽」參數，例如 「&junk=junk.png」或 「?.png」以強制解析器實現 Image_URL 實際上指向一個圖像，然後嵌入它. )

为什么不允许外部图像？
Inline external images are disallowed on across many Wikimedia projects, and MediaWiki has AllowExternalImages set to false by default since version 1.6.9. The reasons for this are:

To prevent malicious gathering of browser data. Every time your browser fetches an image (or a web page for that matter) it also submits various bits of data to the webserver in its request. This includes your IP address, the URL of the page you were looking at (the wiki site), and cookies (information about previous requests to that same webserver).

Now with external images enabled, a user can be fetching images from other webservers. A malicious (or devious) person could make wiki edits to set up an external image URL on your wiki, purely for the purpose of gathering this data about your visitors. No need to panic! They wouldn't get credit card numbers or anything, just the kind of data that is sent every time you visit a website. But this might allow them to build up a (rather fuzzy) picture about visitors to your site, which might be correlated with similar data from other sites, and could potentially give rise to privacy concerns. It's the kind of data that has a value to marketing companies, a list saying "The person on this IP address is interested in this kind of website"

An image URL added for this purpose, is an abuse of your wiki, which (unless you disallow it) you will need to look out for along with more conventional Wiki Spam attacks. Note that the actual image could be a miniscule 1x1 pixel images, and so as with wiki spam, you won't necessarily see it on the page itself, but you will see the edit on your 'recent changes'. Conventional Anti-spam features (such ) will counter these kinds of URL along with normal link spam.

To prevent (or reduce the impact of) certain types of vandalism. People can still upload offensive images to your wiki, but this option will prevent people inline linking to offensive images, which might make that kind of vandalism less prevalent. If you do allow external images, then removing abusive image links is always a matter of a simple wiki edit (followed by whatever conflict resolution/banning action you wish to take)

To prevent "bandwidth theft" from other sites. A wiki administrator might wish to avoid being accused of bandwidth theft due to inline linking.

This is only of concern in cases where your wiki is linking to a web server/host belonging to somebody else, and that person was not involved or consulted in setting up the link (a wiki edit) In that situation the person might object to such links. Of course removing the link is as simple as editing the wiki, but it should be noted that inline linking in this kind of situation is widely regarded as bad netiquette (even if you are very happy to remove on demand).

In many other situations, bandwidth theft is not a concern:


 * There are some websites which explicitly encourage inline linking to images they host (note that sometimes terms & conditions are attached to inline linking e.g. they require a textual link/acknowledgement)
 * A contributor might decide that images they are hosting on their own website could appear on a wiki page, and so they set up the inline link themselves.
 * Often it might be useful to allow inline linking to images hosted on the very same webserver as the wiki (which are just not uploaded into the wiki), or images hosted as part of the same overall project/organisation. (You could use to specify this as an exception instead)

To prevent "link rot". An image on another site may have been valid when a wiki article was originally created, but there is no guarantee that an independent external site will remain up, with the same content at the same URL, in the future. Any change in the design of the external site has the potential to break external links to individual files on that site. The same problem exists for textual hyperlinks of course, but for broken image references you will wind up with an ugly error box if the link is broken.

To ensure you are hosting all resources. You might wish to disallow inline linking in order to ensure that all images resources appearing on your wiki, are available from your wiki. If you have good hosting bandwidth, you might want to make full use of this and avoid any slowdown in browsing experience due to images being fetched from elsewhere. You might also want to ensure you are gathering all the image resources locally, in order to offer up all your content as a download.

For consistency in handling images. Uploaded images are added to a wiki page using a different wiki syntax. Having two different syntaxes and two different approaches to adding images, could cause confusion for some novice users. If you disallow external images, users must always follow the same upload procedure, and use the same syntax. Also it means images always have the same click behaviour (taking you to the image page)

图像描述
You cannot easily put an image caption for external images. One solution is by using a table.

参见

 * - Allow using html-style tags. Useful to resize images, etc.. Only available for MW 1.17+
 * - Only allow external images from a given source or sources.
 * - Enable an on-wiki page to define what external images are allowed.
 * - Enable using images from Wikimedia Commons.