NEW dec2bin() and bin2dec() functions

[lunter2]

Description

Since the pack() function does not support variable (minimum) length encodings, I would like to propose two useful functions for direct implementation in PHP.

Currently, you have to use a combination of:

• dechex() -> hex2bin() with odd/even length check
• bin2hex() -> hexdec()

which is not optimal for performance.

<?
 function dec2bin($dec){
  $hex=dechex($dec);
  if(strlen($hex)%2===1){ // is an odd length
   $hex='0'.$hex;
  }
  $bin=hex2bin($hex); // $hex must have an even length
  return $bin;
 }

 function bin2dec($bin){
  $hex=bin2hex($bin);
  $dec=hexdec($hex);
  return $dec;
 }

 $dec=random_int(0,1000);
 $bin=dec2bin($dec);
 $new_dec=bin2dec($bin);

 print($new_dec===$dec?'OK':'ERROR'); // test
?>

[damianwadley]

This doesn't really make sense to me...

What is the purpose of these functions? Are they any different from chr and ord?

[lunter2]

chr and ord only work on single byte (numbers from 0 to 255).

The idea is to work on any unsigned integers like existing decbin and bindec function (which unfortunately inputs/returns a zero-one string, and not binary data).

Another solution to this problem would be to add a second parameter to decbin and bindec - bool $binary = false,
how it is done in hash or sha1, etc...

---

Unless there is some native function that works like this:
fn(300) => in chr(1).chr(44)
and
fn(70000) => chr(1).chr(17).chr(112)

...and vice versa.

[damianwadley]

The idea is to work on any unsigned integers like existing decbin and bindec function

Except unsigned (64-bit) integers only support strings up to 8 bytes long. Any longer than that and the number becomes a float, which will be useless for this sort of thing.

The reason that hex2bin/bin2hex exist is because (1) a hex representation of the bytes of a string is a relatively common need, and (2) both are strings and so allow a (nearly) unlimited number of bytes.

Are you thinking of a function that deals with Unicode code points? Currently it goes up to U+10FFFF, which is easily within the range of even a 32-bit signed integer. The problem with a sort of "Unicode ord() and chr() functions" is string encoding - PHP doesn't have "wide" strings, so characters above U+00FF must necessarily be encoded into multiple bytes, but that raises the question of which encoding to use... In other words, there's no simple solution for Unicode like there is for plain ASCII's 0x00-0x7F (or even -0xFF) range.

(which unfortunately inputs/returns a zero-one string, and not binary data)

Because those functions are for numeric "base conversion" - decbin converts a number from base 10 to a number in base 2, and bindec does the reverse. Similarly dechex/hexdec use bases 10 and 16, and decoct/octdec use bases 10 and 8. (And the numbers in a base other than 10 obviously must be represented as strings.)

Another solution to this problem would be to add a second parameter to decbin and bindec - bool $binary = false,
how it is done in hash or sha1, etc...

Putting aside that how the hashing functions are a completely different situation, a "decbin that outputs binary strings" has the same problems as above: limited range of a 64-bit unsigned integer and the required choice of a character encoding.

---

After your edit, it seems you are talking about base conversion after all:

Unless there is some native function that works like this: fn(300) => in chr(1).chr(44) and fn(70000) => chr(1).chr(17).chr(112)

...and vice versa.

It may not be obvious to you but that is a very specialized transformation process. By which I mostly mean that it's one that doesn't correspond to any character encoding scheme I'm aware of. It's essentially a numeric conversion between base 10 and base 256.
(edit: Also, this makes an implicit assumption of big-endian encoding.)

Honestly, I don't think it's a common enough use case that PHP should have some out-of-the-box function to do it. Does it serve any purpose outside of... what do you need this for, by the way?

My instinct says that this behavior should be implemented using pack(). And it's not hard. https://3v4l.org/aTmc0
The reverse would NUL-pad the input to 8 bytes and unpack().

[lunter2]

what do you need this for, by the way?

For serialization and deserialization of integers written as:

• the first byte specifies the length of the encoded data
• the next bytes are the encoded value

If I have a value 1, it encodes as: chr(1).chr(1)
If I have a value 256, it encodes as: chr(2).chr(1).chr(0)

This is used, for example, in BER/CER/DER encoding in ASN.1
Which is very popular and common encoding.
All certificates, openssl keys etc.

---

It's essentially a numeric conversion between base 10 and base 256.

Yes, that's exactly what's missing.

---

I understand everything you write, but I miss fast functions that will serialize and deserialize integers of variable length of binary representation.
Pack function works on fixed sizes (predetermined in first argument) (with leading zeros in returns).

[damianwadley]

So I'm reading through this page and I'm spotting a problem: 128-255 does not serialize as a single byte (beside the length). Because if it did serialize as \x80-\xFF, the MSB would be set and the value interpreted as a negative number. Which means even if PHP did provide a sort of "base 10 to base 256" conversion, you wouldn't be able to use it...

No offense, but have you considered using a library for this instead of writing it yourself? A quick search turned up sop/asn1 and FreeDSx/ASN1.

[lunter2]

I'm spotting a problem: 128-255

I may have given a bad example.
I mainly use this to write/read the length of a stored value.

https://luca.ntop.org/Teaching/Appunti/asn1.html

3.1 Primitive, definite-length method
Long form. Two to 127 octets. Bit 8 of first octet has value "1" and bits 7-1 give the number of additional length octets. Second and following octets give the length, base 256, most significant digit first.

That this: base 256, most significant digit first

My functions presented in the first post do this very well, but a bit roundabout (by going through the hex form).

---

FreeDSx/ASN1 might be interesting, but...

But I wrote a functions to serialize and deserialize BER. Total only 0.5kB of code.

This can convert BER to PHP array and back. The result is binary identical to the source, but you can also edit the array before serialization.

Something like json_decode and json_encode for JSON.

---

Maybe we could add a second parameter to the existing dechex function:
bool even = false
to force (if true) the returned value to always be of even length (which would provide compatibility with the hex2bin function input).

[cmb69]

gmp_export() and gmp_import() may serve as relevant building blocks for what you want to accomplish. Their documentation needs improvement, but see e.g. https://3v4l.org/SOEY1.

And pack()/unpack() might be suitable as well.

[cmb69]

Would gmp_export()/gmp_import() work for you, @lunter2?