Difference between revisions of "Talk:Text To Byte Conversion"

From Second Life Wiki
Jump to navigation Jump to search
(New page: 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 th...)
 
 
(14 intermediate revisions by 5 users not shown)
Line 1: Line 1:
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. -- [[User:Strife Onizuka|Strife Onizuka]] 09:58, 3 January 2008 (PST)
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. -- [[User:Strife Onizuka|Strife Onizuka]] 09:58, 3 January 2008 (PST)
:Take a look here [[Combined Library#Encoding]] -- [[User:Strife Onizuka|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. --[[User:Dedric Mauriac|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). -- [[User:Strife Onizuka|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. --[[User:Dedric Mauriac|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. -- [[User:Strife Onizuka|Strife Onizuka]] 16:12, 5 January 2008 (PST)
:See ReadBase64Byte and WriteBase64Byte. -- [[User:Strife Onizuka|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) --[[User:TigroSpottystripes Katsu|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. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 23:41, 18 October 2009 (UTC)
::I've change the code yet again, this time it should work. I've abandonded the three byte method as we need to search for nulls in the input list. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 04:53, 6 January 2010 (UTC)
== broken ==
Script copied & pasted from page yeilds
Object: 72, 101, 108, 108, 111, 44, 32, 65, 118, 97, 116, 97, 114, 33
Object: HAeAlAlAoA,A AAAvAaAtAaArA!A
Object: 84, 111, 117, 99, 104, 101, 100, 46
Object: TAoAuAcAhAeAdA.A
[[User:Trinity Dejavu|Trinity Dejavu]] 15:44, 2 December 2013 (PST)
:Try it now, there was a typo. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 23:10, 2 December 2013 (PST)

Latest revision as of 23:10, 2 December 2013

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)
I've change the code yet again, this time it should work. I've abandonded the three byte method as we need to search for nulls in the input list. -- Strife (talk|contribs) 04:53, 6 January 2010 (UTC)

broken

Script copied & pasted from page yeilds

Object: 72, 101, 108, 108, 111, 44, 32, 65, 118, 97, 116, 97, 114, 33
Object: HAeAlAlAoA,A AAAvAaAtAaArA!A
Object: 84, 111, 117, 99, 104, 101, 100, 46
Object: TAoAuAcAhAeAdA.A

Trinity Dejavu 15:44, 2 December 2013 (PST)

Try it now, there was a typo. -- Strife (talk|contribs) 23:10, 2 December 2013 (PST)