Как проверить json на валидность notepad
Допустим, у вас есть база данных пользователей, где каждая запись выглядит примерно так:
Вопрос, с которым мы собираемся разобраться, заключается в том, как определить, является ли запись, подобная приведенной выше, действительной или нет.
Примеры очень полезны, но недостаточны при описании ваших требований к данным. На помощь приходит JSON-схема. Это одна из возможных схем, описывающих запись пользователя:
Посмотрите на схему выше и запись пользователя, которую она описывает (которая действительна в соответствии с этой схемой). Здесь есть много объяснений.
Код JavaScript для проверки записи пользователя по схеме может быть:
Все примеры кода доступны в GitHub repo tutsplus-json-schema . Вы также можете попробовать это в браузере .
Ajv , валидатор, используемый в примере, является самым быстрым валидатором JSON-Schema для JavaScript. Я создал его, поэтому собираюсь использовать его в этом уроке.
Прежде чем мы продолжим, давайте быстро разберемся со всеми причинами.
Зачем проверять данные как отдельный шаг?
- быстро провалиться
- чтобы избежать повреждения данных
- упростить обработку кода
- использовать проверочный код в тестах
Почему JSON (а не XML)?
- такое широкое распространение, как XML
- проще в обработке и более кратким, чем XML
- доминирует в веб-разработке благодаря JavaScript
Зачем использовать схемы?
- декларативный
- легче поддерживать
- могут быть поняты некодерами
- не нужно писать код, можно использовать сторонние библиотеки с открытым исходным кодом
Почему JSON-схема?
- самое широкое применение среди всех стандартов для проверки JSON
- очень зрелый (текущая версия 4, есть предложения для версии 5)
- охватывает большую часть сценариев проверки
- использует простые для анализа документы JSON для схем
- независимая платформа
- легко растяжимый
- 30+ валидаторов для разных языков, в том числе 10+ для JavaScript, поэтому не нужно кодировать его самостоятельно
Задания
Этот учебник включает в себя несколько относительно простых задач, которые помогут вам лучше понять схему JSON и то, как ее можно использовать. Есть простые сценарии JavaScript, чтобы проверить, что вы сделали их правильно. Для их запуска вам нужно установить node.js (вам не нужно с этим работать). Просто установите nvm (менеджер версий узлов) и последнюю версию node.js:
Вам также необходимо клонировать репозиторий и запустить npm install (он установит валидатор Ajv).
Давайте погрузимся в схемы!
Свойства данных
Поскольку большинство данных JSON состоит из объектов с несколькими свойствами, ключевое слово «свойства» , вероятно, является наиболее часто используемым ключевым словом. Это относится только к объектам (см. Следующий раздел о том, что означает «применять»).
В приведенном выше примере вы могли заметить, что каждое свойство внутри ключевого слова «properties» описывает соответствующее свойство в ваших данных.
Здесь важно то, что ключевое слово «properties» не требует никаких свойств; он определяет только схемы для свойств, присутствующих в данных.
Например, если наша схема:
тогда объекты со свойством «foo» или без него могут быть действительными согласно этой схеме:
и только объекты, которые имеют свойство foo, не являющееся строкой, недопустимы:
Тип данных
Вы уже выяснили, что делает ключевое слово «тип» . Это, наверное, самое важное ключевое слово. Его значение (строка или массив строк) определяет, какой тип (или типы) данных должен быть действительным.
Как видно из приведенного выше примера, пользовательские данные должны быть объектом.
Что значит «подать заявку»? Допустим, у нас действительно простая схема:
Вы можете ожидать, что, чтобы быть действительным согласно такой схеме, данные должны быть строкой, соответствующей шаблону:
Благодаря этому вы можете создавать очень гибкие схемы, которые будут проверять несколько типов данных.
Посмотрите на свойство «id» в примере пользователя. Он должен быть действительным в соответствии с этой схемой:
Эта схема требует, чтобы действительные данные были либо «строкой», либо «целым числом» . Существует также ключевое слово «pattern», которое применяется только к строкам; требуется, чтобы строка состояла только из цифр и не начиналась с 0. Существует ключевое слово «минимум», которое применяется только к числам; для этого необходимо, чтобы число было не менее 1.
Другой, более подробный способ выразить то же самое требование:
Но из-за способа определения JSON-схемы эта схема эквивалентна первой, которая короче и быстрее проверяется в большинстве валидаторов.
Проверка номеров
Есть несколько ключевых слов для проверки чисел. Все ключевые слова в этом разделе относятся только к числам (включая целые числа).
«Минимум» и «максимум» говорят сами за себя. В дополнение к ним есть ключевые слова «exclusiveMinimum» и «exclusiveMaximum» . В нашем примере пользователя возраст пользователя должен быть целым числом 13 или больше. Если схема для возраста пользователя была:
тогда эта схема потребовала бы, чтобы возраст пользователя был строго больше 13, то есть минимально допустимый возраст был бы 14.
Проверка строк
Есть также несколько ключевых слов для проверки строк. Все ключевые слова в этом разделе относятся только к строкам.
«MaxLength» и «minLength» требуют, чтобы строка была не длиннее или не короче заданного числа. Стандарт JSON-схемы требует, чтобы пара юникода, например символ эмодзи, считалась одним символом. JavaScript учитывает его как два символа при доступе к свойству .length строк.
Некоторые валидаторы определяют длины строк в соответствии со стандартом, а некоторые делают это способом JavaScript, что быстрее. Ajv позволяет вам указать, как определять длину строки, и по умолчанию это соответствует стандарту.
Ключевое слово «format» определяет семантическую проверку строк, таких как «email» , «date» или «date-time» в примере пользователя. JSON-схема также определяет форматы «uri» , «hostname» , «ipv4» и «ipv6» . Валидаторы по-разному определяют форматы, оптимизируя скорость проверки или правильность. Айв дает вам выбор:
Большинство валидаторов позволяют вам определять пользовательские форматы как регулярные выражения или проверочные функции. Мы могли бы определить собственный формат «телефон» для нашей схемы, чтобы использовать его в нескольких местах:
и тогда схема для свойства phone будет такой:
Задание 1
Создайте схему, которая потребует, чтобы данные были датой (строка) или годом (числом), а год был больше или равен 1976 году.
Поместите свой ответ в файл part1/task1/date_schema.json и запустите node part1/task1/validate чтобы проверить его.
Проверка объекта
В дополнение к «свойствам» в нашем примере пользователя вы можете увидеть несколько других ключевых слов, которые применяются к объектам.
Если бы у нас была эта схема:
тогда все объекты без свойства foo будут недействительными.
Ключевое слово «patternProperties» позволяет вам определять схемы, в соответствии с которыми значение свойства данных должно быть допустимым, если имя свойства соответствует регулярному выражению. Его можно комбинировать с ключевым словом «properties» в той же схеме.
Свойство feeds в пользовательском примере должно быть допустимым в соответствии с этой схемой:
Чтобы быть действительными, feeds должны быть объектом со свойствами, имена которых состоят только из латинских букв и значения которых являются логическими.
Ключевое слово «AdditionalProperties» позволяет вам либо определить схему, в соответствии с которой все остальные ключевые слова (не используемые в «свойствах» и не соответствующие «patternProperties» ) должны быть действительными, либо полностью запретить другие свойства, как мы это делали в свойстве feeds схема выше.
В следующем примере «AdditionalProperties» используется для создания простой схемы для хеша целых чисел в определенном диапазоне:
Ключевые слова «maxProperties» и «minProperties» позволяют ограничить количество свойств в объекте. В нашем пользовательском примере схема для свойства address выглядит следующим образом:
Эта схема требует, чтобы адрес являлся объектом с необходимыми свойствами street , postcode , city и country , допускает два дополнительных свойства («maxProperties» равно 6) и требует, чтобы все свойства были строками.
«Зависимости» , вероятно, являются наиболее сложным и запутанным и наиболее редко используемым ключевым словом, но в то же время это очень мощное ключевое слово. Это позволяет вам определить требования, которым должны удовлетворять данные, если они имеют определенные свойства.
Существует два типа таких требований к объекту: иметь некоторые другие свойства (это называется «зависимость от свойства») или удовлетворить некоторую схему («зависимость от схемы»).
В нашем пользовательском примере одна из возможных схем, в отношении которых пользовательское соединение должно быть действительным, заключается в следующем:
Для этого требуется, connType свойство connType равно «относительному» (см. Ключевое слово «enum» ниже), а если свойство relation присутствует, это строка.
Это не требует наличия relation , но ключевое слово «зависимости» требует, чтобы ЕСЛИ свойство relation присутствовало, ТОЛЬКО свойство close тоже должно присутствовать.
Обратите внимание, что схема в свойстве «отношение» в ключевом слове «зависимости» используется для проверки родительского объекта (т. Е. Соединения), а не значения свойства relation в данных.
Задача 2
Ваша база данных содержит людей и машины. Используя только ключевые слова, которые я объяснил до сих пор, создайте схему для проверки обоих. Образец человеческого объекта:
Пример машинного объекта:
Обратите внимание, что это должна быть одна схема для проверки как людей, так и машин, а не две схемы.
Поместите свой ответ в файл part1/task2/human_machine_schema.json и запустите node part1/task2/validate чтобы проверить его.
Подсказки: используйте ключевое слово «зависимости» и посмотрите в файле part1/task2/invalid.json чтобы увидеть, какие объекты должны быть недействительными.
Какие объекты, которые, вероятно, также должны быть недействительными, отсутствуют в файле invalid.json ?
Я думаю, что основная цель проверки состоит в том, чтобы проверить недействительные данные как недействительные, и в этом вся сложность.
Проверка массива
Существует несколько ключевых слов для проверки массивов (и они применяются только к массивам).
«MaxItems» и «minItems» требуют, чтобы массив содержал не больше (или не меньше), чем определенное количество элементов. В примере пользователя схема требует, чтобы количество соединений не превышало 150.
Ключевое слово «items» определяет схему (или схемы), в соответствии с которой элементы должны быть действительными. Если значением этого ключевого слова является объект (как в примере с пользователем), то этот объект является схемой, в соответствии с которой данные должны быть действительными.
Если значением ключевого слова «items» является массив, то этот массив содержит схемы, в соответствии с которыми соответствующие элементы должны быть действительными:
Как насчет предметов после этих двух? Схема выше не определяет никаких требований для других предметов. Они могут быть определены с помощью ключевого слова « AdditionalItems».
Ключевое слово « AdditionalItems» применяется только к ситуации, в которой ключевое слово «items» является массивом, и в данных содержится больше элементов, чем в ключевом слове «items» . Во всех остальных случаях (без ключевого слова items , это объект или в данных больше нет элементов) ключевое слово AdditionalItems будет игнорироваться независимо от его значения.
Если ключевое слово « AdditionalItems» имеет значение true, оно просто игнорируется. Если оно ложно и в данных содержится больше элементов, чем в ключевом слове «items», проверка завершается неудачно:
Если ключевое слово « AdditionalItems» является объектом, то этот объект является схемой, в соответствии с которой все дополнительные элементы должны быть действительными:
Пожалуйста, поэкспериментируйте с этими примерами, чтобы увидеть, как работают «items» и «AdditionalItems» .
Последнее ключевое слово, которое применяется к массивам, это «uniqueItems» . Если его значение равно true , оно просто требует, чтобы все элементы в массиве были разными.
Проверка ключевого слова «uniqueItems» может быть вычислительно дорогой, поэтому некоторые валидаторы решили не реализовывать ее или делать это только частично.
Ajv имеет возможность игнорировать это ключевое слово:
Задача 3
Одним из способов создания объекта даты в JavaScript является передача от 2 до 7 чисел в конструктор Date:
var date2 = new Date(year, month0, day, hour, minute, seconds, ms);У вас есть массив. Создайте схему, которая проверит, что это допустимый список аргументов для конструктора Date.
Поместите свой ответ в файл part1/task3/date_args_schema.json и запустите node part1/task3/validate чтобы проверить его.
Ключевое слово «Enum»
Ключевое слово enum требует, чтобы данные были равны одному из нескольких значений. Это относится ко всем типам данных.
В примере пользователя он используется для определения gender свойства внутри personal свойства как «мужской» или «женский». Он также используется для определения свойства connType в пользовательских подключениях.
Ключевое слово «enum» может использоваться с любыми типами значений, не только со строками и числами, хотя это не очень распространено.
Он также может использоваться для требования, чтобы данные были равны определенному значению, как в примере пользователя:
Предложения для следующей версии (v5) стандарта JSON-Schema включают ключевое слово «константа», чтобы сделать то же самое.
Ajv позволяет использовать «константу» и некоторые другие ключевые слова из v5:
Ключевые слова проверки соединения
Есть несколько ключевых слов, которые позволяют вам определить расширенную логику, включающую проверку по нескольким схемам. Все ключевые слова в этом разделе относятся ко всем типам данных.
В нашем примере пользователя используется ключевое слово «oneOf» для определения требований к пользовательскому соединению. Это ключевое слово допустимо, если данные успешно проверены по одной схеме внутри массива.
Если данные являются недействительными по всем схемам в ключевом слове «oneOf» или действительны по двум или более схемам, то данные являются недействительными.
Давайте посмотрим более внимательно на наш пример:
Приведенная выше схема требует, чтобы пользовательское соединение было либо «относительным» (свойство connType ), и в этом случае оно может иметь свойства relation (строка) и close (логическое), либо один из типов «друг», «коллега» или «другое» ( в этом случае он не должен иметь relation свойств и close ).
Есть еще одно ключевое слово, которое позволяет вам избежать этого: «anyOf» . Это ключевое слово просто требует, чтобы данные были действительными согласно некоторой схеме в массиве (возможно, нескольким схемам).
Использование «oneOf» в тех случаях, когда «anyOf» выполняет одинаково хорошую работу, является очень распространенной ошибкой, которая отрицательно влияет на производительность проверки.
Наш пользовательский пример также выиграл бы от замены «oneOf» на «anyOf» .
Однако в некоторых случаях нам действительно необходимо ключевое слово «oneOf» :
В данной статье описывается стандарт JSON Schema и его использование для проверки соответствия заданному формату на языке C++ средствами библиотеки valijson.
Немного истории
Для начала вспомним, что привело к повсеместному вытеснению JSON-ом XML-а и что в этом было плохого. XML изначально создавался как метаязык разметки документов, позволяя использовать унифицированный код парсера и валидатора документов. Будучи первым стандартом такого рода, да еще и пришедшимся на период бурного внедрения цифровых корпоративных информационных систем, XML послужил основой для бесчисленного множества стандартов сериализации данных и протоколов взаимодействия, т.е. хранения и передачи структурированных данных. Тогда как создавался он прежде всего для разметки документов.
Будучи разрабатываемым комитетами, стандарт XML оказался дополнен множеством расширений, позволяющих, в частности, избегать конфликтов имен и выполнять сложные запросы в XML-документах. И, самое важное, поскольку получающееся нагромождение тэгов оказывалось совершенно нечитаемым никаким человеком, был разработан и широко реализован стандарт XML Schema, позволяющий на том же XML абсолютно строго описать допустимое содержимое каждого документа с целью последующей автоматической проверки.
Тем временем, все больше разработчиков под влиянием зарождающихся интерактивных web-технологий стало знакомиться с языком JavaScript, и они начали осознавать, что для представления структурированных объектов в текстовом виде совершенно не обязательно изучать много сотен страниц XML-спецификаций. И когда Дуглас Крокфорд предложил стандартизовать подмножество JavaScript для сериализации объектов (но не разметки документов!) безотносительно к языку, идея была поддержана сообществом. В настоящее время JSON является одним из двух (вместе с XML) языков, поддерживаемых всеми сколько-либо популярными технологиями программирования. Тот же YAML, призванный сделать JSON более удобным и человекочитаемым, ввиду своей сложности (т.е. широты возможностей) распространен не так широко (в моей компании не так давно были проблемы с работой с YAML из MATLAB, тогда как с JSON все хорошо).
JSON Schema
Рассмотрим пример простой, но показательной, схемы, задающей словарь 2D или 3D геометрических точек в пространстве (-1, 1)x(-1, 1)x(-1, 1) с ключами, состоящими из цифр:
Если простить Крокфорду надоедливые кавычки, из данного докуменда должно быть ясно, что мы согласны иметь дело с объектом (словарем), ключи которого должны состоять из цифр (см регулярное выражение), значения которого обязаны иметь поля x, y, value, и могут иметь поле z, причем value — неотрицательное число, а x, y, z все имеют некий одинаковый тип point_coord, соответствующий числу от -1 до +1. Даже если предположить, что других возможностей JSON Schema не предоставляет (что далеко от истины), этого должно хватить для многих сценариев использования.
Но это в том случае, если для вашего языка/платформы реализован валидатор. В случае с XML такой вопрос вряд ли мог бы встать.
Тем не менее, приемлемое решение существует и называется valijson. У этой библиотеки есть все что нам нужно (валидация схем и BSD-лицензия), и даже больше, — независимость от JSON-парсера. Valijson позволяет использовать любой json-парсер посредством адаптера (в комплекте адаптеры для jsoncpp, json11, rapidjson, picojson и boost::property_tree), таким образом не требуя переходить на новую json-библиотеку (или тащить за собой еще одну). Плюс ко всему, она состоит только из заголовочных файлов (header only) и не требует компиляции. Очевидный минус только один, и то не для всех, — зависимость от boost. Хотя есть надежда на избавление даже от этого недо-недостатка.
Разберем на примере документа составление JSON-схемы и валидацию этого документа.
Пример составления схемы
Допустим, у нас есть таблица неких полосатых объектов, для которых задана конкретная полосатая раскраска (в виде последовательности 0 и 1, соответствующих черному и белому).
Здесь мы имеем словарь с числовыми ключами, к которым может быть приписан суффикс «inv» (для инвертированных штрих-кодов). Все значения в словаре являются объектами и обязаны иметь поля «width», «stripe_length» (строго положительные числа) и «code» (строка нулей и единиц длины 12).
Начнем составлять схему, указав ограничения на формат имен полей верхнего уровня:
Здесь мы воспользовались конструктом patternProperties, разрешающим/специфицирующим значения, ключи которых удовлетворяют регулярному выражению. Также мы указали (additionalProperties=false), что неспецифицированные ключи запрещены. Используя additionalProperties, можно не только разрешить или запретить неуказанные явно поля, но и наложить ограничения на их значения, указав в качестве значения спецификатор типа, например, так:
Далее опишем тип значения каждого объекта в словаре:
Здесь мы явно перечисляем разрешенные поля (properties), требуя их наличие (required), не запрещая (по умолчанию) любые дополнительные свойства. Числовые свойства у нас строго положительные, а строка code должна соответствовать регулярному выражению.
В принципе осталось только вставить описание типа отдельного объекта в вышеописанную схему таблицы. Но прежде чем это сделать, отметим, что у нас дублируется спецификация полей «width» и «stripe_length». В реальном коде, из которого взят пример, таких полей еще больше, поэтому полезно было бы один раз определить данный тип, а потомы ссылаться на него отосвюду. Именно для этого есть механизм ссылок ($ref). Обратите внимание на секцию definitions в итоговой схеме:
Сохраним ее в файл и приступим к написанию валидатора.
Применение valijson
В качестве json-парсера используем jsoncpp. Имеем обычную функцию загрузки json-документа из файла:
Минимальная функция-валидатор, сообщающая нам о расположении всех ошибок валидации, выглядит примерно так:
Теперь мы можем загружать и валидировать документы:
Все, мы научились валидировать json-документы. Но обратим внимание, что теперь нам придется думать, где хранить схемы! Ведь если документ каждый раз меняется и получается, например, из web-запроса или из аргумента командной строки, то схема неизменна и должна поставляться вместе с приложением. А для небольших программ без развитого механизма загрузки статических ресурсов необходимость введения такового представляет значительный барьер для внедрения валидачии через схемы. Вот было бы здорово компилировать схему вместе с программой, ведь изменение схемы в любом случае потребует изменения кода, обрабатывающего документ.
Это возможно и даже довольно удобно, если в нашем распоряжении есть C++11. Решение примитивное, но работает прекрасно: мы просто определяем строковую константу с нашей схемой. А чтоб не заботиться о кавычках внутри строки, мы используем raw string literal:
Таким образом, мы имеем удобный кроссплатформенный кросс-языковой механизм валидации json-документов, использование которого в C++ не требует ни линковки внешних библиотек с неудобными лицензиями, ни возни с путями к статическим ресурсам. Эта вещь может сэкономить действительно много сил, и, что немаловажно, помочь окончательно убить XML как формат представления объектов, ибо он неудобен ни для людей, ни для машин.
Я осмотрел все параметры TextFX, но не смог найти ничего, что работало.
JSTool (ранее известный как JsMin/JsMinNpp)
установить
скачать с http://sourceforge.net/projects/jsminnpp/ и копия JSMinNpp.dll в каталог плагинов Notepad++. Или вы можете просто установить "JSTool" из менеджера плагинов в Notepad++.
установить новый Notepad++ и куда пошел PluginManager? См.как просмотреть менеджер плагинов в Notepad++
Совет: выберите код, который вы хотите переформатировать, затем Plugins | JSTool / JSFormat.
универсальный отступ GUI плагин для Notepad++ превратит ваш образец в:
Я лично использую JSON Viewer поскольку плагин Notepad++ больше не работает.
EDIT-24 мая 2012
Я советую вам загрузить плагин JSMin для блокнота, как указано в ответ. Это хорошо работает для меня в последней версии (v6.1.2 на момент написания статьи).
EDIT-7 ноября 2017
согласно комментарию @danday74 ниже, JSMin теперь JSToolNpp. Кроме того, имейте в виду, что инструмент просмотра JSON находится на Codeplex, который, вероятно, исчезнет в ближайшем будущем.
Это не решение АЭС, но в крайнем случае, вы можете использовать этот онлайн форматер JSON а затем просто вставьте форматированный текст в NPP, а затем выберите Javascript в качестве языка.
Это сработало для меня в последнем издании Блокнота с использованием UniversalIndentGui.
то, что я сделал, было под настройкой плагина, выберите включить автоматическое обновление текста, появилось окно, и я выбрал javascript.
Блокнот 5.8.7 и jsmin 1.7.0.0 прекрасно работает здесь.
будьте осторожны, выяснила помощью jsmin ест комментариях трудный путь (должен быть).
Я использую плагин JSON Viewer с NPP 5.9, и он, похоже, работает хорошо.
используйте на свой страх и риск, ОФК. (стандартный отказ от ответственности от меня при связывании чего-либо вне SExchange, fyi)
вам нужен плагин для форматирования JSON.Чтобы установить плагин do following step
- открыть блокнот++ - > ALT+P - > менеджер плагинов - > Selcet JSON Viewer - > нажмите Установить
- перезапустить notepad++
- Теперь вы можете использовать ярлык для форматирования json как CTRL + ALT +SHIFT + M или ALT+P - > менеджер плагинов - > JSON Viewer - > формат JSON
Если вы не хотите устанавливать плагин Notepad++, но у вас есть Firefox и плагин JSON для Firefox, вы можете выбрать Run -> Launch in Firefox . Вы получаете содержимое в формате JSON с помощью плагина Firefox.
это то, что я лично делаю.
Я знаю, что вы спросили о NotePad++, но TextMate для OS X может сделать это через пакет JSON, его называют командой "переформатировать документ".
лучше всего использовать одну из последних версий Eclipse (я использую Eclipse Galileo J2EE и Eclipse Ganymede J2EE). Создайте файл JavaScript, затем создайте переменную:
и, наконец, нажмите CTRL + SHIFT + F и вуаля! У вас есть красивый объект JSON с отступом. Я тоже ищу форматер Notepad++ JSON, и я очень хорошо могу быть вынужден разработать плагин Npp некоторое короткое время в будущем.
Основной особенностью скриптов в формате JSON является взаимозаменяемость его на формат XML. Оба типа представляют собой текстовые документы, которые можно открывать текстовыми процессорами. Однако начнем мы со специализированного ПО.
Способ 1: Altova XMLSpy
Достаточно известная среда разработки, которую используют в том числе и веб-программисты. Эта среда также генерирует файлы JSON, следовательно способна и открывать сторонние документы с таким расширением.
Недостатков у данного ПО два. Первый – платная основа распространения. Пробная версия активна 30 дней, однако для её получения необходимо указать имя и почтовый ящик. Второй – общая громоздкость: человеку, которому просто нужно открыть файл, она может показаться чересчур навороченной.
Способ 2: Notepad++
Плюсов у Notepad++ изрядно – тут и отображение синтаксиса многих языков программирования, и поддержка плагинов, и малый размер… Однако в силу некоторых особенностей работает программа неторопливо, особенно если открыть в ней объемный документ.
Способ 3: AkelPad
Невероятно простой и в то же время богатый на возможности текстовый редактор от российского разработчика. В число поддерживаемых им форматов входит и JSON.
Как и Notepad++, этот вариант блокнота также бесплатен и поддерживает плагины. Он работает шустрее, однако большие и сложные файлы может не открыть с первого раза, так что имейте в виду такую особенность.
Способ 4: Komodo Edit
Бесплатное ПО для написания программного кода от компании Komodo. Отличается современным интерфейсом и широкой поддержкой функций для программистов.
В программе, к сожалению, отсутствует русский язык. Однако рядового пользователя скорее отпугнет избыточный функционал и непонятные элементы интерфейса – все-таки этот редактор ориентирован в первую очередь на программистов.
Способ 5: Sublime Text
Еще один представитель code-oriented текстовых редакторов. Интерфейс проще, чем у коллег, однако возможности те же. Доступна и портативная версия приложения.
К сожалению, Sublime Text недоступен на русском языке. Недостатком можно назвать и условно-бесплатную модель распространения: свободная версия ничем не ограничена, но время от времени появляется напоминание о необходимости покупки лицензии.
Способ 6: NFOPad
Простой блокнот, однако для просмотра документов с расширением JSON тоже подойдет.
NFOPad подходит для просмотра JSON-документов, однако есть нюанс – при открытии некоторых из них программа намертво зависает. С чем связана такая особенность – неизвестно, но будьте внимательны.
Способ 7: Блокнот
И наконец, стандартный текстовый процессор, встроенный в ОС Windows, также способен открывать файлы с расширением JSON.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Читайте также: