Torsten Schassan wrote:
> Ad hoc I can't explain what exactly makes XP interpret the "%20" as
> string instead of a character representation but I remember that plus
> signs in the places of spaces should work well enough.
Aha, in an off-list reply to Daniel I mistakenly assumed this was an issue
about command-line apps locating a user-defined My Documents ("Shell")
folder that wasn't in the default position (a source of many XP problems
where people have customised their desktops). I see now that the reference
to My Documents in the original posting was a red-herring, to the extent
that any folder with a space in its name would show the same behaviour.
If the problem, stated more generally, is that where there are spaces in the
path to an input file then Saxon interprets then correctly when opening the
file, but when asked to write to a file with spaces in its pathname it
attempts instead to write to a path where each space character has been
escaped to the literal character sequence '%20', then this indeed looks like
an application bug (though my installation of Saxon doesn't show it).
The filesystem component of XP itself doesn't and shouldn't know anything
about escaping spaces in URIs: that is for applications to handle. So when
Saxon asks via the Java stream output to open a file in the filesystem, it
is its reponsibility to undo any uri-escaping that may have been performed
on characters in the path. If this behaviour can be consistently reproduced
under the current release of Saxon, then this should be reported to Michael
Kay. If it really is a Saxon bug he will fix it pronto.