small quick question, when I store a bytes32 and retrieve it from truffle console, why is it showing in 64 bits?

Ex: 0x74657374737472696e6700000000000000000000000000000000000000000000

because this is kinda annoying when it comes to using truffle testing framework.

assert.equal(data[1].toUpperCase(), "0x74657374737472696e6700000000000000000000000000000000000000000000".toUpperCase(), "name doesn't match");

When testing bytes32 data, I have to match an exact 64 bits hex value in order to pass. So for assert.equal's second parameter where I would enter in my predicted value, I have to manually convert a string to hex using mostly from this site, and in fact most of the string to hex sites do not show in full 64 bits. They would show it as: 74657374737472696e67.

It is annoying that I have to count the zeros and append them to match 64 bits. Are there any handy ways to handle this?


The values you're showing are 32 bytes long (256 bits), not 64 bits.

They're that length because the type is bytes32. The number 1 is different from 10, and the same holds in hexadecimal. You can't just drop the trailing zeros without changing the value.

Assuming you're always working with strings, you could use web3.toAscii... e.g. assert.toEqual(web3.toAscii(data[1]), "teststring");.

(FYI, I think in web3.js 1.0 beta, the function is web3.utils.toAscii.)

  • It turns out that it's giving an error: expected 'teststring\u0000\u0000\u0000\u0000\u0000\u0000\.............. I guess I need to find a way to get rid of \u0000s
    – bbusdriver
    Jun 21 '18 at 18:43
  • 1
    Try web3.toAscii(data[1]).replace(/\0/g, '') instead.
    – user19510
    Jun 21 '18 at 18:51
  • Thanks, worked like a charm. Do you think truffle should take this into consideration for testing? People must be testing a lot with bytes32 values.
    – bbusdriver
    Jun 21 '18 at 19:23
  • why is it showing as null(\u0000) by the way?
    – bbusdriver
    Jun 21 '18 at 19:37
  • 1
    I don't use Truffle, so I don't know if they have some other built in string<-->bytes32 comparison. If not, I suppose it would be useful, though web3.toAscii is a fine solution.
    – user19510
    Jun 21 '18 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.