I am passing a lot of data between PHP and JavaScript. I am using JSON and json_encode in php, but the problem here is that I am passing a lot of numbers stored as strings - for example, numbers like 1.2345.
Is there a way to pass the data directly as numbers (floats, integers) and not have to convert it to ASCII and then back?
Thanks,
No. HTTP is a byte stream protocol(*); anything that goes down it has to be packed into bytes. You can certainly use a more compact packed binary representation of values if you like, but it's going to be much more work for your PHP to encode and your JS to decode.
Anyhow, for the common case of small numbers, text representations tend to be very efficient. Your example 1.2345 is actually smaller as a string (6 bytes) than a double-precision float (8 bytes).
JSON was invented precisely to allow non-string types to be transferred over the HTTP connection. It's as seamless as you're going to get. Is there any good reason to care that there was a serialise->string->parse step between the PHP float and the JavaScript Number?
(* exposed to JavaScript as a character protocol, since JS has no byte datatype. By setting the charset of the JSON response to iso-8859-1 you can make it work as if it were pure bytes, but the default utf-8 is usually more suitable.)
If you didn't want to use JSON, there are other encoding options. The data returned from an HTTP request is an octect stream (and not 7-bit clean ASCII stream -- if it were, there would be no way to server UTF-8 encoded documents or binary files, as simple counter examples).
Some binary serialization/data protocols are ASN.1, Thrift, Google Protocol Buffers, Avro, or, of course, some custom format. The advantage of JSON is "unified human-readable simplicity".
But in the end -- JSON is JSON.
Perhaps of interest to someone: JavaScript Protocol Buffer Implementation
Related
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.
This question already has answers here:
What is base 64 encoding used for?
(19 answers)
Closed 8 years ago.
Hi my question is that does base64_encode does unique data every time we run the script?
Below is the code.
<?php
$id = 1;
echo base64_encode($id);
?>
If it does not provide the unique data every time then what is the point in encoding the string and passing in url. Does that make url safe??
Base64 encoding is not a method of encryption. It is used for encoding binary data into text, which makes it safer to transmit over the internet.
If you stream bits, some protocols may interpret it differently. Streaming text is much more reliable.
What is base 64 encoding used for?
If you need true encryption, you need to use something which hashes based on a salt you can hide from other users, such as the mcrypt library.
http://php.net/manual/en/book.mcrypt.php
base64-encoding does not provide unique data. Its purpose is to provide a compact representation of binary data in string form. In your example, you are encoding non-binary data, so it is not very practical. However, if you wanted to encode a string containing a newline and punctuation and pass it via the URL, you cannot send the binary data directly.
For example, if you had the string Hello, World!!\n there would be three punctuation marks, a space and a newline that all need to be URL-encoded. Doing that gives the result:
Hello%2C+World%21%21%0A
Which is 23 bytes long.
On the other hand if you were to base64-encode the same string, the result would be:
SGVsbG8sIFdvcmxkISEK
Which is 20 characters, or about 13% shorter. This adds up quickly if you've got a lot of non-alphanumeric characters or a large amount of data.
So the primary advantage of base64 encoding is its slightly more compact representation of certain data.
Base64 encoding is a way of representing data using only a limited set of characters. You use it when you need to store data in something such as a cookie that can't handle the data in its original format.
Base64 only uses 6 bits per character (2^6 = 64) to create textual data from image files. This causes an in-efficiency.
According to a wikipedia entry on Base64, this in-efficiency is to protect against 8 bit dirty things like email.
Is Ajax Posting 8 bit clean? If so, is there an alternative to using Base64?
php.net ( as does wikipedia ) claims a 33% in-efficiency for base64_encode..
Kind of. All JavaScript strings are UTF-16, not byte strings. If you're sending the data with send, then it will be encoded into UTF-8 before it is sent. As such, you can convert the bytes into Unicode code points, which will then be encoded into UTF-8. When it reaches the server, you'll have to decode the UTF-8 and then convert the code points back into bytes.
For 7-bit data, this will not expand the size of the data at all. For 8-bit data with the most significant bit always set, it will double the size of the data. For 8-bit data with the most significant bit set half of the time, it will increase the size of your data by 50%, which is worse than the Base64 33.3͞% increase.
On the other hand, using XMLHttpRequest Level 2 will allows you to send binary data by passing send an ArrayBuffer, Blob, or FormData. However, XMLHttpRequest Level 2 is only supported in newer browsers.
I think AJAX posting is the same as a generic POST requests in that aspect; that's why we need 'multipart/form-data' for sending files' content, for example. Usually the data gets url encoded, but Base64 is perhaps a better way, as it's (generally) more efficient.
UPDATE: It might be helpful to look at this the other way. ) You need some stream of values, that might possibly take all 8 bits, to safely pass the 7-bit filtering. The perfect solution is to use '7-to-8' encoding, so each 7 bytes become 8 'safe' characters. But this is not applicable, as some of these 7-bit characters are actually used to specify some additional (meta) information about the stream...
Now you have a dilemma: either use the next integer (6 bit - that is base64) - or try to invent a scheme with 'non-integer' divider. Such schemes exist (check Ascii85, for example), but they are rarely used.
People know all about storing binary data in database server as BLOBs. How would one accomplish the same thing in PHP?
In other words, how do i store blobs in a php variable?
As PHP doesn't have Unicode support you can safely use normal strings as binary storage. Most (all?) functions are null-safe, too, so you shouldn't get any problems because of that either.
PS: Theoretically you could prefix all binary strings with b (e.g. b'binary data'). This is a forward compatability token to make sure that strings that expect to be handled as binary will really be handled so even than Unicode support is available.
Easy - store it in a string. You can use all the normal string functions (strlen, substr, etc) - just remember that the PHP string functions work in single byte units, e.g. substr($binstr, 0, 1) gives you the first 8 bits of $binstr
Maybe as an array of bytes. After all binary data is nothing more.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the use of base 64 encoding?
I've seen many code fragments that base64 encode images before transmitting over HTTP protocol.
I am wondering why do we need it?
It's not necessary, but it enables you to embed images without performing additional HTTP requests (where, in some cases, it's not possible or permitted).
From the Wikipedia entry on Base64:
The term Base64 refers to a specific
MIME content transfer encoding. It is
also used as a generic term for any
similar encoding scheme that encodes
binary data by treating it numerically
and translating it into a base 64
representation. The particular choice
of base is due to the history of
character set encoding: one can choose
a set of 64 characters that is both
part of the subset common to most
encodings, and also printable. This
combination leaves the data unlikely
to be modified in transit through
systems, such as email, which were
traditionally not 8-bit clean.
And specifically regarding HTTP:
Base64 encoding can be helpful when
fairly lengthy identifying information
is used in an HTTP environment. For
example, a database persistence
framework for Java objects might use
Base64 encoding to encode a relatively
large unique id (generally 128-bit
UUIDs) into a string for use as an
HTTP parameter in HTTP forms or HTTP
GET URLs. Also, many applications need
to encode binary data in a way that is
convenient for inclusion in URLs,
including in hidden web form fields,
and Base64 is a convenient encoding to
render them in not only a compact way,
but in a relatively unreadable one
when trying to obscure the nature of
data from a casual human observer.
The HTTP protocol isn't guaranteed to be "8 bit clean", so it might mangle a binary stream.