上下文:这是 INTRANET 系统的一部分,需要基本身份验证并在只能在我们的工作域内访问的内部服务器上运行。
因此,情况是 IE9 将通过映射驱动器跟踪网络文件和文件夹的链接,没有任何问题。我已经得到了这个工作正常,一种仅适用于 IE 的安全漏洞,非常适合我们的情况和许多其他情况:)
例如:
<a href="file:///U:/foo/bar.txt" target=\"_new\">Example</a>
工作正常。
现在,问题是 <a href="file:///C:/foo/bar.txt" target=\"_new\">Example</a>
不起作用。
但是如果我复制并粘贴 file:///C:/foo/bar.txt
进入地址栏,它加载正常。本地文件夹也是如此。
另一点需要注意的是我尝试过 <a href="#" onclick="window.open('file:///C:/foo/bar.txt');">Example</a>
并经历了完全相同的结果。指向网络映射驱动器上的文件和文件夹的 URL 工作正常,C:\文件夹和文件不起作用(除非粘贴到地址栏中)。
所以我的问题是:
1.考虑到我有一个有效的URL,为什么IE9在点击时不跟随它,但在输入地址栏时会跟随它?
2.为什么 IE 可以毫无顾虑地启动网络文件和文件夹,但不能启动本地文件和文件夹?
3.我怎样才能让它发挥作用? (而且我会毫不犹豫地使用任何必要的肮脏的 IE hack)
回答其中任何一个问题都很好,但金星奖颁给能够回答第 3 个问题的人!
我怀疑/希望这只是我的谷歌搜索无法发现的一个模糊的安全设置。
感谢您抽出宝贵的时间,希望这对以前经历过并解决过此问题的人来说是一个警钟:)
编辑:我刚刚注意到 IE9 正在重新解释我的链接!如果我查看源代码并看到:<a href="C:/foo/bar.txt" target="_new">Example</a>
或<a href="file://C:/foo/bar.txt" target="_new">Example</a>
,当我将鼠标悬停在链接上或复制快捷方式时,我得到 file:///C:/foo/bar.txt
。所以我认为我正在与试图形成“正确”URL 进行一场艰苦的战斗。我确信这不是代码语法错误,而是某个地方的设置,可以启用这些 C: 链接。
最佳答案
我无法重现您的问题。我可以使用以下两种方法在 Chrome 和 IE 中打开页面:
<a href="file:///C:/temp/test.py">Example</a>
和:
<a href="file://C:/temp/test.py">Example</a>
关于javascript - URL 在 IE9 地址栏中粘贴/输入时有效,但在 href 或 window.open 中无效,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7654682/