Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Json::encode escapes unicode entities #2111

Closed
hdodov opened this issue Sep 17, 2019 · 5 comments

Comments

@hdodov
Copy link

commented Sep 17, 2019

To Reproduce
Steps to reproduce the behavior:

  1. Put this in a template:
echo \Kirby\Data\Json::encode('здравей');
  1. Echoed string is:
\u0437\u0434\u0440\u0430\u0432\u0435\u0439

Expected behavior
The encoded string should be здравей

Kirby Version
3.2.3

Additional context
This can be fixed by simply adding a flag in Json::encode() (tested):

json_encode($data, JSON_UNESCAPED_UNICODE);
@afbora

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

Instead of direct usage, we can enchance encode() method passing optional options param.

public static function encode($data, int $options = 0): string
{
    return json_encode($data, $options);
}

Usage:

echo \Kirby\Data\Json::encode('здравей', JSON_UNESCAPED_UNICODE);
@bastianallgeier

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

I prefer @afbora's way. As I understand it, the version with encoded unicode characters is more stable. That's why it's the PHP default.

@distantnative distantnative added this to the 3.3.0 milestone Sep 17, 2019
bastianallgeier added a commit that referenced this issue Sep 17, 2019
@bastianallgeier bastianallgeier modified the milestones: 3.3.0, 3.2.5 Sep 17, 2019
bastianallgeier added a commit that referenced this issue Sep 17, 2019
@bastianallgeier

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

@lukasbestle

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2019

@bastianallgeier We can't really do it that way as that changes the method signature compared to the other Data handler classes. I see three problems with it:

  • It could be confusing because you would expect that all handlers work the same way (which they currently do).
  • We won't be able to add params to the other handlers that aren't compatible with this new $options param, otherwise the different handlers won't be compatible anymore (which they should be as the whole Data package should be a transparent translation layer between memory data and serialization forms).
  • You can't pass the $options param when calling Data::write($myFile . '.json', $data) directly, so it's of limited use.

I haven't found any background information on the PHP JSON option constants, but I'd imagine they are there for backwards-compatibility. Some ancient parsers don't play well with Unicode and also with slashes, which is why the JSON_UNESCAPED_SLASHES and JSON_UNESCAPED_UNICODE constants are probably not enabled by default. But I can't imagine that there are actually still parsers out there that can't handle those chars. So we should actually be pretty safe to always use those two options. Or have you found any more specific information @bastianallgeier?

@lukasbestle lukasbestle reopened this Sep 17, 2019
bastianallgeier added a commit that referenced this issue Sep 18, 2019
@bastianallgeier

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

@lukasbestle you are right. I added the two options as default. I agree that they should be fine as general defaults. By removing the param again, the code is also a bit simpler, which is good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.