Talk:Text To Byte Conversion

These two functions are going to be very slow and they have a large memory footprint. This is what llBase64ToInteger and llIntegerToBase64 are good for. Suppose it's time I post some of the new functions to the Combined Library. -- Strife Onizuka 09:58, 3 January 2008 (PST)

Take a look here Combined Library#Encoding -- Strife Onizuka 10:40, 3 January 2008 (PST)

Thanks. I changed the code to use the llBase64ToInteger and llIntegerToBase64 methods. It is a lot smaller and easier to manage now. --Dedric Mauriac 01:36, 5 January 2008 (PST)

Looks good, still a few spots that could be optimized. I should point out that the resulting list will require about 9 to 10 times more memory then the string (which is why my functions work with base64, only a 4/3's expansion). A 2k strings would result in a list that would eat all the memory, even a 1k string would be dangerous, not good. This is why I haven't made a function that does byte to list myself (the only reason I have base64&hex <-> dword-list functions is so I can handle encryption keys expressed as lists). -- Strife Onizuka 02:00, 5 January 2008 (PST)

Yes, that was my next step to work with blocks of the base64 string rather than convert the whole thing back and forth to a list. I'm still having a few problems with the conversion in that an extra byte of 0 is added onto the end depending on the length of the string. It's messing with my encryption. --Dedric Mauriac 02:13, 5 January 2008 (PST)

Yeah I've had that problem too. My solution thus far (which is less then optimal) is to strip off the extra A's and then read an extra integer off the end but ignore it if it's zero. I'll post some byte based functions to my combined library. -- Strife Onizuka 16:12, 5 January 2008 (PST)

See ReadBase64Byte and WriteBase64Byte. -- Strife Onizuka 16:26, 5 January 2008 (PST)

bug?

With the string "a\na▒a" the output is

Object: 97, 10, 97, 226, 150, 146, 97, 0, 155
Object: a
a▒a??

I'm not sure what interpret from that (I feel like I really should be in bed sleeping right now) --TigroSpottystripes Katsu 08:08, 18 October 2009 (UTC)

Yeah there is a bug. It's caused by it working in 3 byte chunks at a time. I've modified the code so it now removes the extra bytes & characters. I'd appreciate it if you could test it. -- Strife ^{(talk|contribs)} 23:41, 18 October 2009 (UTC)

The code doesn't seem to work correctly:

       llOwnerSay(llList2CSV(text2bytes("a")));
       llOwnerSay(llList2CSV(text2bytes("ab")));
       llOwnerSay(llList2CSV(text2bytes("abc")));
       llOwnerSay(llList2CSV(text2bytes("abcd")));
       llOwnerSay(llList2CSV(text2bytes("abcde")));
       
       llOwnerSay(bytes2text([97]));
       llOwnerSay(bytes2text([97, 98]));
       llOwnerSay(bytes2text([97, 98, 99]));
       llOwnerSay(bytes2text([97, 98, 99, 100]));
       llOwnerSay(bytes2text([97, 98, 99, 100, 101]));

Produces:

[12:36] OAuth: 97 [12:36] OAuth: 97, 98 [12:36] OAuth: 97, 98, 99 [12:36] OAuth: 97, 98, 99, 100 [12:36] OAuth: 97, 98, 99, 100, 101

[12:36] OAuth: a? [12:36] OAuth: a [12:36] OAuth: abc [12:36] OAuth: abc [12:36] OAuth: abcd

Any idea how to fix this? Babbage Linden 20:48, 5 January 2010 (UTC)