临时解决方案可以参考：nginx服务器中文url无法访问导致404报错临时方案

http请求中的中文编码与网站服务器上的文件名储存编码不一致一定会导致404。

记录一下问题解决的思路与方案。

情景

nignx环境，dede程序（gbk版本）上传中文文件（程序已修改禁止自动重命名），url请求经测试为gbk编码，上传后的文件名却为utf8编码。

测试：

于是手动写了个简单的php上传脚本，发现：如果处理该文件上传的php程序文件为gbk编码，则上传的文件就是gbk编码；如果是utf8，则文件也是utf8，与程序中编码声明无关。

因此我将dede中select_soft_post.php文件编码改成了gbk编码，但前端上传结果提示乱码（意料之中），但是上传的文件还是utf-8的格式。

至于根本原因可能还不是程序编码的问题，有待研究。

解决方法

那么有以下三种思路可以解决，

方法一：将请求中的url中文编码改成utf-8格式

改了nginx.conf中http处于server处的charset为utf-8，但是仍然不奏效，系统环境编码为utf-8.

方法二：将文件默认储存名改成gbk编码

将环境变量给成en_US.GBK后，手动在服务器上新建中文文件，确实为gbk编码，url可以访问，但是由程序上传的文件还是不行，还特地给www用户环境变量也改了下，仍然不行。

所以这里可以总结出：如果修改环境变量中的编码，只针对用户生产文件的编码，而上传的文件是经过程序处理过的，并不是www用户直接生成。

方法三：将上传后的文件名urlencode编码一次

只剩这个方法了，在前端返回中文文件名的时候直接把文件名用gb2312编码一下不就就可以了？？

一般程序会直接用urlencode对中文名直接编码一下，这样确实可以，但是实测：点击上传后的文件后，前端返回的文件名被自动用utf-8解码了，所以直接显示就乱码。

其中返回文件名的js为：

<SCRIPT language='JavaScript'>

function nullLink()
{
 return;
}

function ReturnValue(reimg)
{
 if(window.opener.document.<?php echo $f?> != null)
 {
 window.opener.document.<?php echo $f?>.value=encodeURI(reimg);
 }
 
 var funcNum = <?php echo isset($CKEditorFuncNum)? $CKEditorFuncNum : 1;?>;
 if(window.opener.CKEDITOR != null && funcNum != 1)
 {
 
 window.opener.CKEDITOR.tools.callFunction(funcNum, reimg);
 
 }
 window.close();
}
</SCRIPT>

然后再测试一下，然后就很fuck了，因为默认还是用utf-8编码的，并没有任何卵用。

百度了一下js的gbk编码，发现还需要“定制”js。

单独分享了一篇文章：

js实现gbk格式的urlencode编码