Маршрутизация URL: обработка пробелов и недопустимых символов при создании дружественных URL

Question

Я видел много дискуссий о маршрутизации URL-адресов и МНОЖЕГО замечательных предложений ... но в реальном мире я не обсуждал одну вещь:

1. Создание дружественных URL с пробелами и недопустимыми символами
2. Запрос к БД

Допустим, вы создаете медицинский сайт, на котором есть Статьи с категорией и необязательной Подкатегория . (От 1 до многих). ( Мог бы использовать любой пример, но в области медицины много длинных слов )

---

Примеры категорий / подразделов / структура статьи:

1. Ваше общее состояние здоровья (категория)
   • Natural Health (подкатегория)
     1. Иммунная система вашего организма и почему она нуждается в помощи. (статья)
     2. Растения и травы действительно являются решением?
     3. Должен ли я есть обогащенные продукты?
   • Гомеопатическая медицина
     1. Что такое гомеопатическое лекарство?
   • Здоровое питание
     1. Стоит ли пить 10 чашек кофе в день?
     2. Стоят ли органические овощи?
     3. Является ли Burger King & reg; зло?
     4. Здоровее ли "французское кафе" или американский кофе?
2. Заболевания и условия (категория)
   • Аутоиммунные расстройства (Подкатегория)
     1. Убийца людей № 1 - это какая-то болезнь
     2. Как получить помощь
   • Генетические условия
     1. Профилактика расщелины позвоночника до беременности.
     2. Вы предрасположены жить долго?
3. Dr. Личные предложения FooBar (Категория)
   1. Мои мысли о фитотерапии и природных средствах (Статья - без подкатегории)
   2. Почему вы должны заботиться о своем здоровье?
   3. Можно правильно питаться и правильно питаться.
   4. Бескровная хирургия достигла совершеннолетия?

---

В такой структуре у вас будет несколько LOOONG URL , если вы перейдете: / {Категория} / {Подкатегория} / {Название статьи}

Кроме того, существует множество недопустимых символов , например, #! ? и т. д.

ТАК, ВОПРОС (С):

1. Как бы вы справились с недопустимыми символами и пробелами? (Плюсы и минусы?)
2. Не могли бы вы получить это из базы данных
   • Другими словами, вы бы доверили БД найти Предмет, передавая заголовок, или извлеките все заголовки и найдите ключ в коде, чтобы получить ключ для передачи в базу данных (два обращения к базе данных)?

примечание: я всегда вижу красивые симпатичные примеры, такие как / products / напитков / Short-Product-Name / как насчет обработки некрасивых примеров ^ _ ^

Answer 1

Я сам предпочитаю _ для - из-за читабельности (вы подчеркиваете это, а _ - практически go_away), если вы собираетесь убирать пробелы.

Возможно, вы захотите попробовать привести расширенные символы, например, ü, к эквивелантам close-ascii, где это возможно, например:

ü -> u

Однако, по моему опыту, самая большая проблема с Фактическими проблемами, связанными с SEO, заключается не в том, что URL содержит весь прекрасный текст, а в том, что когда люди меняют текст в ссылке вся ваша работа по SEO превращается в дерьмо, потому что теперь у вас есть DEADLINKS в индексах.

Для этого я хотел бы предложить, что делать с помощью stackoverflow, и иметь числовую часть, которая ссылается на постоянную сущность, и полностью игнорировать остальную часть текста (и / или обновлять его, если он неправильный)

Кроме того, исключительно наследственная природа просто делает человека непригодным для использования. Люди ненавидят длинные URL. Копирование вставляет их отстой, и они просто более склонны к взлому. Если вы можете разделить его на нижние уровни, то есть

/article/1/Some_Article_Title_Here
/article/1/Section/5/Section_Title_Here
/section/19023/Section_Title_here  ( == above link ) 

Таким образом, единственное, что вам нужно, чтобы использовать магию вуду, это когда действительно пронумерованная статья была удалена , когда вы используете текстовую часть в качестве строки поиска, чтобы попытаться найти настоящую статью или что-то в этом роде. нравится.

Answer 2

Мой последний подход:

1. Преобразование всех "странных букв" в "нормальные буквы" -> а в a, в n и т. Д.
2. Преобразовать все несловесные символы в _ (т.е. не a-zA-Z0-9)
3. заменить группы подчеркивания одним подчеркиванием
4. удалить все хвостовые и ведущие подчеркивания

Что касается хранилища, я считаю, что дружественный URL должен идти в базу данных и быть неизменным, ведь классные URI не меняются

Answer 3

При очистке URL-адресов вот метод, который я использую для замены акцентированных символов:

private static string anglicized(this string urlpart) {
        string before = "àÀâÂäÄáÁéÉèÈêÊëËìÌîÎïÏòÒôÔöÖùÙûÛüÜçÇ’ñ";
        string  after = "aAaAaAaAeEeEeEeEiIiIiIoOoOoOuUuUuUcC'n";

        string cleaned = urlpart;

        for (int i = 0; i < avantConversion.Length; i++ ) {

            cleaned = Regex.Replace(urlpart, before[i].ToString(), after[i].ToString());
        }

        return cleaned;

        // Here's some for Spanish : ÁÉÍÑÓÚÜ¡¿áéíñóúü"

}

Не знаю, является ли это наиболее эффективным регулярным выражением, но оно, безусловно, эффективно. Это метод расширения, поэтому для его вызова вы просто помещаете метод в статический класс и делаете что-то вроде этого:

string articleTitle = "My Article about café and the letters àâäá";
string cleaned = articleTitle.anglicized();

// replace spaces with dashes
cleaned = Regex.Replace( cleaned, "[^A-Za-z0-9- ]", "");

// strip all illegal characters like punctuation
cleaned = Regex.Replace( cleaned, " +", "-").ToLower();

// returns "my-article-about-cafe-and-the-letters-aaaa"

Конечно, вы можете объединить его в один метод с именем «CleanUrl» или что-то еще, но это ваше дело.

Answer 4

На случай, если кому-то интересно. Это маршрут (оооо ... Пунни) Я беру:

Route r = new Route("{country}/{lang}/Article/{id}/{title}/", new NFRouteHandler("OneArticle"));
Route r2 = new Route("{country}/{lang}/Section/{id}-{subid}/{title}/", new NFRouteHandler("ArticlesInSubcategory"));
Route r3 = new Route("{country}/{lang}/Section/{id}/{title}/", new NFRouteHandler("ArticlesByCategory"));

Это дает мне возможность делать URL так:

• site.com / са / ы / Статья / 123 / моя жизнь-и-здоровье
• site.com / са / ы / Раздел / 12-3 / Здоровье-вопросы
• site.com / са / ы / Раздел / 12 /

Answer 5

Решение 2 является типичным подходом тех ... возможны некоторые уточнения, например. превращая апострофы в ничто вместо черты, для удобства чтения. Как правило, вам потребуется сохранить в базе данных версию заголовка munged-for-URL-validity, а также «настоящий» заголовок, чтобы вы могли выбрать элемент с помощью индексированного SELECT WHERE.

Тем не менее. В части пути URL нет действительного недопустимого символа, если вы правильно его кодируете. Например, пробел, хэш или косая черта могут быть закодированы как% 20,% 23 или% 2F. Таким образом, можно закодировать любую строку в часть URL, так что вы можете ВЫБРАТЬ ее из базы данных по фактическому неизменному заголовку.

Есть несколько потенциальных проблем с этим, в зависимости от вашей веб-фреймворк. Например, все, что основано на CGI, не сможет определить разницу между закодированным% 2F и вещественным /, а некоторые инфраструктуры / развертывания могут испытывать трудности с символами Unicode.

В качестве альтернативы, простое и безопасное решение состоит в том, чтобы включить первичный ключ в URL, используя названные части исключительно для того, чтобы сделать адрес лучше. eg.:

http://www.example.com/x/category-name/subcat-name/article-name/348254863

Вот как например. Амазонка делает это. Он имеет то преимущество, что вы можете изменить заголовок в базе данных и автоматически перенаправить URL-адрес со старым заголовком на новый.

Answer 6

Как пользователь клиента, а не веб-дизайнер, я нахожу, что Firefox иногда ломает URL, когда пытается заменить «недопустимые» символы на используемые. Например, FF заменяет ~ на% 7E. Это никогда не загружает меня. Я не могу понять, почему редакторы и браузеры HTML просто не соглашаются не принимать символы, отличные от A-Z и 0-9. Если определенным сценариям требуется%,? И т. Д., Измените приложения сценариев, чтобы они работали с буквенно-цифровыми значениями.

Answer 7

Я предлагаю сделать то, что делает WordPress - вырезать маленькие слова и заменить недопустимые символы тире (максимум 1 тире), а затем позволить пользователю исправить URL-адрес, если он этого хочет. Для SEO лучше сделать URL настраиваемым.

Answer 8

Я решил эту проблему, добавив в базу данных дополнительный столбец (например, UrlTitle рядом со столбцом «Заголовок») и сохранив заголовок, лишенный всех недопустимых символов, символы «&» заменены на «и», а пробелы заменены подчеркиваниями. Затем вы можете искать через UrlTitle и использовать реальный в заголовке страницы или где-либо еще.

Answer 9

Что я обычно делаю, так это разрешаю только юридический символ и стараюсь, чтобы дружественный URL был как можно короче. Также важно то, что дружественные URL-адреса часто вставляются человеком, я никогда не генерирую дружественный URL-адрес из заголовка или содержимого, а затем использую его для запроса к базе данных. Я бы использовал столбец в таблице, например. friendly_url, чтобы администратор сайта мог вставить дружественные URL.

Answer 10

Решение 2 будет моей рекомендацией. Я не самый большой в мире эксперт по SEO, но я считаю, что это все равно «стандартный» способ получить хороший рейтинг.