0

My data is originally JSON, I'm downloading it raw and saving it to database as such:

saveToDatabase( json_encode( $data ) );

The problem, though, is that now the JSON gets encoded twice, since it's originally JSON and I'm, again, encoding it. Thing is, I need an universal answer. This is supposed to be a wrapper over a general-purpose downloader and I can't simply not json_encode everything, because I need to safely save it to the database, but if I do two json_decode over that saved data, unless it's JSON, it'll break.

How can I solve this paradox?

coolpasta
  • 725
  • 5
  • 19
  • check if it is json, before encoding it https://stackoverflow.com/questions/6041741/fastest-way-to-check-if-a-string-is-json-in-php –  May 11 '19 at 03:17
  • I guess, raw means, you have a string, then there is the answer. – Nikolaus May 11 '19 at 03:17
  • @Nikolaus Sigh. Thought PHP had an in-built thing for this case. – coolpasta May 11 '19 at 03:18
  • A built-in thing that prevents you from running `json_encode` on a string that happens to already be valid JSON-encoded data? If you know that your data is already JSON-encoded, why encode it again, just save it as it is. – Greg Schmidt May 11 '19 at 04:25
  • @GregSchmidt That's the thing. My downloader is a general-purpose "retrieve the contents of whatever is on this link's body". Simple. Thing is, it needs to be saved to the database and I thought about all weird characters and had to come up with a way to **encode** it. WordPress does the job with sanitizing and stuff so I don't have to worry. What do you suggest for my case? – coolpasta May 11 '19 at 05:28
  • What you're retrieving is a string. Save it as a string. What's the specific use case where that fails? – Greg Schmidt May 11 '19 at 12:16
  • Could you show the body of the http-request/-response? Maybe I could clarify, what I meant, then. – Nikolaus May 13 '19 at 05:35
  • @GregSchmidt I think OP wants, to have objects in the database, not just a string representing them. What’s the use case for them? Maybe to can filter by field in a select statement, eg a date or a number, that shouldn’t be stored as a part of a string then, because the behavior is different. – Nikolaus May 13 '19 at 05:39
  • @Nikolaus Well, the idea is that the body from any page, no matter what you do is always a string, always. Now, I thought that `json_encode` would be a great way to ensure that no weird characters / things are entered in the database, but this is an issue: when you save a string that's actually JSON and you do `json_encode` over it, then a JSON...something is stored in the database in a...weird way: It has `""` added to it, basically when you do `json_decode`, on first run, the `""` is removed, then you need to run it again to get the JSON object itself. – coolpasta May 13 '19 at 05:46
  • Also, no, I just want the string to be **safely stored**, but if that string turns out to be JSON, then this behavior happens. The stored item should ultimately just be a string. – coolpasta May 13 '19 at 05:46
  • Again, the body from any page *is* a string. It might be a JSON-encoded string, it might be HTML, it might have UNICODE embedded in it. But it's still a string, and should be something you can save directly into the database as-is. If that's causing you problems, then please describe the specifics of those problems, but it really feels like trying to JSON-encode everything you get is a bit of an [XY Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). – Greg Schmidt May 13 '19 at 05:56
  • Watch out! If the reason of your json encoding is to be sure nothing "bad" gets into the database, use prepared statements, not json_encode. https://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php – Filip Halaxa Dec 26 '19 at 15:25

0 Answers0