另一台计算机/服务器上的文件的文档（）函数

我明白如下使用document（）。另一台计算机/服务器上的文件的文档（）函数

<xsl:value-of select="document('path\to\docuemnt.xml')/RootElement/Element"/>

而这必须是父XSL文件的相对路径。但是如果我需要引用本地网络中另一台服务器上托管的文件呢？我尝试过这样的事情。

<xsl:value-of select="document('\\servername\path\to\document.xml')/RootElement/Element"/>

但是，这将引发一个错误，因为它看起来在

C:\path\to\xsl\\servername\path\to\document.xml

这当然不存在。

来源

2012-09-10 Horba

答案将取决于您的XSLT处理器，操作系统和文件系统。作为一个经验法则，你可以安全地使用file :: protocol。无论您的XSLT处理器是否支持目录，也可能会影响结果。请告诉我们您的上下文（XSLT处理器等） –

例如，在Saxon处理器上，您可以使用标准file :: protocol引用任何文件，但只能使用短文件名形式。如果您使用长文件名，Saxon将无法找到该文件。 –

作为文件协议的替代方法，如果文件通过http可用，则可以指定它的http协议格式URI。 –

此解决方案仅涉及撒克逊-HE 9.4.0.3N XSLT处理器，在控制台应用程序的形式，在Windows 7

以我的实验中，我发现，该文件（）函数将接受的文件名或URI。不过，我会避免文件名，因为它们需要是短格式的。如果使用长格式，文件名将被拒绝。

假设你的文档是...

c:\path\to\document.xml

在其上映射到驱动器 'J' 服务器ServerName。

要从此用作文件（）的参数值形成URI ...

file:///j:/path/to/document.xml

在相对于URI，我弄错约撒克逊不接受长格式。这仅适用于文件名。但是，有一些陷阱...

请注意正斜杠。反斜杠不起作用。
我还没有找到一种方法来构建一个可操作的文件：只有UNC名称的URI。您需要将驱动器映射到一个字母。
因任何原因未能打开文档将被报告为相同的错误。对于文件系统，有太多可能出错的事情，如果你无法打开文件，那么假定URI是错误的是不安全的。可能有许多世俗的原因，为什么文件无法在特定时间打开。
小心防火墙问题。这些发挥了作用。
许多文本编辑器（如NotePad ++）在缺少BOM并且未使用两种UTF-16编码之一进行编码时假定文本文件在系统代码页中进行了编码。 Saxon会默认假设文件是以UTF-8编码的，所以如果您在NotePad ++（ä）中使用我的代码页时有这样的字符，Saxon会吐出虚拟文件，并报告它无法打开文件。（另外：我不确定我的代码页是什么，我的o/s是Win7，当前系统区域设置是英语（澳大利亚），它是确定系统代码页的本地系统）。 Saxon不打开文档的原因是某些代码页中的（ä）编码产生的字节序列不是有效的UTF-8序列。
底层操作系统不支持不是URL路径的URI路径。撒克逊可能会如实地说它支持与文档（）函数相关的URI，但这并不会煮沸任何卷心菜，因为在实践中，您不能使用它们。 - 至少不是在Windows系列的o/s上。
请忽略文件协议上的MSDN page。撒克逊文档（）函数不接受该页面上建议的URL形式（包括|字符等）。使用我上面建议的形式。我已经测试过它，它工作。

来源

2012-09-10 13:31:41

这也适用于我。谢谢！ – Horba

煮白菜？这是澳大利亚人吗？ :-) – LarsH

这里给出了一个关于Windows文件名映射到URI的好文章：http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows。 ASPX。但是，映射不是标准化的，你不能假定Java会像.NET那样执行。 –

您对document（）的理解不正确。它期望一个URI，而不是文件名。

来源

2012-09-10 10:57:34

谢谢， Works。假设我必须安排文件在http：//可访问的位置可用。 – Horba

它不一定是一个HTTP URI，一个文件：URI对于我所知道的所有处理器都可以正常工作。（接受的实际协议集是实现定义的，例如一些处理器可能接受ftp，其他处理器则不接受） –

另一台计算机/服务器上的文件的文档（）函数

回答

相关问题