Summary
StringConstraint appears to use mb_detect_encoding() when calculating string length for minLength / maxLength.
I think this should be avoided. JSON Schema string length keywords are defined in terms of JSON string characters. They should not depend on heuristic detection of the runtime encoding of a PHP string.
Problem
Using mb_detect_encoding() here makes string length validation less deterministic.
In particular:
- the detected encoding may depend on PHP configuration such as the detection order;
- the same input may be validated differently in different environments;
- schema keyword evaluation becomes dependent on encoding guessing;
- the validator treats the value like an arbitrary PHP byte string whose encoding needs to be guessed, rather than as a JSON instance string.
JSON Schema validation operates on JSON instances. A JSON string is not an arbitrary PHP byte string whose encoding should be rediscovered during keyword validation.
Expected direction
For minLength / maxLength, the implementation should avoid encoding detection and use UTF-8 explicitly, for example:
mb_strlen($value, 'UTF-8')
This would make string length validation more deterministic and better aligned with JSON Schema semantics.
Scope
This issue is not about adding explicit UTF-8 validity checks to StringConstraint.
UTF-8 validity should normally be handled at the JSON parsing boundary, for example by json_decode(). JSON Schema validation should operate on the resulting JSON instance representation, not on raw input bytes.
Therefore, the narrower concern here is that minLength / maxLength should not rely on mb_detect_encoding(), because schema keyword evaluation should not depend on heuristic encoding detection.
Whether this library should reject PHP strings that are not valid UTF-8 when users validate PHP values directly is a separate compatibility and responsibility question.
Compatibility note
Changing from detected encoding to fixed UTF-8 may affect users who validate non-UTF-8 PHP strings directly.
However, JSON Schema operates on JSON instances, so using UTF-8 consistently seems more appropriate than relying on heuristic encoding detection.
Summary
StringConstraintappears to usemb_detect_encoding()when calculating string length forminLength/maxLength.I think this should be avoided. JSON Schema string length keywords are defined in terms of JSON string characters. They should not depend on heuristic detection of the runtime encoding of a PHP string.
Problem
Using
mb_detect_encoding()here makes string length validation less deterministic.In particular:
JSON Schema validation operates on JSON instances. A JSON string is not an arbitrary PHP byte string whose encoding should be rediscovered during keyword validation.
Expected direction
For
minLength/maxLength, the implementation should avoid encoding detection and use UTF-8 explicitly, for example:This would make string length validation more deterministic and better aligned with JSON Schema semantics.
Scope
This issue is not about adding explicit UTF-8 validity checks to
StringConstraint.UTF-8 validity should normally be handled at the JSON parsing boundary, for example by
json_decode(). JSON Schema validation should operate on the resulting JSON instance representation, not on raw input bytes.Therefore, the narrower concern here is that
minLength/maxLengthshould not rely onmb_detect_encoding(), because schema keyword evaluation should not depend on heuristic encoding detection.Whether this library should reject PHP strings that are not valid UTF-8 when users validate PHP values directly is a separate compatibility and responsibility question.
Compatibility note
Changing from detected encoding to fixed UTF-8 may affect users who validate non-UTF-8 PHP strings directly.
However, JSON Schema operates on JSON instances, so using UTF-8 consistently seems more appropriate than relying on heuristic encoding detection.