Pregunta

I know that the proper way to handle file/directory paths is to use Path.AltDirectorySeparatorChar, but does this apply to html source paths?

Or, is it that the backslash is the required path separator for html? I've always done it using the backslash (i.e. <img src="images\birthdaysurprise.jpg" />), but now I'm wondering if I've been doing it improperly this entire time?

¿Fue útil?

Solución

The "letter of the law" is that forward slash ('/') is the way to do it. Per RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, §3, "URI Syntactic Components":

The URI syntax does not require that the scheme-specific-part have
any general structure or set of semantics which is common among all
URI.  However, a subset of URI do share a common syntax for
representing hierarchical relationships within the namespace.  This
"generic URI" syntax consists of a sequence of four main components:

   <scheme>://<authority><path>?<query>

each of which, except <scheme>, may be absent from a particular URI.
For example, some URI schemes do not allow an <authority> component,
and others do not use a <query> component.

   absoluteURI   = scheme ":" ( hier_part | opaque_part )

URI that are hierarchical in nature use the slash "/" character for
separating hierarchical components.  For some file systems, a "/"
character (used to denote the hierarchical structure of a URI) is the
delimiter used to construct a file name hierarchy, and thus the URI
path will look similar to a file pathname.  This does NOT imply that
the resource is a file or that the URI maps to an actual filesystem
pathname.

   hier_part     = ( net_path | abs_path ) [ "?" query ]

   net_path      = "//" authority [ abs_path ]

   abs_path      = "/"  path_segments

URI that do not make use of the slash "/" character for separating
hierarchical components are considered opaque by the generic URI
parser.

   opaque_part   = uric_no_slash *uric

   uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                   "&" | "=" | "+" | "$" | ","

We use the term <path> to refer to both the <abs_path> and
<opaque_part> constructs, since they are mutually exclusive for any
given URI and can be parsed as a single component.

Your URI needs a minimal number of forward slashes to separate the scheme from the authority. The remainder of the URI (the path and query components) really have meaning only within the context of the pertinent scheme and authority. However, a couple of things to consider:

  • One, URI paths are not filesystem paths (unless the URI scheme is file (file://...). URI paths are simply identifiers with meaning to authority that may (or may not) map to particular filesystem entries.

  • Two, opaque URI paths (ones not using '/' as the path separator, can't be processed very well by generic tools. Further, it's not necessarily apparent that the path in question is opaque: meaning application of generic tools to your opaque URI may result in unexpected behaviors.

Otros consejos

While I don't know the exact letter of the law, use the forward slash for all path separators. Even Windows can use a forward slash as a separator in its APIs.

Using a backslash may work under a windows platform but:

  • It looks weird
  • Will die and gag if you move to a *nix based system.
  • May end up breaking some code that assume the forward slash
  • \ starts an escape sequence in many instances, so \n could translate in an unexpected way.
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top