ll.StringToBase64 doesn't accept arbitrary SLua strings
complete
Frionil Fang
It terminates on the first zero byte as I expected but hoped it wouldn't, so this is mostly a request for expansion to allow Base64 functions (and other relevant string functions) to work on strings with 0s in them.
Just a simple demo:
local buf = buffer.create(1024)
local i
for i=0,1023,4 do
buffer.writeu32(buf, i, i)
end
local s = buffer.tostring(buf)
local b = ll.StringToBase64(s)
ll.OwnerSay(`original buffer-string length: {string.len(s)}, base64: {string.len(b)}`)
The result is 1024 and 0, i.e. the base64 function stopped on the first 0.
Log In
H
Harold Linden
complete
ll.*Base64*()
functions are staying the same for compatibility with LSL, but we've rolled out llbase64.encode()
and llbase64.decode()
to replace them for native SLua scripts. llbase64.decode()
also accepts a second optional boolean argument to decode directly to a buffer
rather than a string
.Please file a new Canny if there are any issues with those!
H
Harold Linden
inĀ progress
We ended up re-prioritizing this one due to the need to store binary data in JSON without weird hacks.
We've got a simple API like
local buf = buffer.create(4)
local expected_encoded = 'AQD/AA=='
buffer.writeu8(buf, 0, 0x1)
buffer.writeu8(buf, 2, 0xff)
local buf_string = buffer.tostring(buf)
assert(llbase64.encode(buf) == expected_encoded)
assert(llbase64.encode(buf_string) == expected_encoded)
assert(llbase64.decode(expected_encoded) == buf_string)
That'll probably go out next week with the JSON changes unless there are any objections.
Base64ToInteger
and XorBase64Strings
equivalents aren't present, since they're less relevant now that scripters have access to buffer
s.H
Harold Linden
Forgot to mention, there's also an optional second boolean arg like
llbase64.decode(some_b64_str, true)
so you can decode directly to a buffer
rather than a string
if you want. That should reduce pointless allocations when you're just going to create a buffer from the return anyway.Frionil Fang
Harold Linden
That certainly sounds very useful! Binary strings and buffers have lots of utility, this removes any complications from sending or storing them in linkset data.
Signal Linden
closed
This is expected for the moment, as that's also how LSL behaves. We're planning to make SLua-only alternatives that don't use the existing binding layer, since that's the place where those NULLs get truncated.