My purpose in moving to base 32 string encoding is so I can cram more information into the 63 bytes of an event.

I can now answer my own question. On the server side I am using these javascript procedures to do the encoding/decoding:

- value.toString(32)
- parseInt( value, 32 )

In Wiring I use these procedures to do the same thing:

```
String numToString32( long value )
{
String answer = "";
if( value == 0 )
answer = "0";
else
{
boolean negative = ( value < 0 );
if( negative)
value = - value;
while( value > 0 )
{
int remainder = (int) ( value % 32 ); //(value - ( value / 32 ) );
value = value / 32;
char theChar = theAlphabet.charAt( remainder );
answer = theChar + answer;
}
if( negative)
answer = "-" + answer;
}
return answer;
}
long string32ToNum( String value )
{
long answer = 0;
boolean negative = false;
unsigned int i = 0;
for( ; i < value.length(); i++ )
{
char theChar = value.charAt(i);
if( theChar == '-' )
negative = true;
// Strip of any preceding minus signs or preceding zeros
if( ( theChar != '-' ) && theChar != '0' )
break;
}
for( ; i < value.length(); i++ )
{
char theChar = value.charAt(i);
answer = answer*32 + theAlphabet.indexOf(theChar);
}
if( negative )
answer = - answer;
return answer;
}
```

Iâ€™ve compared the results of the above procedures against the standard Java / Javascript functions using â€śround-tripâ€ť test cases on a handful of values (positive, negative and zero). Iâ€™ve also tested the parsing of strings left-padded with â€ś0â€ť. Iâ€™m using it on my Core and server, and all seems to work with round-trip messaging. Lightly tested so far but looking good.

If I discover any bugs Iâ€™ll update this post.