Php valid json string

Check if String is a Valid Json in PHP

This tutorial will discuss about unique ways to check if string is a valid json in php.

Table Of Contents

Method 1: Using json_decode()

The json_decode() accepts a JSON encoded string as parameter, and if it is a valid json string then it converts the string into a PHP value. Where if it is not a valid JSON then the last error will not be JSON_ERROR_NONE.

We have create a function to validate JSON string i.e.

It accepts a string as argument and returns true if given string is a valid JSON string.

Frequently Asked:

Let’s see the complete example,

 $strValue = '< "name": "Ritika", "age" : 32, "city": "London" >'; if (isStringJson($strValue)) < echo "The string represents valid JSON."; >else < echo "The string does not represent valid JSON."; >?>

The string represents valid JSON.

Method 2: Using json_decode() with error suppression

If error suppression is enabled, then we can rely on the return valud of json_decode() .

The json_decode() accepts a JSON encoded string as parameter, and if it is a valid json string then it converts the string into a PHP value. If it is not a valid JSON string then it returns null.

We have create a function to validate JSON string i.e.

It accepts a string as argument and returns true if given string is a valid JSON string.

Let’s see the complete example,

 $strValue = ''; if (isValidJSON($strValue)) < echo "The string represents valid JSON."; >else < echo "The string does not represent valid JSON."; >?>

The string represents valid JSON.

Summary

We learned about two ways to check if a string is a valid JSON string or not in PHP.

Related posts:

Share your love

Leave a Comment Cancel Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Terms of Use

Disclaimer

Copyright © 2023 thisPointer

To provide the best experiences, we and our partners use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us and our partners to process personal data such as browsing behavior or unique IDs on this site and show (non-) personalized ads. Not consenting or withdrawing consent, may adversely affect certain features and functions.

Click below to consent to the above or make granular choices. Your choices will be applied to this site only. You can change your settings at any time, including withdrawing your consent, by using the toggles on the Cookie Policy, or by clicking on the manage consent button at the bottom of the screen.

The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.

The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.

The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.

The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.

Источник

PHP RFC: json_validate

This RFC introduces a new function called json_validate() to validate if an string contains a valid json.

Most userland implementations use json_decode() which by design generates a ZVAL(object/array/etc.) while parsing the string, ergo using memory and processing that could be save.

The proposed function will use the exact same JSON parser that already exists in the PHP core, which is also use by json_decode(), this garantees that what is valid in json_validate() is also valid in json_decode().

Proposal

Description

json_validate(string $json, int $depth = 512, int $flags = 0): bool

Parameters

The json string being analyzed.

This function only works with UTF-8 encoded strings.

PHP implements a superset of JSON as specified in the original » RFC 7159.

Maximum nesting depth of the structure being decoded.

Bitmask of JSON_INVALID_UTF8_IGNORE. The behavior of this constant is described on the JSON constants page.

Return values

Returns true if the string passed contains a valid json, otherwise returns false.

Examples

1. Validate a valid json-string

2. Validate an invalid json-string

Errors during validation can be fetch by using json_last_error() and/or json_last_error_msg().

General notes from discussion of the RFC

Different users have tested the functionality and obtained the promised results. Also their feedback about it was positive.

Most part of the community in the mailing list showed a positive opinion about this RFC , and looks forward for its integration into PHP.

The ones that checked the code also agree that is small implementation, easy to maintain, and at the same time provides a big benefit for such small implementation.

The community got involve very actively in the discussion of the RFC and provided all kind of useful feedback, and also took the time to test json_validate() by themselves.

Use cases contributed by the community

Eventhough not reduce to only these examples, during discussion in mailing list, some users expressed:

“Yes well-formed JSON from a trusted source tends to be small-ish. But a validation function also needs to deal with non-well-formed JSON, otherwise you would not need to validate it.”

“If with a new function (json_validate()) it becomes much easier to defend against a Denial-of-Service attack for some parts of a JSON API , then this can be a good addition just for security reasons.”

“fast / efficient validation of a common communication format reduces the attack surface for Denial-of-Service attacks.”

Reasons to have json_validate() function in the core

Based on discussion of the RFC in the mailing list

Disadvantages of using json_decode to only validate a json-string

By design, json_decode() generates a ZVAL (object/array/etc.) while parsing the string, ergo using memory and processing for it, that is not needed if the only thing to discover is if a string contains a valid json or not.

Disadvantages of using regex

Using a regex for this task forces different, error-prone, hard to maintain, implementations.

Disadvantages of userland solutions

They need to be up-to-date with the existing PHP JSON parser used by json_decode() already, otherwise a json-string valid in userland solution might not be valid json-string for json_decode() or vice-versa.

PHP already has a JSON parser

As previously mentioned, PHP already has a JSON parser used by json_decode(). The proposed function will use that parser, guaranteeing 100% compatibility between json_decode() and json_validate()

Needs from major projects and developers

In the “References” section, there is a list of major open-source php projects that could benefit with this new function.

Also in the mentioned section a link to one of the most popular StackOverflow questions is provided, which somehow reflects the need from our developers to have a feature like this included.

Please check the “References” section.

Complexity added in the core

At the moment, there is a JSON parser in the core, used by json_decode() to do its job, so there is no need to write a new JSON parser for this RFC ; the proposed function will use the existing JSON parser exclusively to parse an string without generating any object/array/etc. in memory for it.

Reasons NOT to have json_validate() function in the core

One member of the mailing list expressed that:

“If we keep the tendency to pollute already bloated standard library with an army of small functions that could have not exists and be replaced with normal PHP counterparts IMHO we’ll end with frustration from developers as I believe DX slowly falls down here.”

“A `json_decode()` is a substitute that IMO solves 99% of use cases. If I’d follow your logic and accept every small addition that handles 1% of use cases, somebody will raise another RFC for simplexml_validate_string or yaml_validate and the next PhpToken::validate. All above can be valid if we trust that people normally validate 300MB payloads to do nothing if they DON’T fail and there is nothing strange about that.”

The user also provided an implementation of a JSON parser written in pure PHP. https://gist.github.com/brzuchal/37e888d9b13937891c3e05fead5042bc

Changes in the RFC that happened during discussion

Throw Exception on error

In my initial implementation, the developer had the option to provide a flag to indicate that in case of error during validation an exception should be throw.

The ability to throw an exception on error was removed from the implementation, as this was pointed not only by most of user in the mailing list (with good reasons), but also during code review; as it does not make sense to have such a behavior.

I also have to admit that after they showed their arguments, I changed my mind, and now I also think it makes sense to have such a behavior in the function.

So removing the ability to throw exception on error was removed from implementation.

Others

I removed 3 of the originally provided examples in the RFC because did not adjust to the RFC purpose or were not clear.

I had to adjust the wording in this RFC document regarding disadvantage of using json_decode() as pointed here:

Backward Incompatible Changes

None, as this is a new function only.

json_validate will no longer be available as a function name.

Proposed PHP Version(s)

RFC Impact

This RFC has no impact on SAPIs, existing extensions, Opcache, etc.

Future Scope

— (To be defined by future discussions if needed)

Источник

PHP RFC: is_json

This RFC introduces a new function called is_json() to validate if an string contains a valid json.

Most userland implementations to achieve this are done using json_decode() which by design generates an object/array while parsing the string, ergo using memory and processing, that could be save.

Proposal

Description

is_json(string $json, int $depth = 512, int $flags = 0): bool

Parameters

The json string being analyzed.

This function only works with UTF-8 encoded strings.

PHP implements a superset of JSON as specified in the original » RFC 7159.

Maximum nesting depth of the structure being decoded.

Bitmask of JSON_INVALID_UTF8_IGNORE, JSON_THROW_ON_ERROR. The behavior of these constants is described on the JSON constants page.

Function description, examples, technical strategy, current JSON parser, etc.

Return values

Returns true if the string passed contains a valid json, otherwise returns false.

Extra behavior

Examples

Fundaments/Reasons

Disadvantages of using json_decode

By design, json_decode() generates an object/array while parsing the string, ergo using memory and processing for it, that is not needed if the only thing to discover is if a string contains a valid json.

Disadvantages of using regex

Using a regex for this task forces different, error-prone, hard to maintain, implementations.

Needs from major projects and developers

In the “References” section, there is a list of major open-source php projects needing this feature; also in th mntioned section can find a link to one of the most popular StackOverflow questions, which somehow reflects the need from our developers to have a feature like this included.

Complexity added in the core

At the moment, there is a JSON parser in the core, used by json_decode to do its job, so there is no need to write a new JSON parser for this RFC ; the proposed function will use the existing JSON parser exclusively to parse an string without generating any object/array in memory for it.

Backward Incompatible Changes

None, as this is a new function only.

is_json will no longer be available as a function name, could break potential userland implementations.

Proposed PHP Version(s)

RFC Impact

This RFC has no impact on SAPIs, existing extensions, Opcache, etc.

Источник