У меня есть сайт MVC ASP.NET, где я хочу маршруты как /{controller}/{id}/{action}/{date}
, где "дата" является mm/dd/yyyy частью даты/времени. (Я имею дело с определенными размеры временем данными, таким образом, мне нужны и идентификатор и в момент времени, чтобы сделать большинство операций),
Маршрут для этого прост:
routes.MapRoute(
"TimeDimensionedRoute",
"{controller}/{id}/{action}/{date}",
new { controller = "Iteration", action = "Index", id = String.Empty, date = String.Empty }
);
Этот маршрут правильно отображает "/Foo/100/Edit/01%2F21%2F2010" на желаемое действие. Обновление: это неправильно. Это НЕ направляется правильно, я ошибался. Посмотрите связанный вопрос, связанный в принятом ответе.
Моя проблема - это, когда я использую HTML. ActionLink () для генерации ссылки для этого маршрута это не делает URL - кодируют дату, и я заканчиваю с недопустимыми URL, такими как "/Foo/100/Edit/01/21/2010".
Там какой-либо путь состоит в том, чтобы заставить инфраструктуру маршрутизации кодировать значения для меня? Кажется неправильным, что я имею к вручную URL - кодируют данные, которые я передаю помощникам HTML.
Вы не можете использовать переднюю косушку в значение маршрута в ASP.NET MVC. Даже если это закодировано URL, он не будет работать.
Существует только решение, если вы используете ASP.NET 4.0
Полагаю, что он не кодирует автоматически url, поэтому html-хелперу сложно определить, хотите ли вы представить дату или хотите иметь в маршруте еще 3 поля, например,
// Here's what you're seeing
/Foo /100 /Edit /10/21/2010/
// 4 route values
// But there's know way to know you don't want this
/Foo /100 /Edit /10 /21 /2010/
// 6 route values
Может быть, вы могли бы изменить маршрут на
...
"{controller}/{id}/{action}/{month}/{day}/{year}",
...
Таким образом, он всегда будет работать без экранирования.
В противном случае, вы можете сделать кодирование URL-адреса даты внутри вызова Html.ActionLink(...)
Я не знаю, считается ли это ответом или нет, но я всегда используйте формат гггг-мм-дд
в URI. Не потому, что косые черты зарезервированы в соответствии с RFC (хотя это веская причина), а потому, что они невосприимчивы к проблемам глобализации при преобразовании в / из строки. DateTime.Parse ()
«просто работает» с этим форматом, даже если кто-то устанавливает локаль сервера где-то в Восточной Европе.