MultipartFile中transferTo(File file)的路徑問題

今天看到layui的文件上傳的控件，就嘗試了一下。簡單創建了一個SpringMVC項目。記得在配置文件中注入以下Bean。

<!-- 定義文件上傳解析器 -->
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
    <!-- 設定默認編碼 -->
    <property name="defaultEncoding" value="UTF-8"></property>
    <!-- 設定文件上傳的最大值爲5MB，5*1024*1024 -->
    <property name="maxUploadSize" value="5242880"></property>
    <!-- 設定文件上傳時寫入內存的最大值，如果小於這個參數不會生成臨時文件，默認爲10240 -->
    <property name="maxInMemorySize" value="40960"></property>
    <!-- 上傳文件的臨時路徑 -->
    <property name="uploadTempDir" value="fileUpload/temp"></property>
    <!-- 延遲文件解析 -->
    <property name="resolveLazily" value="true"/>
</bean>

 

我很懶，這些屬性都沒有配置，就註冊了Bean。
接下來是我出錯的地方。先上Controller代碼，前臺通過Layui的文件上傳模塊上傳文件。

@ResponseBody
    @RequestMapping("/upload")
    public Map upload(HttpServletRequest request,MultipartFile file){
        HashMap<String,String> map=new HashMap();
        if (!file.isEmpty()) {
            try {
                // getOriginalFilename()是包含源文件後綴的全名
                String filePath = "D:/upload/test/"+file.getOriginalFilename();
                System.out.println(filePath);
                File saveDir = new File(filePath);
                if (!saveDir.getParentFile().exists())
                    saveDir.getParentFile().mkdirs();
                file.transferTo(saveDir);
                map.put("res","上傳成功");
                return map;
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
        map.put("res","上傳失敗");
        return map;
    }

 

transferTo方法中傳遞的file如果是路徑的話，那麼它會將最後一層路徑當做文件名，沒有後綴的那種。此時重命名這個文件，更改成和上傳文件一致的後綴那麼就可以打開了。
比如我將

 String filePath = "D:/upload/test/"+file.getOriginalFilename();

    1

改成

String filePath = "D:/upload/test";

    1

運行之後打開文件發現這樣的：
在這裏插入圖片描述
transferTo將我想作爲文件夾的test當做文件名了。我加個後綴.jpg
在這裏插入圖片描述
和上傳的文件一致。

最後個人理解爲傳入的File參數是應該包含文件而不是文件路徑，transferTo()並不會將文件轉存到文件夾下。
————————————————
版權聲明：本文爲CSDN博主「cliche_tune」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/cliche_tune/article/details/102901241