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.
Related
I have a fairly big (Around 50bytes) structure in a Embedded device to be transported to a PHP script which is to be stored in a DB. Most of the elements in the structure are bits and some are integers and chars.
What I plan is use a union in C (Embedded Device) to take the data as a binary array and do a base64 encoding and upload through a URL string as a variable.
Now In php I have a big array which needs to be sepertaed as flags and integers to be store in DB.
This is my task. which will be the suitable method to do the work.
Thanks
If you send as binary, then you will have to decide on and enforce byte order at each end regardless of platform byte order. Enforce network byte order by using the POSIX byte order conversion functions.
Also you cannot rely on compiler generated structure bit-fields to pack and unpack identically on both platforms so for the bit fields you must use shifting-and-masking to pack and unpack and to be careful of bitfields that span byte or word boundaries.
A more easily portable solution perhaps is to transfer using a structured text format such as XML or JSON, or a proprietary format of your own design if these are too verbose.
Structures created in C you can decode in php using unpack() function.
I was wondering if there would be some way to compress a small ASCII string (~100 characters) by combining some of the native PHP compression and base converting functions to produce an even smaller string (`~60 characters).
For example, could I take a string, gzcompress it, convert it to a number, and then change the base to a system with more values?
The goal is to have a smaller string that is ASCII (perhaps UTF-8) compatible for display.
You could try a dictionary compression like lzw or a golomb code but the compression depends on the data. Without the exact data it's not possible to answer the question.
base64_encode(gzcompress($input));
That should do it, but I don't think this will make your original string much smaller.
http://php.net/manual/en/function.base64-encode.php
http://php.net/manual/en/function.gzcompress.php
The whole point of designating data as binary is to simply treat the binary sequence as a raw, untouched sequence of bytes.
=> Given that MySQL has BLOB, BINARY and VARBINARY data types, why isn't it possible to store and retrieve any arbitrary binary stream of data from a php script without having the need to escape the sequence with mysql_real_escape_string or addslashes?
Because binary data are still serialized to a string… So, for example, imagine your $binary_data had the value a 'b" c. Then the query INSERT INTO foo VALUES $binary_data would fail.
The whole point of designating data as binary is to simply treat the binary sequence as a raw, untouched sequence of bytes.
you are wrong.
the only point of designating data as binary is just to mark it to be not a subject of character set recoding. that's all.
why isn't it possible to store and retrieve any arbitrary binary stream of data from a php script without having the need to escape the sequence with mysql_real_escape_string or addslashes?
who said it's impossible?
it's quite possible, both to store and retrieve.
The whole point of prepared statements is to send an arbitrary binary stream directly to mysql.
Why is it necessary to add escape sequences to a binary string when storing to a MySQL Database?
If you are talking of SQL, you have to understand what it is first.
SQL is a programming language.
And as any language has it's own syntax to follow.
And if you're going to add your raw binary data to this program, you have to make this data satisfy these rules. That's what escaping for.
What would be the best way to compact a string in PHP that can be decoded to its original form. The base64_encode works for numbers but it yields a longer result for strings that contain special characters.
Gzencode and gzdecode use the GZIP compression algorithm and are very efficient on plain text strings. Just be aware that the output may (will) contain binary characters not suitable for display and possibly not suitable for database storage either.
(Edit: singe gzdecode doesn't ship with PHP, consider gzdeflate and gzinflate. Gzdeflate compresses a string and gzinflate decompresses it.)
Take your pick: Compression and Archive Extensions
well of course a base64-encoding makes a string longer as it is mapping all possible bytes onto a smaller set of numbers and alphabetic chars.
I guess convert_uuencode wouldn't increase the size of your binary string as much as base64 b/c the target set is larger.
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