Есть ли правильный способ создать путь HTML src?


Я знаю, что правильный способ обработки путей к файлам / каталогам-использовать Path.AltDirectorySeparatorChar, но применимо ли это к исходным путям html?

Или обратная косая черта является необходимым разделителем пути для html? Я всегда делал это, используя обратную косую черту (т. е. <img src="imagesbirthdaysurprise.jpg" />), но теперь мне интересно, не делал ли я это неправильно все это время?

2 3

2 ответа:

"Буква закона" состоит в том, что прямой Слэш ( ' / ' ) - это способ сделать это. Per RFC 2396, Uniform Resource Identifiers (URI): универсальный синтаксис, §3, "синтаксические компоненты URI":

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.

Ваш URI нуждается в минимальном количестве прямых косых линий, чтобы отделить схему от органа . Остальные компоненты URI (путь и запрос ) действительно имеют значение только в контексте соответствующей схемы и авторитет . Тем не менее, несколько вещей, чтобы рассмотреть:

  • Один, URI пути являются не пути файловой системы (если схема URI не является file (file://...). Пути URI-это просто идентификаторы со значением авторитета , которые могут (или не могут) сопоставляться с определенными записями файловой системы.

  • Два, непрозрачные пути URI (те, которые не используют '/' в качестве разделителя путей, не могут быть обработаны очень хорошо универсальными инструментами. Кроме того, это не обязательно очевидно, что путь, о котором идет речь, непрозрачен: это означает, что применение универсальных инструментов к вашему непрозрачному URI может привести к неожиданному поведению.

Хотя я не знаю точной буквы закона, используйте прямую косую черту для всех разделителей путей. Даже Windows может использовать прямую косую черту в качестве разделителя в своих API.

Использование обратной косой черты может работать под платформой windows, но:

  • это выглядит странно
  • умрет и заткнется, если вы перейдете в систему, основанную на * nix.
  • может закончиться взломом некоторого кода, который предполагает прямую косую черту
  • \ во многих случаях запускает escape-последовательность, поэтому \n может быть переведен в неожиданный способ.