A plugin in my Joomla installation stores the following data structure/encoding in the database:
a:20:{s:3:"UID";s:32:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";s:11:"X-EXTRAINFO";s:0:"";s:8:"LOCATION";s:0:"";s:11:"allDayEvent";s:3:"off";s:7:"CONTACT";s:0:"";s:11:"DESCRIPTION";s:63:"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";s:12:"publish_down";s:9:"2015-9-23";s:10:"publish_up";s:9:"2015-9-23";s:13:"publish_down2";s:9:"2015-9-23";s:11:"publish_up2";s:9:"2015-9-23";s:7:"SUMMARY";s:17:"xxxxxxxxxxxxxxxxxx";s:3:"URL";s:0:"";s:11:"X-CREATEDBY";i:708;s:7:"DTSTART";i:1443031200;s:5:"DTEND";i:1443045599;s:5:"RRULE";a:4:{s:4:"FREQ";s:4:"none";s:5:"COUNT";i:1;s:8:"INTERVAL";s:1:"1";s:5:"BYDAY";s:24:"+1SA,+2SA,+3SA,+4SA,+5SA";}s:8:"MULTIDAY";s:1:"1";s:9:"NOENDTIME";s:1:"1";s:7:"X-COLOR";s:0:"";s:9:"LOCKEVENT";s:1:"0";}
I replaced some characters with x's to erase 'sensitive' information.
I get how the encoding works: it uses arrays(a), string(s) and integer(i) with some length, if applicable, between colons.
However, I want to know name of this encoding and I would like to know it there is some off-the-shelf php-function that parses the information, like json_decode for JSON.
The encoding appears to be 'a storable representation of a value'.
As #AbraCadaver states in the comments, the PHP function serialize converts PHP data objects to this representation. The PHP function unserialize creates a PHP value from the stored representation.
Related
I want to edit some options from a WordPress installation. I located the fields in a serialized field in wp_options:
the value of field is in the following format:
a:93:{s:19:"hide_upgrade_notice";s:5:"3.3.5";s:25:"icl_capabilities_verified";b:1;s:21:"interview_translators";i:1;s:34:"existing_content_language_verified";i:1;s:25:"language_negotiation_type";s:1:"1";s:23:"theme_localization_type";i:1;s:14:"icl_lso_header";i:0;s:18:"icl_lso_link_empty";i:0;s:13:"icl_lso_flags";s:1:"1";s:19:"icl_lso_native_lang";i:0;s:20:"icl_lso_display_lang";i:0;s:18:"sync_page_ordering";i:1;s:16:"sync_page_parent";i:1;s:18:"sync_page_template";i:1;s:16:"sync_ping_status";i:1;s:19:"sync_comment_status";i:1;s:16:"sync_sticky_flag";i:1;s:13:"sync_password";i:1;s:17:"sync_private_flag";i:1;s:16:"sync_post_format";i:1;s:11:"sync_delete";i:0;s:15:"sync_delete_tax";i:0;s:20:"sync_post_taxonomies";i:1;s:14:"sync_post_date";i:0;s:21:"sync_taxonomy_parents";i:0;s:25:"translation_pickup_method";i:0;s:15:"notify_complete";i:1;s:26:"translated_document_status";i:1;s:17:"remote_management";i:0;s:15:"auto_adjust_ids";i:1;s:11:"alert_delay";i:0;s:12:"promo
How is this formatted? I know that this isn't valid JSON.
How can I edit/remove settings manually?
This is PHP serialized data, a format that is largely unused now thanks to the prevalence of JSON. It was quite popular among PHP developers at one stage. It fell into disuse because there are some security concerns with php serialize and unserialize and also because of the rise of JSON. However it's still found in some apps.
use unserialize to convert to a php object
unserialize — Creates a PHP value from a stored representation
Note: You haven't posted a valid serialized string (it's truncated)
I have a SOAP client in PHP that makes calls to a WSDL service. One of the functions returns a base64binary data. I've been trying to decode it without any luck.
base64_decode($encoded_base64data) will not work. I tried using base_convert() and mv_convert_encoding() with various parameters, but could not get a proper result.
The encoded result data starts with:
��`I�%&/m�{J�J��t��`$ؐ#�������iG#)�*��eVe]f#�흼��{����{����;�N'���?\fdl��J�ɞ!���?~|?"
(the data is much longer, this is just a small portion of the string)
Any idea how it could be done?
Thanks
EDIT
I've extended the SoapClient with a new __doRequest() method to check that the received data is a proper base64 string. I got a proper base64 encoded string, and the result shown above is the decoded response.
Anyhow, the string was decoded automatically by the SoapClient from base64 to binary (as #hakre suggested), so I only have to deal with the binary response.
Now what I need is to decode the binary string into something that would look like a readable format. The final response should contain Georgian output, so I'm trying to figure out the original encoding (but that's a different question).
From base64Binary (XML Schema Part 2: Datatypes 3.2.16):
[Definition:] base64Binary represents Base64-encoded arbitrary binary data. The value space of base64Binary is the set of finite-length sequences of binary octets. For base64Binary data the entire binary stream is encoded using the Base64 Content-Transfer-Encoding defined in Section 6.8 of [RFC 2045].
You then comment:
When a WSDL has xsd:base64binary am I supposed to get a base64 response or a binary response or a base64 encoded string?
You are supposed to get a base64 encoded string. That base64 encoded string represents the binary data. If you know the XML specification, this might be more obvious because you can not pass binary information with XML, you can only pass information that fit's into XML's character-range. And that range excludes characters that are part of binary data, especially control characters and the higher pane if you divide the binary octet into a lower and higher one. See Characters (Extensible Markup Language (XML) 1.0 (Fifth Edition) 2.2) which shows that XML is about characters, not binary data. And which also shows which binary data those characters do form (and which they can not form).
Therefore the base64Binary encoding has been defined as one way to transport binary data within an XML document. So what you've got inside the raw XML response to your SOAP request is never binary but base64 encoded binary data.
Take care that your SOAP-client might already deal with this encoding and provide the data decoded.
Although previous answer is absolutely correct but I feel this may be helpful to get quick solution.
When we check in response xml then we see base64 encoded data and we try to decode it in our code to get the real data but it is not required.
Remove base64_decode.
Because SOAP client internally decode itself.
I'm coding a tool to insert test data into a database. Some of the fields are blobs which are the (mcrypt) encrypted representations of strings.
I'm creating binary variables, but can't find a way to properly output it in the format I see in PHPmyAdmin when I export (known good) data as a reference.
For example:
I used PHPmyAdmin to export a known string. It produces a value of 0xe07861bbcaf39ad54a0b85389a9f08886997f8cafffe871b8569c2fcf3293bcc in the VALUES list.
Running bin2hex on my binary field (which I've confirmed contains the same contents as known good data) results in a representation of 7a49e1b3d7c6357cab6b4f9c61bc4d8535c23cbc8789e28ce9321993e9372c80
I can't find any documentation on how to properly convert binary PHP data to the (hex) format that mySQL uses. I've read the similar questions that seem related.
How can I get from a binary field to the 0x.... value that PHPmyAdmin makes?
It's as simple as:
'0x' . bin2hex($bin)
As for the different outputs, my bet is that you are mixing up the original data.
I am using json_encode to transform my php multidimensional array to output json. Normally, this function would convert all values to strings. To make sure that integers values are send to javascript as integer values, I am using the numeric check:
$json = json_encode($data, JSON_NUMERIC_CHECK);
This works fine in all but one case for my app. In the php array (which is extracted from the database), there is one field that contains very large integers. I save it to database as a VARCHAR, but unfortunately this is converted to an integer when encoding to json. The problem is that since this is a very large integer, it gets rounded and therefore does not represent the true value. How could I tackle this problem?
Do you want the large number to be transformed to an integer? Your question leads me to believe you don't. If that's the case, remove the JSON_NUMERIC_CHECK option from the call and it shouldn't change the encoding of the field.
Documentation about this (and other) constants is here.
Maybe is to late but i did hit the same problem, and stuck on PHP 5.3 on the server because of legacy code that must be run with that version. The solution that i used is dumb, but did work for me: simple add an space character at the end of the long integer that is varchar readed from the db, and before sending it to json encode with JSON_NUMERIC_CHECK.
I'm using php 5.2. My file and db table are utf8.
when i insert a column with json_encoded data in it, it converts non-ascii chars into \u-something. ok. when i json_decode the data those \u-somethings are still there!
wasn't json_decode supposed to convert back to the normal chars when displaying on a utf8 page. For example, instead of f\u00f6tter, it should display fötter. do i have to use another function for conversion?
json_encode and json_decode are kind of weak in PHP. Both do the minimum to produce valid, but not necessarily the intended output. json_decode has no idea if \u00f6 is supposed to be ö or \u00f6. There is no way to make json_decode aggressively convert unicode characters back. Remember that JSON is designed to be directly eval'able by JavaScript, and JavaScript will evaluate those escapings.
But why are you json encoding your data to store it in MySQL?
i know this is an old question but the answer did not really answer the question for me.
eventually, i was able to get what i wanted using the JSON_UNESCAPED_UNICODE flag.
$output = json_encode($input, JSON_THROW_ON_ERROR | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
https://www.php.net/manual/en/function.json-encode.php
caveat: this only works if you are able to store utf8 in your database; you said your table is utf8 so that should be ok. i was not able to find a way to convert the \u strings back at decode time, so encoding it as unescaped utf8 is what worked for me.
also, if you're using PHP 7.1+ (your post said 5.2 but that was a long time ago) then you may want to add the JSON_UNESCAPED_LINE_TERMINATORS flag as well)