My little Lua module for Base64 encode/decode :)

[blog...@gmail.com]

This is code :) You can scold if something is wrong hehe.

Everything seems to be working correctly.

git clone https://gitflic.ru/project/blogdron/lua-base64.git

But README in non english language just ignore it :D

there is a description of the API it is in English

In directory 5_1 module for lua5.1 luajit and lua5.2

In directory 5_3 module for lua5.3 and 5.4

You can simply copy the appropriate file to your project

You can use other base64 alphabet for encode/decode

makefile for instalation on debian like operation systems.

support PREFIX and DESTDIR for custom packaging/instalation

I use bit operations for conversion.

Maybe it will be useful for someone :)

I just noticed that people sometimes share their developments here

Got the courage to share. Bye everyone

[Sainan]

The 'variants' is quite interesting because you list RFC 4648 as a variant, but only implement section 4 of it, but this document also describes "base64url" in section 5.

-- Sainan

[blog...@gmail.com]

>but only implement section 4 of it, but this document also describes "base64url" in section 5.

I started writing the module by looking at Wikipedia =) I looked into RFC4648 itself later, then I saw a whole bunch of different RFCs, each of which said that we had a modification of aofavit, then they showed me that there are still different ones. I didn’t dare to cover everything. Therefore, I limited myself to only a base of 64-character alphabet, and since they are somewhat different, I added RFC4648 by default plus the ability to specify a different alphabet, the data for encoding is generated later. Simply put, this is basic base64 with the possibility of slight variability. As far as I understand, Base 64 Encoding with URL differs only in replacing the character in the alphabet, you can specify any alphabet, as long as it has 64 characters and it will be used for encoding and decoding. To implement section 5, you only need to change 1 character in the alphabet. By default, I have what is in section 4, any other option will need to be specified, I did not embed all the options into the code, this will make it bloat, instead you can simply pass any of your alphabet and the program will generate the necessary data for encoding. It seemed to me that doing this would be more correct, simpler and more flexible. The default is the standard alphabet, otherwise you need to specify explicitly. in the description I listed the different alphabets that I could find, there are probably more of them, in any case it’s just 64 any characters.

Maybe it’s worth adding the second alphabet as a ready-made one straight into the code... I don’t know yet. In any case, you can specify what you need manually. It is necessary to clarify that by default there is only 1 encoding/decoding option, and everything else must be indicated explicitly in any case. I'll think about it, thanks for the note

среда, 24 июля 2024 г. в 16:54:13 UTC+3, Sainan:

[blog...@gmail.com]

For example

local basename = 'base64URLencode' -- for realisation section 5 RFC4848

local alphabet = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_'
local endcode  = '='
assert(base64.register(basename,alphabet,endcode))
local base = base64.encode("Hello World!","mybase64")

среда, 24 июля 2024 г. в 17:13:14 UTC+3, blog...@gmail.com:

[blog...@gmail.com]

Ohhh sorry

-local base = base64.encode("Hello World!","mybase64")

+local base = base64.encode("Hello World!","base64URLencode")

среда, 24 июля 2024 г. в 17:19:52 UTC+3, blog...@gmail.com:

[Sainan]

base64url also has no padding, so no '=' at the end. You might have to check if your decoder can handle that.

-- Sainan

[blog...@gmail.com]

>base64url also has no padding, so no '=' at the end. You might have to check if your decoder can handle that.

Hmm. i look this

 * https://datatracker.ietf.org/doc/html/rfc4648#section-5

   Table 2: The "URL and Filename safe" Base 64 Alphabet

(pad) =

Maybe I'm confused :(

I'll try to find the data and double-check, but in any case you just need to indicate the required alphabet and the required ending and everything should just work since technically there is no difference. In any case, thanks for another clarification.

среда, 24 июля 2024 г. в 17:28:16 UTC+3, Sainan:

[Sainan]

Well, if padding is used depends on the application, but despite what the standard says, it is not required for correct decoding either way, and the typical usage of base64url is with padding disabled.

-- Sainan

[blog...@gmail.com]

>Well, if padding is used depends on the application, but despite what the standard says, it is not required for correct decoding either way, and the typical usage of base64url is with padding disabled.

In this case, this character will be ignored. But there is a possibility that some client will look for this character to find the end of the data without decoding. Therefore, it can be left. But! if this character is simply not needed, clearly not needed, instead you can simply specify the end of the line or an empty line and the usual behavior will be. Simply put, which characters of the alphabet will be indicated by such encoding and will be, what ending is indicated or not indicated, whether it will be like this or not. In your proposed case, you can set

 local endcode='' 

or

local endcode='\0'

depending on what you want and need, and that's all :)

This is the whole point of being able to set your own encoding format, the main thing is that it technically matches the base format, only the data changes, the code works the same way.

But I will still carry out various tests in search of problems that may not be obvious to me, until I have found them :)

среда, 24 июля 2024 г. в 17:42:56 UTC+3, Sainan:

[blog...@gmail.com]

The only note to myself is that I seem to have misunderstood you right away. You probably meant that since RFC4648 specifies two alphabets, the module should at least recognize which base64 it is without specifying it explicitly. Yes, this seems logical. But there is one thing, but in order to set the correct alphabet you need to detect certain characters that differ in different alphabets and only for decoding set the desired alphabet and generate the necessary things for it inside the program and only then start the encoding/decoding process. Yes, but it's all expensive. When we encode and decode data, we always know what and how we are doing; if it’s just text, then we use one thing, if it’s a link, then we use something else. It seems to me that forcing the encoding recognition into the code itself will not be very good, since the desired character may be very far away in the data and this will waste time. Maybe I'm wrong, but there is only 1 canonical version of base64 and its standard alphabet. Everything else is variations and deviations and they can and should be indicated explicitly. Something like this. This is an acceptable compromise in my opinion ^.^

среда, 24 июля 2024 г. в 17:53:46 UTC+3, blog...@gmail.com: