Javascript — JSON или HTML?
У меня есть представление asp.net mvc, которое с помощью jquery ajax обновляет div. Должен ли я использовать контроллер, который возвращает PartialView или json? А выступления?
7 ответов
Если вы хотите, чтобы пользователь мог переключаться между различными видами, и это данные, которые можно просто включить в загрузку страницы, просто включите onload, затем скройте/покажите или загрузите как json, а затем залейте по мере необходимости.
Если это очень простой запрос, который необходимо обновить по мере необходимости, и вы не планируете другие подобные потребности в своем приложении, просто верните html.
Однако, если вы делаете запрос, который передает данные или выполняет какое-либо действие, я являюсь поклонником возвращения последовательного ответа json с ошибкой boolean, сообщением об ошибке и элементами контента/данных.
Я сам склоняюсь к JSON. Причина в том, что JSON предоставляет вам гибкость при возвращении разных данных. например.
Вы можете вернуть 100 результатов, а также некоторые метаданные о том, что эти результаты (ключевые слова, группировка и т.д.) И информация о том, сколько еще результатов доступно, как свежие результаты, пейджинговая информация.
Аналогично может появиться другая не связанная информация — сообщения о статусе, «новая почта!» индикаторы и т.д.
С возвратом чистого HTML вы ограничиваете дополнительные параметры, чтобы делать что-либо, кроме обновления содержимого HTML в контейнере.
Для меня самый крутой способ сделать AJAX — это возвращать тонкие пакеты данных, а не предварительно визуализированный HTML. Поэтому я бы сказал, что вы используете опцию JSON.
. Но все зависит от ваших потребностей. Гораздо проще показать предварительно обработанные HTML-фрагменты, поэтому, если вам нужно что-то быстрое, частичный вид может быть лучшим вариантом.
Но все это обсуждалось ранее. Итак, взгляните на эту ссылку: Ответ AJAX: XML, HTML или JSON?. Автор представляет хорошее, независимое от платформы резюме трех основных вариантов ответа AJAX с преимуществами и недостатками каждого из них.
Если вы сжимаете ответ, тогда верните HTML, иначе верните JSON и создайте клиентскую сторону HTML. В идеальном мире ваш сервер должен всегда сжимать ответ, но у вас может быть плохо настроенный сервер, который не находится под вашим контролем. Однако точка моего ответа заключается в том, чтобы сохранить его просто, поскольку на стороне сервера разница между построением HTML и JSON весьма минимальна. Также создание HTML на клиенте может быть немного медленным для пользователей с устаревшими машинами. (Или браузеры. вы знаете браузер, о котором я говорю. )
Примечание: Мой ответ следует понимать в наиболее общем контексте. Не смотря на ваш стек технологий и целевой рынок, мне было бы неправильно отвечать любым другим способом. Помните, что большинство правил в программировании больше напоминают рекомендации.
Русские Блоги
XML ， Extensible Markup Language , Расширяемый язык разметки. Расширение файла: .xml. Так же, как роль HTML заключается в отображении данных, роль XML заключается в передаче и хранении данных.
Он сказал, что java Это профессиональная операция XML язык.
Для чего это?
Для облегчения обмена данными и связи между различными приложениями и различными платформами.
(1) Может использоваться как простая база данных для хранения и извлечения данных;
(2) Передача файлов в согласованном формате;
(3) Создайте файл конфигурации программного обеспечения. [Файл конфигурации: файл для сохранения настроек программного обеспечения]
XML Брат HTML
Родился:
XML Родился, чтобы совершенствоваться HTML Дефекты и ограничения.
Различия в использовании заключаются в следующем:
Передача и хранение данных
Нет правильного запроса
Требовать вложения, соответствия и следования DTD Древовидная структура
Только один, если есть несколько
Введите несколько показать несколько
Связь с базой данных
Нет прямого контакта
Переписка и преобразование с реляционными и многоуровневыми базами данных
Чувствительность к регистру
XML Подруги JSON
Позвольте мне поговорить о разнице между «братом» и «подругой»: брат относится к матери, а подруги не родственники.
JSON ， Javascript Object Notation ， js Обозначение объекта. Роль также заключается в хранении и обмене текстовой информацией.
Сравнение двух: JSON соотношение XML Меньше, быстрее и проще разбирать, so Также более популярным.
Сфера двух: JSON Подходит для простой передачи по значению, XML Применимо к более широкому ассортименту.
———————————— Более глубокое понимание ————————————
XML Структура данных — древовидная структура
Как это воплощено, читатель может сослаться на код в примере ниже, и это будет понятно с первого взгляда.
Стоит отметить, что как у книги есть только один корень, XML Может быть только один корневой элемент.
картографирование ума
Приложенная ниже карта ума редактора, и читатели могут общаться.
Код в файле .xml:
Код в файле .xsd:
Дайте несколько каштанов, чтобы объяснить.
Например, мы хотим передать часть данных другой стороне. Содержимое данных «слишком молодое, слишком простое, иногда наивное». Если мы хотим разделить этот абзац на три данных в соответствии с атрибутами, то есть, возраст молодой, опыт слишком простой, результат иногда наивный.
Все мы знаем, что программы не похожи на людей, они могут понимать буквальное значение и автоматически разделяют данные, поэтому нам нужно помочь программе разделить, чтобы появилось множество форматов данных и методов разделения.
Например, это может быть так
Данные «слишком молодые, слишком простые, иногда наивные»
Затем разделите запятую, первая часть — это возраст, вторая — опыт, а третья — результат.
Также может быть так
Данные "too_young ** too_simple"sometimes_naive”
перехватывает первые одиннадцать символов из начала данных и удаляетПодпишите и замените подчеркивание пробелом в качестве первой части, затем перехватите следующие одиннадцать символов и удалитеИ замените подчеркивания пробелами в качестве второй части и, наконец, те же символыЧисла воспринимают пробелы как третью часть.
Оба эти метода могут использоваться для хранения данных и могут быть проанализированы, но они не являются интуитивно понятными, а универсальность не годится, и если есть строка, превышающая предел числа слов, она не может быть размещена, или сами данные могут показаться подчеркнутыми символами, которые необходимо преобразовать Праведность.
Исходя из этой ситуации, появился формат данных xml, если вышеуказанные данные выражены в XML
может быть таким
Также может быть так
Оба метода представляют собой xml, который очень интуитивно понятен, поставляется с описанием данных и имеет общую спецификацию формата, которая позволяет программе анализировать.
Если это выражается в формате JSON, это выглядит следующим образом
<
“age”:“too young”,
“experience”:“too simple”,
“result”:“sometimes naive”
>
Я не вижу этого. На самом деле, данные одинаковы. Разница лишь в формате данных. Я отправляю вам те же данные в формате xml. Вы анализируете эти три данные в формате xml и передаете их вам в формате json. Разобрать три данных в формате json. Я также могу сохранить данные в формате xml локально. Сначала я анализирую три данных, а затем создаю их в формате json, чтобы передать вам. Вы анализируете формат json и получаете три данных. Создайте его самостоятельно в формате xml и сохраните его. Если говорить прямо, будь то xml или json, это просто другой формат для упаковки данных. Важным моментом являются содержащиеся в нем данные, а не формат упаковки.
описание слова:
XML может расширять расширяемый язык разметки. Метка относится к информационному символу, который может быть понят компьютером, и с помощью этой метки статьи, содержащие различную информацию, могут обрабатываться между компьютерами. Как определить эти теги, вы можете выбрать международный язык разметки, такой как HTML, или вы можете использовать язык разметки, такой как XML, который свободно выбирают соответствующие люди. Это масштабируемость языка. XML упрощен и модифицирован из SGML. Он в основном использует XML, XSL и XPath.
Приведенный выше абзац является базовым определением XML, широко принятым описанием. Проще говоря, XML — это язык описания данных, хотя он и не имеет основных функций общих языков, он распознается и запускается компьютерами. Для объяснения используйте только другой язык, чтобы он достиг желаемого эффекта или был воспринят компьютером.
Если вы новичок в XML, вы не сможете понять, что такое XML по определению. Возможно, вы можете понять, что такое XML с другой стороны: со стороны приложения, чтобы понять XML, из XML можно что-то понять, это должно быть для вас более полезным, чем более пустое определение.
Поверхность приложения XML в основном делится на два типа: тип документа и тип данных. Вот некоторые распространенные XML-приложения:
1. Пользовательский XML + XSLT => HTML, одно из самых распространенных приложений на основе документов. XML сохраняет данные XML всего документа, а затем XSLT преобразует и анализирует XML в сочетании с тегами HTML в XSLT и, наконец, становится HTML, который отображается в браузере. Типичным примером является пост на CSDN.
2. Как микро-база данных, XML является одним из наиболее распространенных приложений для обработки данных. Мы используем соответствующие API-интерфейсы XML (MSXML DOM, JAVA DOM и т. Д.) Для доступа и запросов к XML. В реализации доски объявлений, вы часто можете увидеть использование XML в качестве базы данных. В то же время, вот несколько новичков, чтобы сказать, базы данных и системы баз данных, эти две концепции разные. Вот, кстати, влияние XML на систему баз данных. В новой версии традиционной системы баз данных XML стал типом данных. Противоположностью «традиционной» является новая форма базы данных, система баз данных, полностью основанная на технологиях, связанных с XML. В настоящее время хорошо известен eXist.
3. Как носитель передачи информации. Почему это перевозчик? Хотя эти приложения по-прежнему принимают XML в качестве базовой формы, они разработали форму формата с определенным значением. Наиболее типичным является WEB-СЕРВИС, данные упаковываются в XML для передачи, но здесь XML имеет специфическую спецификацию, а именно SOAP. Тем не менее, я все еще должен сказать AJAX. Среди приложений AJAX я считаю, что есть также некоторые приложения, которые используют пользовательский XML в качестве данных, но они не стали промышленным стандартом, и я не буду здесь подробно останавливаться.
4. Информация о конфигурации данных приложения. Наиболее типичным является web.XML, используемый J2EE для настройки веб-сервера. Это приложение оценивается как очень простое для понимания. Нам нужно только сохранить необходимые данные в XML, а затем загрузить их в наше приложение, в соответствии с различными данными, выполнить соответствующую операцию. Это на самом деле похоже на Приложение 2. Разница в том, что изменения данных в базе данных являются нормальными, а информация о конфигурации часто статична и не содержит изменений.
5. Формат XML некоторых других документов. Такие как WORD, EXCEL и т. Д.
6. Сохраните отношение сопоставления между данными. Таких как Hibernate.
Среди этих нескольких общих приложений мы также можем разделить их на: пользовательский XML и конкретный смысл XML в соответствии с их обширным применением. 1 и 2 относятся к категории пользовательских XML, 3-6 относятся к определенному значению XML или расширению XML.
Шесть приложений, представленных здесь, в основном охватывают основное использование XML. Короче говоря, XML — это абстрактный язык, который не так специфичен, как традиционные языки программирования. Чтобы глубже понять его, вы должны начать с его применения, выбрать нужное вам применение, а затем научиться его использовать.
Лучшая практика: загрузка визуализированного html или json?
Привет, ребята, у меня вопрос, который кажется глупым, но я не могу сказать почему.
Задний план:
Представьте себе веб-приложение с пользователями и тегами. Пользователи отмечают друг друга.
У меня есть одна страница в приложении, которая отображает подробную информацию об одном теге по отношению к одному пользователю. Скажем, пользователь bob и пометил тег footag . На этой странице я показываю два списка: всех людей, которые пометили bob тегом «footag», и всех людей, которые bob пометили тегом «footag». назовем их <div id sent»>
Скажем, URL-адрес этого представления: /users/bob/tags/footag
Естественно, эти списки длинные — я не хочу загружать весь список при просмотре страницы. Поэтому я загружаю первые десять штук для каждого.
Вопрос
Теперь я могу обеспечить динамическое разбиение на страницы для каждого из списков одним из двух способов:
- Получите данные для следующих 10 пользователей как json. Напишите js для рендеринга этих данных, заменив содержимое div .
- Получите обработанный «фрагмент» html с другого четко определенного URL-адреса на моем сервере, скажем /users/bob/tags/footag/received?page=1 . Я получаю его асинхронно и просто заменяю содержимое соответствующего <div> .
Итак, в одном случае я получаю данные и визуализирую их через JS в браузере, в другом — получаю обработанные данные и просто вставляю их в документ.
Есть ли причина не использовать №2? Не могу себе представить, но полагаю, что могут быть аспекты безопасности, которые я не рассматриваю, или производительность, или что-то еще. Я бы предпочел сделать №2, так как это значительно упрощает мою жизнь.
Как парсить страницы сайтов с автоподгрузкой на примере Instagram
Статья обновлена 19 января 2020 в связи с изменениями структуры JS необходимой для извлечения query_hash в парсере по тэгам. Механика автоподгрузки на страницах сайтов осуществляется с помощью Javascript. Поэтому, для того, чтобы определить на какой URL нам нужно обращаться и какие параметры использовать, нам нужно либо досконально изучить JS код который работает на странице, либо, и что предпочтительней, изучить запросы, которые делает браузер при прокрутке страницы вниз. Изучить запросы мы можем с помощью Инструментов для разработчика, которые встроены во все современные браузеры. В нашей статье мы будем использовать Google Chrome, но вы можете использовать любой другой браузер, приняв во внимание, что инструменты разработчика могут выглядеть по разному в разных браузерах.
Изучать нашу задачу мы будем на примере Instagram, а именно, используя официальный канал Instagram. Откроем эту страницу в браузере, и запустим Chrome Dev Tools — инструменты для разработчика, которые встроены в Google Chrome. Для этого кликнем правой кнопкой мыши в любом месте страницы и выберем опцию «Просмотреть код» или нажмите «Ctrl+Shift+I»:
У нас откроется окно инструментов, где мы перейдем во вкладку Network и в фильтрах выберем показ только XHR запросов. Мы это делаем для того, чтобы отфильтровать ненужные нам запросы. После этого перезагрузим страницу в браузере с помощью кнопки Reload в интерфейсе браузера или клавиши «F5» на клавиатуре.
Давайте теперь прокрутим страницу вниз несколько раз с помощью колесика мышки, что вызовет подгрузку контента. Каждый раз, когда при прокручивании мы будем достигать нижней части страницы, JS будет делать XHR запрос на сервер, получать данные и добавлять их на страницу. В результате, у нас в списке окажется несколько запросов, которые выглядят почти одинаково. Скорее всего они нам и нужны.
Чтобы удостовериться в этом, мы должны выбрать один из запросов и в открывшемся окне перейти во вкладку Preview. Там мы сможем увидеть отформатированное содержимое, которое сервер прислал в браузер по этому запросу. Доберемся до одного из конечных элементов и удостоверимся, что там находятся данные об изображениях, которые есть у нас на странице.
Убедившись, что это нужные нам запросы, рассмотрим один из них более внимательно. Для этого перейдем во вкладку Headers. Там мы можем найти информацию о том, на какой именно URL производится запрос, какой тип запроса (POST или GET) используется, а также какие параметры передаются с запросом.
Параметры запроса лучше изучать в секции Query String Parameters, прокрутив рабочее окно в панели инструментов вниз до конца:
Результатом нашего анализа станут следующие факты:
URL запроса: https://www.instagram.com/graphql/query/
Тип запроса: GET
Передаваемые параметры: query_hash и variables
Очевидно, что в query_hash передается статичный id, который генерируется, скорее всего, когда вы заходите на страницу. В variables же передаются некие параметры в JSON формате, влияющие на выборку данных.
Давайте проведем небольшой эксперимент, возьмем URL с параметрами, который использовался для загрузки данных:
Если бы до последнего апдейта API мы бы взяли и вставили его в адресную строку браузера и нажали Enter, то мы бы увидели как загрузится страница в JSON формате:
Однако, теперь просто так API Инстаграма не отдает данные, для этого необходимо рассчитать подпись для запроса и передать ее в заголовке запроса. Этот вопрос более подробно рассматривается ниже. Без корректного заголовка все что мы получим сейчас — это ошибку 403.
Теперь нам нужно понять, откуда берется query_hash. Если мы перейдем во вкладку Elements и попытаемся найти (CTRL+F) наш query_hash f2405b236d85e8296cf30347c9f08c2a, то мы узнаем что на самой странице его нет, а значит он подгружается или генерируется где-то в коде Javascript. Поэтому, перейдем опять во вкладку Network и поставим фильтр на JS. Таким образом мы увидим только запросы на JS файлы. Последовательно перебирая запрос за запросом, будем искать наш id в загруженных файлах: просто выбираем запрос, затем открываем в открывшейся панели вкладку Response чтобы увидеть содержимое JS и делаем поиск нашего id (CTRL+F). После нескольких неудачных попыток, мы обнаружим, что наш id находится в следующем JS файле:
а фрагмент кода, который обрамляет id, выглядит так:
Соответственно, для получения query_hash нам надо найти на первой странице URL на ProfilePageContainer.js файл, извлечь этот URL, забрать JS файл по этому URL, распарсить место с нужным нам id и записать его в переменную для дальнейшего использования.
Теперь давайте посмотрим, что за переменные передаются в variables:
Если мы проанализируем все XHR запросы с догружаемыми данными, что мы обнаружим, что меняется только параметр after. Поэтому id скорее всего есть id канала, который мы парсим, first — количество записей, которые сервер должен отдать по запросу, а after — очевидно id последней показанной записи.
Нам нужно найти место, из которого мы можем извлечь id канала, для этого первым делом мы поищем текст 25025320 в исходном коде начальной страницы. Перейдем во вкладку Elements и сделаем поиск (CTRL+F) нашего id. Мы обнаружим, что он есть в JSON структуре на самой странице, именно оттуда мы и можем его извлечь:
Вроде все понятно, но где нам брать этот самый after для каждой последующей подгрузки? Все очень просто. Если мы загрузим в браузере следующий URL:
мы увидим, что там есть следующая структура:
То есть, в нашей логике мы сможем использовать значение поля has_next_page чтобы знать переходить ли на следующую страницу или нет и end_cursor как значение параметра after.
Сейчас мы напишем заготовку нашего парсера, загрузим первую страницу и попытаемся загрузить JS файл с query_id. Создайте диггер в вашем аккаунте Diggernaut и добавьте в него следующую конфигурацию:
Установите диггер в режим Отладка. Теперь нам нужно запустить наш парсер и после того как он отработает посмотреть лог. В конце лога мы увидим как диггернаут работает с JS файлами. Он преобразовывает их в следующую структуру:
А значит селектор для забора всего JS будет script. Давайте допишем функцию парсинга query_id из JS:
Сохраним наш парсер и снова запустим. Подождем когда он закончит работу и посмотрим в лог. В логе мы увидим следующую строчку:
Set variable queryid to register value: 42323d64886122307be10013ad2dcc44
Это значит, что query_hash был успешно извлечен и записан в переменную с именем queryid.
Теперь мы извлечем id канала. Как вы помните, он есть в JSON объекте на самой странице. Поэтому нам нужно взять содержимое определенного элемента script, вытащить оттуда JSON, конвертировать его в XML и забрать нужное нам значение, используя CSS селектор.
Если вы внимательно посмотрите в лог, то увидите, что JSON структура трансформируется в DOM следующим образом:
Это поможет нам построить CSS селекторы для забора первых 12 записей и маркера последней записи, который нужен нам для забора следующих 12 записей. Напишем логику для извлечения данных, а также начем формировать пул (pool) линков со ссылками на фиды (feeds) с подгружаемыми данными. Далее начнем итерацию по пулу линков и посмотрим как преобразует Diggernaut полученный JSON, так, чтобы мы смогли построить корректные CSS селекторы для логики парсера.
Совсем недавно Instagram сделал изменения в публичном API, теперь для авторизация делается не по CSRF токену, а по специальной сигнатуре, которая рассчитывается используя новый параметр rhx_gis, передаваемый в sharedData странице канала и передаваемые в запросе переменные. Алгоритм можно узнать при разборе JS. Этот алгоритм мы используем и будем автоматически подписывать запросы. Для этого нам нужно извлечь rhx_gis параметр.
После запуска в логе мы можем увидеть вот такую структуру, с которой нам нужно работать:
Мы намеренно укоротили исходный код, убрав повторяющиеся элементы. Теперь мы можем описать логику парсинга всех нужных нам полей, а также добавить ограничитель на количество подгрузок, скажем, 10. Также мы добавим паузу, для менее агрессивного парсинга. В результате мы получим финальную версию нашего парсера Instagram.
Теперь мы пожем перевести наш диггер в Активный режим и запустить его. Как результат в вашем наборе данных будут подобные записи.
Надеемся что данная статья поможет вам в изучении мета-языка и теперь вы сможете решать задачи по парсингу страниц с подгрузкой без затруднений. В качестве домашнего задания, попробуйте разобраться с тем как работает версия парсера для поиска по хэштегам. Ниже приведим код парсера: