I bought some NFTs using cardano-cli commands, and some of them were minted with special characters, or spaces " " and now I just cannot send it for my main wallet. I get errors like
I already tried to convert to base16 but it returns “An error occured while decoding asset name exceeds 32 bytes”
1.31.0 cardano-cli, but when I try to pass the assetName base16 encoded, it returns longer than 32 bytes, because cardano-cli tries to convert to base16 again
because I already converted the assetName to base16, but internally it already do it, so it tries to converty the base16 code that im passing to base16 again, and it turns into a big code.
yes it is 1.31.0
its not done by me, like the print i posted before, the code that exceeds 32 byts is the result of encoding what is already coded by me.
You never posted your tries with encoding, just your tries with plaintext, which will not work for 1.31.0+, because it wants base16/hex encoding and not with 1.30.1-, because there are non-ASCII characters and spaces.
So, I just tried at with an asset name with a non-ASCII character and a space in it:
There is no double encoding with recent versions of cardano-cli, not even when using the old build-raw, calculate-min-fee, build-raw again way of doing it.
Still think that either you pick up an old version of cardano-cli somehow. (Do you use it from a script? Does that script have another $PATH than your usual shell? Does it maybe have the full path to an old version of cardano-cli hard-coded?)
Or you are somehow doing the base16 twice yourself, before giving it to cardano-cli. (Do you store the unencoded asset name in the same variable as the encoded one later on and have the encoding double in your process? Do you do it with $(echo $assetname | xxd -p) or something like that in the call to cardano-cli, although $assetname already contains the encoded version?)