Как получить адрес файла
Члены большинства типов в пространстве имен System.IO имеют параметр path , который позволяет указать абсолютный или относительный путь к ресурсу в файловой системе. Этот путь передается в API файловой системы Windows. В этом разделе рассматриваются форматы путей к файлам, которые можно использовать в операционных системах Windows.
Традиционные пути DOS
Стандартный путь DOS может состоять из трех компонентов:
- Буква тома или диска, после которой следует разделитель томов ( : ).
- Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
- Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.
Если присутствуют все три компонента, путь является абсолютным. Если буква тома или диска не указана и имя каталога начинается с символа разделителя каталогов, такой путь задан относительно корня текущего диска. В противном случае путь задан относительно текущего каталога. В следующей таблице показаны некоторые возможные пути к каталогам и файлам.
| Путь | Описание: |
|---|---|
| C:\Documents\Newsletters\Summer2018.pdf | Абсолютный путь к файлу из корня диска C: . |
| \Program Files\Custom Utilities\StringFinder.exe | Абсолютный путь из корня текущего диска. |
| 2018\January.xlsx | Относительный путь к файлу в подкаталоге текущего каталога. |
| ..\Publications\TravelBrochure.pdf | Относительный путь к файлу в каталоге, который является одноранговым для текущего каталога. |
| C:\Projects\apilibrary\apilibrary.sln | Абсолютный путь к файлу из корня диска C: . |
| C:Projects\apilibrary\apilibrary.sln | Относительный путь из текущего каталога диска C: . |
Обратите внимание на различия между двумя последними путями. В обоих случаях задается необязательный описатель тома ( C: ), однако первый путь, в отличие от второго, начинается с корня указанного тома. В результате первый путь является абсолютным из корневого каталога диска C: , тогда как второй — относительным из текущего каталога C: . Использование второй формы пути в тех случаях, когда предполагается наличие первой, является распространенным источником ошибок, связанных с путями к файлам в Windows.
Чтобы определить, является ли путь к файлу полным (такой путь не зависит от текущего каталога и не изменяется при смене текущего каталога), можно вызвать метод Path.IsPathFullyQualified. Обратите внимание, что такой путь может включать сегменты с относительным путем к каталогу ( . и .. ), но при этом по-прежнему будет полным, если разрешенный путь всегда указывает на одно и то же место.
В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера.
Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.
UNC-пути
UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:
- Имя сервера или узла, которому предшествуют символы \\ . В качестве имени сервера может выступать имя компьютера NetBIOS, а также IP-адрес или полное доменное имя (поддерживаются адреса IPv4 и IPv6).
- Имя общего ресурса, которое отделяется от имени узла символами \ . Имя сервера и имя общего ресурса в совокупности образуют том.
- Имя каталога. Символ разделителя каталогов служит для разделения подкаталогов во внутренней иерархии каталога.
- Необязательное имя файла. Символ разделителя каталогов служит для разделения пути к файлу и его имени.
Ниже приводятся некоторые примеры UNC-путей:
| Path | Описание |
|---|---|
| \\system07\C$\ | Корневой каталог диска C: на компьютере system07 . |
| \\Server2\Share\Test\Foo.txt | Файл Foo.txt в тестовом каталоге тома \\Server2\Share . |
UNC-пути всегда должны быть полными. Они могут включать сегменты с относительным путем к каталогу ( . и .. ), однако они должны быть частью полного пути. Использовать относительные пути можно только посредством сопоставления UNC-пути с буквой диска.
Пути к устройствам DOS
В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:
Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:
Путь к устройству DOS состоит из следующих компонентов:
Описатель пути к устройству ( \\.\ или \\?\ ), который идентифицирует путь как путь к устройству DOS.
Символьная ссылка на "реальный" объект устройства (C: в случае имени диска или Volume в случае GUID тома).
Первый сегмент пути к устройству DOS после описателя пути к устройству идентифицирует том или диск. (Например, \\?\C:\ и \\.\BootPartition\ .)
Для UNC-путей существует специальная ссылка, которая называется UNC . Пример:
Для UNC-путей к устройствам часть сервера или общего сетевого ресурса образует том. Например, в пути \\?\server1\e:\utilities\\filecomparer\ часть server1\utilities представляет сервер или общий сетевой ресурс. Это важно при вызове такого метода, как Path.GetFullPath(String, String) с сегментами с относительным путем к каталогу, поскольку переход дальше тома невозможен.
Пути к устройствами DOS по определению являются полными. Сегменты с относительным путем к каталогу ( . и .. ) в них не допускаются. Они никогда не задаются относительно текущего каталога.
Пример. Способы задать ссылку на один и тот же файл
В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.
Нормализация путей
Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:
- Идентифицируется путь.
- Текущий каталог применяется к неполным (относительным) путям.
- Выполняется канонизация разделителей каталогов.
- Вычисляются относительные компоненты каталога ( . для текущего и .. для родительского каталога).
- Удаляются некоторые символы.
Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.
Идентификация пути
На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:
- Пути к устройствам: начинаются с двух разделителей и знака вопроса или точки ( \\? или \\. ).
- UNC-пути: начинаются с двух разделителей без знака вопроса или точки.
- Полные пути DOS: начинаются с буквы диска, разделителя томов и компонентов ( C:\ ).
- Пути к устаревшим устройствам ( CON , LPT1 ).
- Пути относительно корня текущего диска: начинаются с одного разделителя компонентов ( \ ).
- Пути относительно текущего каталога указанного диска: начинаются с буквы диска и разделителя томов, но не содержат разделителя компонентов ( C: ).
- Пути относительно текущего каталога: начинаются с любых других символов ( temp\testfile.txt ).
Тип пути определяет, будет ли каким-либо образом применяться текущий каталог. Кроме того, от типа пути зависит применяемый корень.
Работа с устаревшими устройствами
Если путь указывает на устаревшее устройство DOS, например CON , COM1 или LPT1 , он преобразуется в путь к устройству путем добавления перед ним последовательности \\.\ и возвращается в таком виде.
Путь, который начинается с имени устаревшего устройства, всегда интерпретируется как путь к устаревшему устройству с помощью метода Path.GetFullPath(String). Например, путь к устройству DOS CON.TXT будет выглядеть как \\.\CON , а путь к устройству DOS COM1.TXT\file1.txt будет выглядеть как \\.\COM1 .
Применение текущего каталога
Если путь не является полным, система Windows применяет к нему текущий каталог. К UNC-путям и путям к устройствам текущий каталог не применяется. Также текущий каталог не применяется к полным путям к диску с разделителем C:\ .
Если путь начинается с одного разделителя компонентов, применяется диск текущего каталога. Например, для пути к файлу \utilities и текущего каталога C:\temp\ в результате нормализации будет получен путь C:\utilities .
Если путь начинается с буквы диска, разделителя томов и не содержит разделителя компонентов, применяется последний текущий каталог, установленный из командной оболочки. Если последний текущий каталог не был установлен, применяется диск сам по себе. Например, для пути D:sources , текущего каталога C:\Documents\ и последнего текущего каталога D:\sources\ на диске D: в результате будет получен путь D:\sources\sources . Пути, задаваемые относительно диска, являются распространенными источниками ошибок программ и логики скрипта. Предположение, что путь, начинающийся с буквы и двоеточия, не является относительным, очевидно неверно.
Если путь не начинается с разделителя, применяются текущий диск и текущий каталог. Например, для пути к файлу filecompare и текущего каталога C:\utilities\ в результате будет получен путь C:\utilities\filecompare\ .
Канонизация разделителей
Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( \ ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.
Вычисление относительных компонентов
При обработке пути выполняется вычисление любых его компонентов или сегментов, которые состоят из одной или двух точек ( . или .. ):
Если обнаруживается одна точка, текущий сегмент удаляется, поскольку он ссылается на текущий каталог.
Если обнаруживаются две точки, удаляются текущий и родительский сегмент, поскольку в этом случае задается ссылка на родительский каталог.
Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C:\ ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \\Server\Share ) и префикс пути к устройству для путей к устройствам ( \\?\ или \\.\ ).
Удаление знаков
Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:
Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент, состоящий из одной или двух точек, нормализуется на предыдущем шаге. Сегмент, состоящий из трех или более точек, не нормализуется и фактически представляет собой допустимое имя файла или каталога.)
Если путь не заканчивается разделителем, удаляются все конечные точки и пробелы (U+0020). Если последний сегмент содержит только одну или две точки, к нему применяется приведенное выше правило для относительных компонентов.
Это правило устанавливает, что вы можете создать имя каталога с конечным пробелом, добавив разделитель после пробела.
Создавать имена каталогов или файлов с конечным пробелом нельзя. Наличие конечных пробелов может затруднить или исключить возможность доступа к каталогу. В связи с этим при попытке обработать каталоги или файлы, имена которых содержат конечные пробелы, происходит сбой приложения.
Пропуск нормализации
Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.
Зачем нужно пропускать нормализацию? Существует три основных причины:
Получение путей, которые в обычных обстоятельствах недоступны, но являются допустимыми. Например, невозможно каким-либо иным способом получить доступ к файлу или каталогу с именем hidden. .
Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена.
Пропуск нормализации и проверки максимальной длины пути является единственным отличием между двумя видами синтаксиса путей к устройствам. В остальных аспектах они идентичны. Пропуск нормализации следует использовать с осторожностью, поскольку в этом случае легко получить пути, при работе с которыми в обычных приложениях будут возникать трудности.
Пути, начинающиеся с последовательности \\?\ , по-прежнему нормализуются, если явно передать их в функцию GetFullPathName.
Вы можете передавать пути длиной более MAX_PATH символов в функцию GetFullPathName без \\?\ . Она поддерживает пути произвольной длины, которая ограничивается лишь максимальным размером строки, поддерживаемым в Windows.
Регистр символов и файловая система Windows
Особенность файловой системы Windows заключается в том, что пользователи и разработчики, имеющие дело с другими операционными системами, могут сталкиваться с проблемами из-за того, что в именах каталогов и путях не учитывается регистр символов. Это значит, что в именах каталогов и файлов сохраняется регистр строк, используемый в момент их создания. Например, вызов метода
В Интернете доступны миллионы статей по устранению неполадок, которые помогут решить проблемы с вашим компьютером. В большинстве случаев при чтении этих статей вам будет предложено открыть определенный файл, папку или приложение для устранения проблемы. Как правило, легко найти местоположение исходного файла в Windows и Mac. Однако это не всегда так, особенно для ярлыков приложений и системных приложений. Если вы не можете найти местоположение файла, вот как это можно сделать в Windows и Mac.
Поиск местоположения исходного файла
Процесс очень прост как в Windows, так и в Mac. Однако это зависит от типа файла, в котором вы хотите найти исходное местоположение.
Получить расположение файла в Windows 10
Мы объясним все возможные сценарии на компьютере с Windows 10.
1. Поиск местоположения с помощью свойств файла
Многие пользователи хранят ярлыки приложений на своем рабочем столе. Кроме того, системные приложения, такие как браузер Edge, будут иметь ярлык по умолчанию на рабочем столе. Давайте займемся поиском местоположения приложения Chrome, для которого вы создали ярлыки на рабочем столе.
- Сначала щелкните правой кнопкой мыши ярлык приложения Chrome на рабочем столе и выберите «Свойства». Кроме того, вы можете выбрать значок и нажать сочетания клавиш «Alt + Enter».
- Откроется окно свойств файла ярлыка.
- Сведения о расположении в разделе «Общие» покажут вам расположение файла ярлыка. Это бесполезно, поскольку вы уже знаете, что файл ярлыка находится на вашем рабочем столе.
- Щелкните вкладку «Ярлык» и установите флажок «Цель». Здесь вы можете найти расположение исходного файла ярлыка.
- Щелкните «Открыть расположение файла», чтобы открыть файл в проводнике. Кроме того, вы можете скопировать целевой путь и сохранить его для дальнейшего использования.
Это полезно, особенно если вы установили приложения на дисках, отличных от C :.
Статьи по Теме:
2. Поиск местоположения с помощью поиска в Windows 10
- Введите «край» в поле поиска Windows и щелкните маленькую стрелку вниз, показанную в правой части.
- Это покажет некоторые дополнительные параметры и нажмите «Открыть расположение файла».
- Теперь вы увидите приложение Edge в проводнике. Однако это будет ярлык Edge, а не исходный файл приложения.
- Щелкните правой кнопкой мыши ярлык Edge и откройте окно свойств файла. Как объяснено в приведенном выше методе, вы можете найти местоположение исходного файла в разделе «Ярлык» в поле «Цель».
Однако поле поиска работает по-разному для разных типов файлов. При поиске изображений Windows покажет параметры «Открыть расположение файла» и «Копировать полный путь».
Расположение файлов изображений
Кроме того, вы можете увидеть список «Лучшие приложения», щелкнув поле поиска. Отсюда вы также можете щелкнуть правой кнопкой мыши и открыть расположение файла.
3. Получить расположение файла в проводнике.
Приложение File Explorer покажет полный путь к файлу, который вы просматриваете в данный момент. В случае, если вы хотите скопировать местоположение в проводнике, просто щелкните адресную строку. Это покажет полный путь к файлу и нажмите «Control + C», чтобы скопировать местоположение в буфер обмена.
Получить расположение файла на Mac
Подобно Windows, Mac также предлагает различные методы поиска местоположения файла.
1. Определите местоположение с помощью Get Info
Щелкните файл, местоположение которого нужно найти, и нажмите сочетания клавиш «Command + I». Либо щелкните файл правой кнопкой мыши и выберите параметр «Получить информацию».
Откроется диалоговое окно свойств файла. Проверьте путь к файлу «Исходный» в разделе «Общие».
Исходное местоположение
2. Найдите расположение приложений в Dock.
Если вы хотите найти расположение файла приложения, доступного на вашей док-станции, щелкните его правой кнопкой мыши. Перейдите в «Параметры»> «Показать в Finder», чтобы открыть местоположение файла в Finder.
Найти местоположение из Finder
3. Откройте расположение файла в поиске Spotlight.
Путь к файлу в поиске Spotlight
В этой инструкции я покажу, как скопировать полный путь к файлу в Windows 10. Иногда нам для поиска информации или работы других программ, необходимо скопировать путь расположения файла, папки или каталога. Чтобы найти определенный файл в иерархии каталогов, необходимо указать абсолютный путь к нему.
Как посмотреть путь к файлу?
С помощью Shift
Например, путь к рабочему столу Windows 10 на моем компьютере имеет вид ⇒ C:\Users\Alex\Desktop, а к папке Temp ⇒ C:\Program Files (x86)\Temp
Через свойства папки или файла
Следующим способом удобно смотреть расположение папки или документа, но скопировать весь путь не получиться, так как последняя директория в пути не указывается.
Например путь к графическому изображению help.jpg
вместо ⇒E:\Фотоматериалы и изображения\Иконки\help.jpg
будет выглядеть как ⇒
E:\Фотоматериалы и изображения\Иконки
Узнаем путь к файлу в командной строке Windows
- Открываем командную строку. Сделать это можно, нажав комбинацию клавиш Win+R и в открывшейся строке ввести cmd.
- Перетаскиваем иконку файла или папки в основное окно программы cmd.exe.
- Полный путь до файла будет скопирован в окно командной строки. Если это будет файл запуска, например exe, то при нажатии кнопки Ввод (Enter) запуститься программа.
Для примера создадим документ Word с именем Doc3 и поместим его в любую папку и посмотрим его путь в командной строке.
Как скопировать путь к файлу на Mac
Пути к файлам и папкам на Маке можно узнать так же, как и в Виндовс через Shift, только названия кнопок другие ⇒
В буфер обмена скопируется полный путь к файлу например ⇒
Скопировать полный путь до любого файла достаточно просто и с этим справится любой пользователь ПК или ноутбука.
Абсолютный и относительный пути
Путь (от англ. path) — набор символов, показывающий расположение файла или каталога в файловой системе.
Например, в следующей записи G:\EPIM Pro\Необходимые программы\ABBYY FineReader 10.0.102.95 Pro\readme.txt
readme.txt — это имя файла, а G:\EPIM Pro\Необходимые программы\ABBYY FineReader 10.0.102.95 Pro — путь к нему.
Полный (абсолютный) путь к файлу начинается с логического имени диска. Далее идут имена вложенных друг в друга папок (их может быть сколько угодно много). В последней папке содержится требуемый файл.
Стандартный путь состоит из трех компонентов ⇒
Если присутствуют все три компонента, путь является абсолютным. Полный путь всегда начинается с корневого каталога.
Если буква тома или диска не указана и имя каталога начинается с символа разделителя, то такой путь задан относительно корня текущего диска. В противном случае путь задан относительно текущего каталога.
В следующей таблице показаны некоторые возможные пути к каталогам и файлам ⇒
И именно URL является тем базовым параметром атрибута href, с помощью которого создаются гиперссылки, входящие в состав гипертекста как основы Мировой Паутины. Благодаря урлу все пользователи получают возможность посетить нужный сайт и получить искомую информацию.
Кроме этого, разберем на наглядных примерах, из чего состоят урлы, какого вида они бывают и как находить адреса изображений, страниц сайта, видео и копировать их для своих нужд.
Что такое URL адрес и из чего он состоит?
URI является более общей системой идентификации. Она может включать в себя либо URN, либо URL, либо оба идентификатора вместе. То есть, URN и URL являются частными случаями URI. Попробую объяснить, что значит каждый термин, на наглядном примере из реальной жизни.
Допустим, имеется конкретный адрес (г. Нижний, ул. Верхняя, д.4, кв.15), до которого возможно добраться различными способами в зависимости от степени удаления пункта отправления. Имя владельца квартиры Василий Васильевич Пупкин.
Скажем, сосед Пупкина доберется к нему пешком (это будет в данном случае методом доступа к объекту). А родственнику, живущему за несколько тысяч километров, придется задействовать комплексный вариант (прилететь на самолете, приехать по нужному адресу на такси и дойти оставшееся расстояние пешком). Способ доступа в этом случае будет другим (самолет - такси - пешком). В контексте выше сказанного это и есть URL (адрес + метод доступа к объекту).
Нас интересует в первую очередь унифицированный указатель, поскольку именно он является основной идентификационной системой, используемой широко на практике в глобальной сети. Поэтому далее мы и уделим основное время описанию структурных особенностей URL.
Структура УРЛ и некоторые особенности для вебмастеров
Итак, мы с вами определили в общих чертах, что же такое URL адрес. Это путь до любого файла (вебстраницы сайта, картинки, видео и др.). Начнем с простого примера. Вот как может выглядеть локатор в общем виде для одного из файлов, находящегося в определенной директории (папке):
В качестве реального примера привожу урл адрес файла, который содержит логотип этого блога:
Тогда наблюдается присутствие в интернете двух разных ресурсов (с WWW и без) с одинаковым содержанием. С точки зрения поисковых систем это зеркала, являющиеся по своей сути дублями, которые жутко мешают продвижению проекта как в Яндексе, так и в Гугле.
К тому же, обратные ссылки, проставленные на ваш сайт с доноров, могут быть распределены в неизвестных пропорциях между зеркалами. Поэтому надо предпринять действия по определению главного домена и склейке зеркал, в том числе посредством 301-ого редиректа.
С доменным именем мы разобрались. Кстати, при создании сайта домен вашего веб-проекта будет считаться корневой папкой с точки зрения файловой структуры веб-сервера. Вследствие этого цепочку после двойного слеша можно воспринимать как последовательность вложенных друг в друга папок (их может быть несколько), где на конце урла находится нужный файл:
Для полноты картины нужно еще упомянуть об адресах страниц сайтов в интернете. Чаще всего встречаются урлы трех видов (ЧПУ), которые наиболее предпочтительны во всех смыслах:
Вроде бы, первый вариант больше всего отвечает разобранной нами схеме. Но в случае с URL страницы не все так однозначно. В теории это состоит следующим образом (попробую объяснить все на примере обычного блога, по-моему, он достаточно наглядный и понятный большинству).
При стандартных серверных настройках каждый URL, соответствующий каталогу (папке), должен заканчиваться слэшем, в этом случае обработчик "поймет", что необходимо отобразить листинг всех файлов, которые там содержатся, а не какой-то конкретный объект, поиск которого будет осуществляться, если слеша не будет (таким образом вы экономите ресурсы сервера).
В соответствии с этими рассуждениями локатор главной должен заканчиваться на «/», поскольку домен является корневой директорией:
По этой же причине такой же вид урла соответствует рубрикам сайта:
А вот статические или страницы записей выводятся в таком обличье:
Помните, чуть выше я упоминал о двух легитимных вариантах существования файлов в Unix-подобных операционных системах (с расширением и без)?
Однако, подобные рассуждения не совсем корректны в том числе и потому, что подавляющее большинство современных вебсайтов работает под управлением самых различных CMS, или, по-простому, движков, которые генерируют странички динамически "на лету" на базе имеющихся шаблонов с расширением .php, включающих комплекс соответствующих функций.
Если взять в качестве образца самый популярный в мире движок WordPress, то там все шаблоны, отвечающие за формирование различных страничек сайта (главной, рубрик, вебстраниц записей и т.д.) входят физически в одну директорию текущей темы.
Таким образом, содержание названных страниц в конечном виде существует лишь при просмотре в веб-браузере, а не физически на сервере. К слову, с файловым строением тем WP вы можете познакомиться перейдя по ссылке, этот материал даст вам дополнительные полезные сведения.
Кто привык копать глубоко и желает более подробно изучить этот архиважный аспект, отсылаю вас к очень качественному материалу, где он освещается на основе первоисточника в формате спецификации общего синтаксиса URL, и в котором красной нитью проходит утверждение, что урл вообще (вне зависимости от своего содержания) указывает на абстрактное местоположение ресурса, а не на его конкретное физическое расположение.
Резюмируя и суммируя все приведенные доводы, могу утверждать, что с точки зрения синтаксиса все образцы рассмотренных урлов для веб-страниц сайта (со слешем на конце, без него и с расширением .html) вполне корректны и пригодны для использования.
Более того, ни один из них не имеет сколь-нибудь заметного преимущества в глазах поисковых систем. Единственное, для обеспечения правильной индексации надо также установить 301 редирект в случае применения URL со слешем или без в конце.
Надеюсь, что предоставленная информация поможет вам определиться с настройкой урлов на своем сайте. Для проектов, работающих на WordPress, например, постоянные ссылки сайта можно легко настроить в соответствующем разделе админ-панели.
Важное замечание! Настройку ссылок желательно производить в начале создания проекта, дальнейшие изменения могут замедлить или приостановить продвижение сайта, поскольку переиндексация у поисковиков не происходит мгновенно.
Выше мы рассмотрели частные случаи различных типов локаторов, ну а общая блок-схема, демонстрирующая структуру URL, выглядит следующим образом:
Пожалуй, следует дать некоторые разъяснения по отдельным составляющим.
Для полноты информации вы можете ознакомиться с полным перечнем используемых схем на соответствующей страничке Википедии.
В таком случае для доступа к нужному файлу или папке понадобиться указать логин и пароль, а также порт (если он отличен от стандартного, применяемого по умолчанию):
А это и есть самые настоящие дубли, большое количество которых способно существенно снизить скорость индексирования страничек, а значит, и косвенным образом замедлить продвижение веб- ресурса. Поэтому, думаю, будет уместным в этом месте дать гиперссылку, перейдя по которой вы узнаете, как бороться с самым разнообразным дублированным контентом на Вордпресс.
К выше сказанному надо бы еще добавить, что в стандартных урлах рекомендуется использовать лимитированную выборку знаков: буквы латинского алфавита в нижнем регистре [a-z], цифры 9, точку [.], нижнее подчеркивание [_], и дефис [-].
Такие ограничения действуют со времени зарождения интернета, но с некоторых пор ввиду развития глобальной сети появилась необходимость формировать URL с применением символов национальных языков, включая русский. Такая возможность появилась, но для ее реализации требуется кодировка (encoding) любых знаков в формате ASCII, который понимают браузеры.
Кодирование и декодирование URL
Итак, после некоторых предпринятых соответствующими международными организациями усилий сайт может использовать для адресов своих страниц локаторы, включающие буквы практически любого языка. Нас интересует русский, поэтому можете проверить сие утверждение, введя в адресную строку браузера урл одной из страниц Русской Википедии:
Адрес корректно отобразится:
Это и есть закодированные русские буквы, которые web-браузер автоматически преобразует в читабельный текст на кириллице. Кстати, в сети есть немало сервисов, которые предлагают быстрое кодирование и декодирование содержания URL, например, вот этот:
Конечно, для пользователей рунета гораздо более привлекательным является текст на русском, содержащийся в локаторе (кстати, и доменное имя может быть кириллическим).
Однако, формировать урлы на кириллице для страниц своего сайта я все-таки советую только в том случае, если проект имеет какие-то свои особенности, вследствие которых именно русские символы в URL будут эффективнее привлекать посетителей, особенно целевую аудиторию.
В других случаях все же оптимальнее будет применять латиницу (а для WordPress использовать плагины транслитерации для автоматического преобразования русских букв в постоянных ссылках в латинские), поскольку это исключает некоторые возможные ошибки, а поисковые системы не делают языковых предпочтений в этом аспекте при ранжировании.
Как узнать URL изображения, видео или страницы сайта?
При работе в интернете да и просто во время сёрфинга или поиска информации в сети очень часто нужно просмотреть или скопировать адрес того или иного объекта. Где же взять нужный урл на открытой в браузере веб-страничке? Что касается URL страницы сайта, то его можно подсмотреть в адресной строке:
С помощью того же контекстного меню можно найти и скопировать также URL нужной вам гиперссылки, содержащейся в тексте:
Иногда нужно узнать урл размещенной в web-пространстве картинки. Для этого опять используйте тот же метод:
В случае присутствия видео в контенте веб-странички его URL- адрес можно получить с похожей легкостью (достаточно щелкнуть правой кнопкой мыши прямо по плейеру):
Таким вот образом вы легко можете получать и копировать URL-адрес практически любого объекта. Кстати, контекстное меню может принимать различный вид в зависимости от применяемого веб-браузера, но суть его опций остается практически идентичной.
Читайте также: