Added support for duplicate keys via ALLOW_DUPLICATE_KEYS constant. Will take something like:

{
    "a" : 1234,
    "a" : 4567,
    "a" : 8910
}

and convert to

{
    "a" : 1234,
    "a.1" : 4567,
    "a.2" : 8910
}

In this way, if someone has a JSON file with keys that are acted like verbs, for example, for using JSON as configuration files, where you may have multiple action blocks. Rather than wrap blocks in extra brackets, or be forced to add unique charachters to verb.

Composer fails from an exception of this library on PHP 7 so I enabled testing against PHP7 to see if unit tests pass. https://travis-ci.org/yiisoft/yii2/jobs/52251656#L1496

$json = '{ "test": "Информация о балансе на договоре по номеру телефона: возвращает количество найденых договоров, баланс, блокировку, номер договора, тип договора, игнорим расторгнутые договора." }'; $parser = new JsonParser(); $parser->lint($json); $data = $parser->parse($json);

Hey, we've just run into a major issue with jsonlint regarding performance today. Our requests were all timing out and stopped at the lexer. Here's a Sentry screenshot:

We've investigated the JSON that it tried to parse and while it was a bit bigger than usual, the parsing times were a LOT higher.

So I've done some digging. The following numbers are for formatted JSON files:

Lines (approx.) | execution time ---------|--------------- 10k | 1.89s user 0.03s system 96% cpu 1.989 total 25k | 6.29s user 0.05s system 98% cpu 6.419 total 40k | 25.82s user 13.47s system 99% cpu 39.521 total 50k | 58.24s user 43.51s system 99% cpu 1:42.27 total

(lines to time ratio)

As it turns out, the library is actually waiting for the system to do its thing.

A blackfire run with 3 samples on the 50k lines JSON shows that substr seems to be the culprit:

Due to privacy concerns I can't share the JSON file, but there should be random JSON generators out there that can create files for you.

Many thanks in advance!

Closes #59

I'm not an expert at this so I'm not sure this is the best way to handle this case to be honest. It's also a bit weird to use json_decode there but I've picked that solution as alternatives suggested the use of mb_string and I preferred to avoid a dependency on an extension at this point.

I noticed that when installing this through composer the tests are also part of the package.

Will you accept a PR to remove tests and supporting files from the distributions? If so, I will create one.

I know not everyone likes that, hence I'm asking first.

With the test json:

{ 	nonceValue:"90a9225e1ac785aea7c9e80f232d21a6" }

(yep, just that)

PHP's own json_decode returns Syntax error, it looks like Github's markdown display system also detects the issue, and https://jsonlint.com/ returns

Error: Parse error on line 1:
{	nonceValue: "90a9225
--^
Expecting 'STRING', '}', got 'undefined'

However, the linter (release 1.7) fails to detect an issue.

Given the following JSON:

{
  "errors": [
    {
      "message": "Argument \u0022input\u0022 has an invalid value: ...."
    }
  ]
}

(for some reason a mink driver is returning this instead of \"...)

With json_decode() you will get:

{#4
  +"errors": array:1 [
    0 => {#5
      +"message": "Argument "input" has an invalid value: ...."
    }
  ]
}

However with JsonParser you will get:

{#17
  +"errors": array:1 [
    0 => {#16
      +"message": "Argument "input" has an invalid value: ...."
    }
  ]
}

Any idea of how this could be fixed?

Given the following JSON:

{
  "SA-CORE-2019-002": "../patches/sa-core-2019-002.patch",
  "#3026386-26 - Drush fatal error after upgrading to 8.6.6, 8.5.9, or 7.62: PHP Fatal error: Uncaught TYPO3\PharStreamWrapper\Exception": "https://www.drupal.org/files/issues/2019-01-16/d8-3026386-26.patch"
}

the error is:

test.json: Parse error on line 2:
...-2019-002.patch",  "#3026386-26 - Drush
---------------------^
Invalid string, it appears you forgot to terminate a string, or attempted to write a multiline string which is invalid - It appears you have an extra trailing comma

The error message doesn't seem related, as there is no extra trailing comma.

Hi! I guess your code does support. :) I just see some limitations in composer.json file. Could you test your code and update requirements?

Thanks for the module, by the way!

Added support for multiple JSON files to be passed as arguments to jsonlint cli utility

Basic usage: ./vendor/bin/jsonlint file.json otherFile.json

Advanced usage: ./vendor/bin/jsonlint $(find . -type f -iname "*.json" -printf "%p ")

Output example: ./jsonlint file.json otherFIle.json Checking 2 files Valid JSON (file.json) Valid JSON (otherFIle.json)