Comments (3)
The Json Schema specification does not define "base64" as a format specifier. So trying that isn't going to work unless the chosen schema validator has a custom implementation for a custom "base64" format.
On the other hand, the Json Schema spec defines "base64" as a content encoding for the contentEncoding
keyword. But the contentEncoding
keyword is an annotation, not an assertion. The current Json Schema validation spec goes even so far as to stipulate that schema validators shall not do contentEncoding-based parsing/decoding/validation by default. And even if a validator is doing a contentEncoding-based validation, the particulars of the validation and the returned results is left unspecified by the spec. (https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-validation-01#section-8.2). So, this is also not looking too great, either...
Any ideas how to make it work?
Yes. RFC4648-conforming Base64 is a rather simple data format with a very specific and limited set of characters, arranged in 4-character tuples (https://datatracker.ietf.org/doc/html/rfc4648#section-4 ). This can be relatively easily modeled by a regex pattern (using the pattern
keyword instead of format
).
The case-insensitive pattern for one full non-padded 4-char tuple is basically: [a-z0-9+/]{4}
.
The last 4-char tuple (or the single tuple if the decoded data is <= 3 bytes in length) however can be a full 4-char tuple or padded tuple in the form of XX== or XXX=, the regex pattern for the last tuple in the encoded Base64 string thus being (with white-spaces for legibility): ( [a-z0-9+/]{4} | [a-z0-9+/]{2}(=|[a-z0-9+/])= )
Therefore, the full regex pattern that matches non-empty Base64-strings that consist of one or more 4-character tuples:
(?i)^([a-z0-9+/]{4})*([a-z0-9+/]{4}|[a-z0-9+/]{2}(=|[a-z0-9+/])=)$
If the schema you are designing should be interoperable/compatible with various different schema validators (which is probably a good idea to follow regardless of whether you have this particular requirement right now or not), it's preferable to not use the (?i)
inline-flag in the regex pattern (as it is not part of the ECMAScript/JavaScript regex dialect the Json Schema regex specification for the pattern
keyword refers to). Instead, use both the a-z
and A-Z
ranges in the character classes to achieve case-insensitive matching, like for example so:
^([a-zA-Z0-9+/]{4})*([a-zA-Z0-9+/]{4}|[a-zA-Z0-9+/]{2}(=|[a-zA-Z0-9+/])=)$
(No guarantee about me not making a silly error here when plonking down the regex pattern here. Please do verify it yourself before putting it into production code...)
from json-everything.
Thank you for the detailed response. The regex works fine :)
The Json Schema specification does not define "base64" as a format specifier. So trying that isn't going to work unless the chosen schema validator has a custom implementation for a custom "base64" format.
On the other hand, the Json Schema spec defines "base64" as a content encoding for the
contentEncoding
keyword. But thecontentEncoding
keyword is an annotation, not an assertion. The current Json Schema validation spec goes even so far as to stipulate that schema validators shall not do contentEncoding-based parsing/decoding/validation by default. And even if a validator is doing a contentEncoding-based validation, the particulars of the validation and the returned results is left unspecified by the spec. (https://json-schema.org/draft/2020-12/draft-bhutton-json-schema-validation-01#section-8.2). So, this is also not looking too great, either...Any ideas how to make it work?
Yes. RFC4648-conforming Base64 is a rather simple data format with a very specific and limited set of characters, arranged in 4-character tuples (https://datatracker.ietf.org/doc/html/rfc4648#section-4 ). This can be relatively easily modeled by a regex pattern (using the
pattern
keyword instead offormat
).The case-insensitive pattern for one full non-padded 4-char tuple is basically:
[a-z0-9+/]{4}
.The last 4-char tuple (or the single tuple if the decoded data is <= 3 bytes in length) however can be a full 4-char tuple or padded tuple in the form of XX== or XXX=, the regex pattern for the last tuple in the encoded Base64 string thus being (with white-spaces for legibility):
( [a-z0-9+/]{4} | [a-z0-9+/]{2}(=|[a-z0-9+/])= )
Therefore, the full regex pattern that matches non-empty Base64-strings that consist of one or more 4-character tuples:
(?i)^([a-z0-9+/]{4})*([a-z0-9+/]{4}|[a-z0-9+/]{2}(=|[a-z0-9+/])=)$
If the schema you are designing should be interoperable/compatible with various different schema validators (which is probably a good idea to follow regardless of whether you have this particular requirement right now or not), it's preferable to not use the
(?i)
inline-flag in the regex pattern (as it is not part of the ECMAScript/JavaScript regex dialect the Json Schema regex specification for thepattern
keyword refers to). Instead, use both thea-z
andA-Z
ranges in the character classes to achieve case-insensitive matching, like for example so:^([a-zA-Z0-9+/]{4})*([a-zA-Z0-9+/]{4}|[a-zA-Z0-9+/]{2}(=|[a-zA-Z0-9+/])=)$
(No guarantee about me not making a silly error here when plonking down the regex pattern here. Please do verify it yourself before putting it into production code...)
from json-everything.
Please read through the documentation. You will find that @elgonzo's response is correct.
Another solution is to create a custom format. Information for doing so can be found in the linked documentation.
from json-everything.
Related Issues (20)
- Polish language localization HOT 6
- Regression in Schema Evaluation After Upgrading from 5.5.1 to 6.0.3 HOT 16
- How to get list of JSON Pointers that have the format keyword of date-time value from a JSON Schema HOT 4
- Support xml comments on generated schema HOT 13
- Deconstruct JsonLogic for conversion into another format HOT 8
- Spam
- Spam
- Support Case Insensitive Match on Property Names HOT 2
- Support custom keywords in schema generation HOT 6
- Evaluate JsonRequired Attribute HOT 5
- Model with Nullable value type is invalid HOT 1
- Model is not valid when has integer value as string HOT 1
- that the custom metastructure could not be parsed HOT 4
- How to extend SchemaGenerator for DateTime HOT 7
- JsonSchema.NET DataValidation HOT 10
- Custom `IAttributeHandler` never called HOT 5
- Anchors naming of 2020 still following 2019 rules HOT 5
- Generating a Custom JSON Schema HOT 1
- ArgumentOutOfRangeException thrown when calling JsonSchema's Evaluate methods from multiple threads. HOT 3
- 2020-12 output incorrectly places annotations
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from json-everything.