图片网址中的unicode字符-404 [英] unicode characters in image URL - 404

问题描述

我正在尝试打开名称中带有拉丁字符的图像(113_AtléticoMadrid ).

I am trying to open an image that has Latin characters in its name (113_Atlético Madrid).

我通过使用PHP函数 rawurlencode()对其名称进行编码来保存它，所以现在它的新名称为 113_Atl％C3％A9tico％20Madrid .但是，当我尝试通过该URL打开它时，例如 mysite.com/images/113_Atl%C3%A9tico%20Madrid.png ，我收到404错误.

I saved it by encoding its name with the PHP function rawurlencode(), so now its new name is 113_Atl%C3%A9tico%20Madrid. But when I am trying to open it by this URL for example mysite.com/images/113_Atl%C3%A9tico%20Madrid.png I got 404 error.

如何解决此问题?

PHP代码:

if(isset($_FILES['Team'])){
    $avatar = $_FILES['Team'];
    $model->avatar = "{$id}_".rawurlencode($model->name).".png";
    if(!is_file(getcwd()."/images/avatars/competitions/{$model->avatar}")){
        move_uploaded_file($avatar['tmp_name']['avatar'], getcwd()."/images/avatars/teams/{$model->avatar}");
    }
}

推荐答案

％编码用于URL.文件名不是URL.您使用以下形式:

%-encoding is for URLs. Filenames are not URLs. You use the form:

http://example.org/images/113_Atl%C3%A9tico%20Madrid.png

，然后Web服务器会将其解码为类似以下的文件名:

in the URL, and the web server will decode that to a filename something like:

/var/www/example-site/data/images/113_Atlético Madrid.png

当您准备将文件名放入URL时，应使用 rawurlencode()，但不应使用它来准备用于磁盘存储的文件名.

You should use rawurlencode() when you're preparing the filename to go in a URL, but you shouldn't use it to prepare the filename for disc storage.

这里还有一个问题，就是在光盘上存储非ASCII文件名在各个平台上都是不可靠的.特别是如果您在Windows服务器上运行，则PHP文件API(例如 move_uploaded_file())很可能会使用不需要的编码，并且最终可能会得到文件名，例如113_Atlético Madrid.png .

There is an additional problem here in that storing non-ASCII filenames on disc is something that is unreliable across platforms. Especially if you run on a Windows server, the PHP file APIs like move_uploaded_file() can very likely use an encoding that you didn't want, and you might end up with a filename like 113_Atlético Madrid.png.

不一定对此有一个简单的解决方法，但是您可以使用任何形式的编码，甚至％-encoding.因此，如果您坚持使用当前的 rawurlencode()来创建文件名:

There isn't necessarily an easy fix to this, but you could use any form of encoding, even %-encoding. So if you stuck with your current rawurlencode() for making filenames:

/var/www/example-site/data/images/113_Atl%C3%A9tico%20Madrid.png

可以，但是您必须使用double- rawurlencode 生成匹配的URL:

that would be OK but you would then have to use double-rawurlencode to generate the matching URL:

http://example.org/images/113_Atl%25C3%25A9tico%2520Madrid.png

但是无论如何，将潜在用户提供的任意字符串作为文件名的一部分包含在内都是非常危险的.您可能会遇到目录遍历攻击，其中名称包含诸如/../../之类的字符串，以访问目标目录之外的文件系统.(这些攻击通常会升级为通常在弱权限下部署的PHP应用程序的执行任意代码攻击.)您最好使用完全合成的名称，如@MatthewBrown建议的(+1).

But in any case, it's very risky to include potentially-user-supplied arbitrary strings as part of a filename. You may be open to directory traversal attacks, where the name contains a string like /../../ to access the filesystem outside of the target directory. (And these attacks commonly escalate for execute-arbitrary-code attacks for PHP apps which are typically deployed with weak permissioning.) You would be much better off using an entirely synthetic name, as suggested (+1) by @MatthewBrown.

(请注意，允许用户上传文件仍不是安全问题的结局，事实证明这是一项非常困难的功能.内容嗅探和插件仍然存在问题，可以允许图像文件上传到用户的计算机上.会被重新解释为其他类型的文件，从而导致跨站点脚本编制问题.为避免这种情况，最好仅从单独的主机名提供用户提供的文件，这样针对该主机的XSS不会帮助您针对主要站点的XSS.)

(Note this still isn't the end of security problems with allowing user file uploads, which it turns out is a very difficult feature to get right. There are still issues with content-sniffing and plugins that can allow image files to be re-interpreted as other types of file, resulting in cross-site scripting issues. To prevent all possibility of this it is best to only serve user-supplied files from a separate hostname, so that XSS against that host doesn't get you XSS against the main site.)

这篇关于图片网址中的unicode字符-404的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！