Который лучше для сайта направляющих? / {вход в систему} или/user/[закрытый] {вход в систему}
Это работает, если ваши данные не содержат , или :, потому что нам нужно несколько якорей, чтобы распутать этот беспорядок:
import re
a='{"1":"abc"de"fg","2":"xyz"xyz"xyz"}'
b = re.sub('"((?:[^,:]|")*)"',lambda m : '"{}"'.format(m.group(1).replace('"','')),a)
>>> b
'{"1":"abcdefg","2":"xyzxyzxyz"}'
- регулярное выражение соответствует строке между кавычками и функцией замены удаляет внутренние кавычки.
- мы создаем внутреннюю не захватывающую группу
(?:[^,:]|"), чтобы сказать, чтобы она соответствовала кавычкам или чему угодно, кроме запятой и двоеточия.
теперь b можно анализировать как json:
>>> import json
>>> json.loads(b)
{'1': 'abcdefg', '2': 'xyzxyzxyz'}
теперь, что если строка содержит :? Решение выше не работает. Мы должны адаптировать его:
- разделить в соответствии с
":"(с возможными пробелами) - применить такое же регулярное выражение, как указано выше (с удалением только первой кавычки) для всех элементов разделенный список
- объединяет элементы с
":"
следующим образом:
import re,json
# a lot of colons in keys & values
a='{"1":"a:bc"de"fg","2:":"xy::z"xyz"xyz"}'
b = '":"'.join(re.sub('((?:[^,:]|")*)"',lambda m : '{}"'.format(m.group(1).replace('"','')),x) for x in re.split('"\s*:\s*"',a))
print(json.loads(b))
В результате получается правильный анализ json:
{'1': 'a:bcdefg', '2:': 'xy::zxyzxyz'}
5 ответов
Я сказал бы, что недостатки перевешивают профессионалов, поэтому пойдите с/user/login по входу в систему/. Рассмотрите stackoverflow, так как это - MVC также: Я думаю, что это легче к программе, зная, что все в/user/blah будет всегда относиться к пользователю, тогда как, если Вы не делаете этого, необходимо будет рассмотреть каждую возможность.
Например, в сайте/нечто, нечто могло быть именем пользователя, администраторской страницей или некоторым другим ключевым словом. Намного легче иметь дело с тем, если Вы правильно сегментируете все все, таким образом, Вы знаете, видите ли Вы сайт/пользователя/нечто, это всегда - пользователь, названный нечто.
Вы могли бы рассмотреть третью возможность:
Разграничивание пользователей с отдельным символом, вместо каталога, как в Unix.
Это может даже привести к modrewrite к/user/username, если это более удобно.
Затем у Вас есть краткие названия, легко иметь дело с, и ни одна из Ваших регулярных страниц не будет использовать тот специальный символ.
- Adam
Существует очень важная проблема с разрешением пользователям создать произвольные имена в корне веб-сервера (поскольку они могли chosing свой собственный вход в систему, если Вы используете / {вход в систему} вместо/user/{вход в систему}): некоторые имена имеют специальные волшебные значения, и эти значения определяются третьими лицами. Например:
- robots.txt, также известный как "Стандарт исключения роботов", сопровождаемый всеми поисковыми системами хорошего поведения.
- favicon.ico, который запустился как стандарт Internet Explorer и позже был принят несколькими другими браузерами.
- Некоторые веб-сайты (по крайней мере, Google и Yahoo IIRC) используют то, что можно создать специально именованный файл в корне веб-сервера как доказательство, что Вы - веб-мастер сайта и таким образом предоставляете Вам доступ к некоторым дополнительным функциям (как Google Webmaster Tools).
Существует несколько других; я услышал о картах сайта и файлах, предоставляющих дополнительный междоменный доступ, но нет никакого пути I (или кто-либо еще) может знать всех их.
Лично я пошел бы для/user/{вход в систему}
Используя / {вход в систему} чувствует совсем как загромождение глобального пространства имен, и все мы знаем, что globals плохи ;)
От УСПОКОИТЕЛЬНОГО MVC в прошлый раз, когда я проверил, примером от Успокоительного плагина Аутентификации является сессия, создают шаблон. Таким образом вместо того, чтобы войти в систему пользователь, Вы создаете сессию для пользователя. В этом случае GET http://{site}/session/new показал бы экран входа в систему и POST http://{site}/session с корректными параметрическими усилителями зарегистрировал бы пользователя в том, если аутентификация успешна.
Затем если Вы хотите, может создать новый маршрут для http://{site}/login это перенаправило бы к http://{site}/session/new. Так же DELETE http://{site}/session зарегистрировал бы Вас.