Related, but not directly addressing the issue, here is a little more info that might help in this matter and in understanding other URI/URL issues.
Looking at this very late in the game (yeah, I have read all the replies), the defacto standard for how URIs and URLs should work on any platform were originally stated in the RFC 3986 document from Jan 2005 called RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
located here:
Page 16 has a good breakdown of how a URI is broken down under section 3. Syntax Components.
Regarding localhost in a URI, this is touched on in 3.2.2 Host (pg. 20-21) and 6.2.3. Scheme-Based Normalization
Section 3.3 goes into more detail regarding paths for those interested.
To save you the trouble:
Section 3
3. Syntax Components
The generic URI syntax consists of a hierarchical sequence of
components referred to as the scheme, authority, path, query, and
fragment.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
The scheme and path components are required, though the path may be
empty (no characters). When authority is present, the path must
either be empty or begin with a slash ("/") character. When
authority is not present, the path cannot begin with two slash
characters ("//"). These restrictions result in five different ABNF
rules for a path (Section 3.3), only one of which will match any
given URI reference.
The following are two example URIs and their component parts:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
| _____________________|__
/ \ / \
urn:example:animal:ferret:nose
Section 3.2.2
If the URI scheme defines a default for host, then that default
applies when the host subcomponent is undefined or when the
registered name is empty (zero length). For example, the "file" URI
scheme is defined so that no authority, an empty host, and
"localhost" all mean the end-user's machine, whereas the "http"
scheme considers a missing authority or empty host invalid.
and Section 6.2.3
Another case where normalization varies by scheme is in the handling
of an empty authority component or empty host subcomponent. For many
scheme specifications, an empty authority or host is considered an
error; for others, it is considered equivalent to "localhost" or the
end-user's host.
Hope this helps anyone interested in better understanding how these beasties are laid out.
On Feb 25, 2014, at 8:21 AM, koenig.yvan wrote: Le 25/02/2014 à 12:32, Shane Stanley < email@hidden> a écrit : On 25 Feb 2014, at 10:12 am, Shane Stanley < email@hidden> wrote: use framework "Foundation" on pathFromTextURL:theURL set thePath to current application's NSString's stringWithString:theURL -- make an NSString set thePath to thePath's stringByReplacingPercentEscapesUsingEncoding:(current application's NSUTF8StringEncoding) -- replace encoded chars set theStart to location of (thePath's rangeOfString:"/") -- find / to reomve file: bit return (thePath's substringFromIndex:theStart) as text end pathFromTextURL:
I was asked off-list about how this would cope with URLs beginning with "file//localhost". The answer is, not very well. In my defence, URLs created under Mavericks no longer include localhost.
But I realised there's an easier method than the above, which shouldn't care about localhost or the extra slashes:
use framework "Foundation" on pathFromTextURL:theURL return (current application's NSURL's URLWithString:theURL)'s |path|() as text end pathFromTextURL:
|