Difference between revisions of "Talk:Text To Byte Conversion"
| Line 7: | Line 7: | ||
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) | 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) | |||
Revision as of 16:12, 5 January 2008
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)