不知道什么回事，图片就是读不出来，但是看网页源代码，有图片路径，单独访问图片路径也可以读到图片，但是在jsp中读不到，可能是过滤器或者拦截器的原因，不知道了，问问各位大神。
下面时spring MVC上传代码：String path = null;
//将当前上下文初始化给  CommonsMutipartResolver (多部分解析器)
CommonsMultipartResolver multipartResolver=new CommonsMultipartResolver(
request.getSession().getServletContext());
//检查form中是否有enctype="multipart/form-data"
if(multipartResolver.isMultipart(request))
{
//将request变成多部分request
MultipartHttpServletRequest multiRequest=(MultipartHttpServletRequest)request;
//获取multiRequest 中所有的文件名
Iterator iter=multiRequest.getFileNames();
while(iter.hasNext())
{
//一次遍历所有文件
MultipartFile file=multiRequest.getFile(iter.next().toString());
if(file!=null)
{
path=request.getServletContext().getRealPath("")+"\\image\\"+file.getOriginalFilename();
//上传
file.transferTo(new File(path));
}
}
}
存入数据库的路径是这样：D:\Tomcat\apache-tomcat-7.0.42\webapps\students\image\QQ图片20180531181825.jpg，在jsp页面中图片路径就是这个，但是就是显示不出来，请问该怎么修改才能在将图片在jsp页面中显示出来，还有， 我这个是不是没有将图片存到服务器上啊？ 求教各位了，谢谢

	

写在前面
知道我的人都应该很清楚，我的日常工作环境就是 Windows。为啥没有用 macOS？因为买不起；为啥不用 Linux？因为折腾不起。后两者我多少都尝试了半年以上，最后还是转回 Windows。不可否认，macOS和Linux不同发行版，对开发效率都有帮助。但对于我个人来说，windows是最好的选择：
用了快二十年windows，习惯在那里
身边绝大多数用Windows，从方便沟通的角度出发，这是最好的选择
TBtools 的主要用户在Windows下工作，macOS用户最多不到10%，从TBtools开发的角度出发，这也是最好的选择
回到主题，无论我们在哪类系统下工作，常常会要一些软件使用问题。这些软件可能需要我们通过文件对话框选择具体输入文件，这是一个非常尴尬的事情，比如
对于大多数程序的对话框，我们需要一直在菜单中跳转跳转跳转，直到找到文件。当然，其实 TBtools 几乎所有文件输入框都支持拖拽放置 - 自动获取路径。
但我们并不排除一些特殊情况，比如用户以管理员身份打开 TBtools，发现不能拖拽放置。这主要还是文件系统的安全权限设置问题。
问题当然不仅于此，我们会在很多时候，其实需要的不是复制文件，而是复制文件完整路径。比如，需要这个文本信息
C:\Users\ccj04\Desktop\XPS 13 迁移\Gene Density Profile\Arabidopsis_thaliana.genome.gff3
解决办法
Emmm，一直以来，我有一个解决办法：
首先，右键当前文件，重命名并复制文件名
黏贴到 Everything
在 Everything 中右键文件，复制完整路径和文件名
然而，这明显不优雅，而且涉及两步操作。
早上起来，越想越不爽。一顿搜索，找了系列解决方案：
安装一些右键菜单管理软件，- 太麻烦，不要
人工修改注册表 - 太麻烦，也不要
.reg 文件，双击运行搞定 - 可行
网络上存在三五个不同版本的 .reg 文件，可以自动修改注册表并完成这项，但多少存在一些问题：
复制出来的路径有双引号，多数时候会影响程序运行，尤其是 TBtools
复制时，会弹出 CMD 黑框，不优雅
没有 icon
只有增加菜单项，没有删除菜单项
综合以上，我鼓捣了一波，于是得到两个.reg文件，
操作步骤
首先看看原始右键菜单
操作简单，双击文件
选择是，
点击确定即可，再看看现在的菜单
于是，只要对于每个文件/文件夹，右键即可复制路径，如下：
C:\Users\ccj04\Desktop\XPS 13 迁移
如何获取
顺便测试一下公众号的关键词检索功能，大体可以在生信札记公众号，输入关键词如：
复制路径
路径
复制
右键菜单
。。。
公众号就会自动回复文件下载链接(后续有可能更新，公众号回复可以随时更新)...
似乎完美
写在后面
有时候，折腾一下，生活会变得更轻松。还是那句话，工欲善其事，必先利其器。
这波操作，就像我写 TBtools 一样，用户开心，而我自己也是用户。

最大路径长度限制
在Windows API(以下段落中讨论一些例外)中，路径的最大长度是MAX_PATH ，定义为260个字符。 本地路径按以下顺序组织：驱动器号，冒号，反斜杠，用反斜杠分隔的名称组件以及终止的空字符。 例如，驱动器D上的最大路径为“D：\ 一些256个字符的路径字符串 ”，其中“”表示当前系统代码页的不可见的终止空字符。  (字符<>在这里用于视觉清晰，不能是有效路径字符串的一部分。)
现在我们看到它是1 + 2 + 256 + 1或[驱动器] [：\] [路径] [空] = 260。人们可以假设256是一个合理的固定字符串长度从DOS天。 回到DOS API，我们意识到系统跟踪每个驱动器的当前路径，并且我们有26个(带有符号的32个)最大驱动器 (和当前目录)。
INT 0x21 AH = 0x47表示“该函数返回没有驱动器号和初始反斜杠的路径描述”。因此，我们看到系统将CWD存储为一对(驱动器，路径)，并且通过指定驱动器(1 = A，2 = B，…)，如果指定了0，则它将假定由INT 0x21 AH = 0x15 AL = 0x19返回的驱动器的路径。 所以现在我们知道为什么它是260而不是256，因为这4个字节不存储在路径字符串中。
为什么一个256字节的路径字符串，因为640K是足够的RAM。
这是不正确的，因为NTFS文件系统支持多达32k个字符的路径。 您可以使用win32 api和前缀“ \\?\ ”来使用大于260个字符的路径。
.Net BCL团队博客的详细解释。
一小段摘录突出了长路径的问题
另一个问题是暴露长途支持导致的行为不一致。 带有\\?\前缀的长路径可用于大多数与文件相关的Windows API，但不能用于所有的Windows API。 例如，如果文件名比MAX_PATH长，将模块映射到调用进程地址的LoadLibrary失败。 所以这意味着MoveFile将让你移动一个DLL到一个位置，使得它的路径长度超过260个字符，但是当你试图加载DLL时，它会失败。 整个Windows API都有类似的例子。 一些解决方法存在，但他们是在个案的基础上。
问题是为什么限制仍然存在。 当然，现代Windows可以增加MAX_PATH的一面以允许更长的路径。 为什么限制没有被删除？
它不能被删除的原因是Windows承诺永远不会改变。
通过API合约，Windows已经保证所有的应用程序标准文件API永远不会返回超过260字符的路径。
考虑以下正确的代码：
WIN32_FIND_DATA findData; FindFileFirst("C:\Contoso\*", ref findData);
Windows 保证我的程序将填充我的WIN32_FIND_DATA结构：
WIN32_FIND_DATA { DWORD dwFileAttributes; FILETIME ftCreationTime; FILETIME ftLastAccessTime; FILETIME ftLastWriteTime; //... TCHAR cFileName[MAX_PATH]; //.. }
我的应用程序没有声明常量MAX_PATH ，Windows API的值。 我的应用程序使用该定义的值。
我的结构是正确定义的，只分配总共592字节。 这意味着我只能够收到少于260字符的文件名。  Windows 向我保证 ，如果我正确地写了我的应用程序，我的应用程序将在未来继续工作。
如果Windows允许文件名超过260字符，那么我现有的应用程序(正确使用正确的API)将会失败。
对于任何要求Microsoft更改MAX_PATH常量的人，他们首先需要确保没有现有的应用程序失败。 例如，我仍然拥有并使用Windows 3.11上编写的Windows应用程序。 它仍然在64位Windows 10上运行。这就是向后兼容性。
微软确实创造了一种使用完整的32,768路径名称的方法; 但他们必须创建一个新的API合同来做到这一点。 首先，您应该使用Shell API来枚举文件(因为不是所有的文件都存在于硬盘或网络共享中)。
但他们也不得不破坏现有的用户应用程序。 绝大多数应用程序不使用shell API来进行文件工作。 每个人都只需调用FindFirstFile / FindNextFile并在一天内调用它。
您可以将文件夹安装为驱动器。 从命令行，如果你有一个路径C:\path\to\long\folder你可以把它映射到驱动器号X: using：
subst x: \path\to\long\folder
从Windows 10.您可以通过修改注册表项来删除限制 。
提示从Windows 10版本1607开始，MAX_PATH限制已从常见的Win32文件和目录函数中删除。 但是，您必须选择新的行为。
注册表项允许您启用或禁用新的长路径行为。 要启用长路径行为，请在HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (类型： REG_DWORD )上设置注册表项。 在第一次调用受影响的Win32文件或目录函数(下面的列表)后，系统(每个进程)将缓存该键的值。 注册表项在进程的生命周期内不会被重新加载。 为了让系统上的所有应用程序识别密钥的值，可能需要重新引导，因为在密钥设置之前某些进程可能已经启动。 注册表项也可以通过Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths组策略进行控制。 您也可以通过清单为每个应用程序启用新的长路径行为：
true
处理路径限制的一种方法是使用符号链接来缩短路径条目。
例如：
创建一个C:\p目录来保持较长的路径的短链接
mklink /JC:\p\foo C:\Some\Crazy\Long\Path\foo
将C:\p\foo添加到您的路径而不是长路径
至于为什么这仍然存在 –  MS不认为它是一个优先事项，并且在推进他们的操作系统(至少在这种情况下)向后兼容。
我使用的解决方法是使用路径中目录的“简称”，而不是标准的，人类可读的版本。 因此， 例如对于C:\Program Files\我将使用C:\PROGRA~1\您可以使用dir /x找到短名称等价物。
至于如何应对Windows上的路径大小限制 – 使用7zip打包( 和解压缩)您的路径长度敏感的文件似乎是一个可行的解决方法。 我用它来传输几个IDE安装(这些Eclipse插件路径，yike！)和一堆自动生成的文档，到目前为止还没有一个单一的问题。
真的不知道它是如何逃避Windows设置的260个字符限制(从技术PoV)，但嘿，它的工作原理！
有关SourceForge页面的更多详细信息，请访问 ：
“NTFS实际上可以支持长达32,000个字符的路径。”
7-zip也支持这么长的名字。
但在SFX代码中禁用。 有些用户不喜欢漫长的路径，因为他们不知道如何使用它们。 这就是为什么我已经禁用它在SFX代码。
并发布说明 ：
9.32阿尔法2013-12-01
改进了对超过260个字符的文件路径名称的支持。
4.44测试版2007-01-20
7-Zip现在支持超过260个字符的文件路径名。
重要提示：为使其正常工作，您需要直接在7zip “提取”对话框中指定目标路径，而不是将文件拖放到目标文件夹中。 否则，“Temp”文件夹将被用作临时缓存，一旦Windows资源管理器开始将文件移动到“最终安放地点”，您将弹出相同的260个字符限制。 请参阅对这个问题的答复以获取更多信息。

在Win32API中工作路径是用GetCurrentDirectory()获得;

而模块路径是由GetModuleFileName()获得

下面通过一段简单的代码来解释一下工作路径与模块路径的区别



运行结果：



当前模块路径是不变的，文件放在哪，他就是啥

但是工作路径的话就不同了，工作路径是父进程通过CreateProcess这个API传给他的，通过参数 __in_opt LPCTSTR lpCurrentDirectory将工作路径传给子进程。

如下例:

 



运行结果：