zamicol / baseconverter Goto Github PK

I am using the base converter to convert hexadecimal strings into alphanumeric ones, but if the hex string starts with a zero, the leading zero gets dropped during the conversion process resulting in the output string being non-reversible due to the same output string generating both with and without the leading zero. In addition, this only seems to occur when running the code in NodeJS and not in the web browser where the zero magically appears in the reversal process despite the two different strings resulting in the same output. My parameters to re-produce the issue are as follows:
Input alphabet: 0123456789abcdef
Input string: 090e5c14c2237ecbc906879d50ae1b12
Output alphabet: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

The resulting output string both with and without the leading zero in the input string: H5UaOom3uXr7KMPbuIFHe

UPDATE: I just tried this with a different input alphabet and string, and I was able to trigger the bug there too. This seems to occur whenever both the input alphabet and string begin with 0, so for example the following parameters will also trigger it:
Input alphabet: 01234abc
Input string: 0143ac4cb213411abcbbac
Output alphabet: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

Error in app.js:

function FullBuckets() {
var inputBase = document.getElementById("inputAlphabet").value.length;
var outputBase = document.getElementById("outputAlphabet").value.length;

inBits = bitPerBase(inputBase);
outBits = bitPerBase(outputBase);

document.getElementById("inputBitsNeeded") = inBits;
document.getElementById("outputBitsNeeded") = outBits;

}
Correction :
document.getElementById("inputBitsNeeded").value = inBits;
document.getElementById("outputBitsNeeded").value = outBits;

Show the byte representation of strings as an array.

For example:
[234 11 119 58 102 1 16 49 206 13 15 82 81 207 42 218 106 38 34 124 58 25 31 70 79 240 21 55 96 211 103 149]

Input: Text
Output: URI_Escaped

Should be reversible.

Input: URI_Escaped
Output: Text

Probably as an extra mode. Look at U+0336, "long stroke overlay". Example base85:

0̶1̶2̶3̶4̶5̶6̶7̶8̶9̶A̶B̶C̶D̶E̶F̶G̶H̶I̶J̶K̶L̶M̶N̶O̶P̶Q̶R̶S̶T̶U̶V̶W̶X̶Y̶Z̶a̶b̶c̶d̶e̶f̶g̶h̶i̶j̶k̶l̶m̶n̶o̶p̶q̶r̶s̶t̶u̶v̶w̶x̶y̶z̶!̶#̶$̶%̶&̶(̶)̶*̶+̶-̶;̶<̶=̶>̶?̶@̶^̶_̶`̶{̶|̶}̶~̶

Perhaps show waste.

Currently padding characters are ignored.

It would be nice to be able to encode with padding with something like "padding character" text area.

If the text area is blank, assume no padding. If it is populated, encode with padding as appropriate.

Put in strings and get unique characters according to input base.

Probably needs to use a big int library.

https://convert.zamicol.com/?inAlph=DND%3A20&in=2020202020202020202020202020202020&outAlph=01

For example, Base84 is 84 characters. How many bits per character?

84 = 2^x

x=log_2 (84)

x ~= 6.39

This can be displayed as a fraction, 6.39/7.

Thank you for writing this useful code. I was wondering if you'd be able to add a license so that potentially I could make use of the code in my own project?

Cheers

i've tried using unary(for fun) in https://rot47.net/base.html and although it was only 12(base10) to unary... it froze my browser and had to close it
then i saw your site in your discus post and i really liked it... and i though of trying unary on yours as well, but chose not to...
but i then accidentally miss-selected all the characters in base input and pressed on 1, SO the good news is that it didn't crash, the ""bad"" are that it did nothing, could you add an unary option with a character output limit? id say 1080 maximum should be enough as a default, but if the user wants to change it he could at his own risk, what do you think?
and of course way to use a custom "1" for the unary base wouldn't be remiss
as for the second part of the title, i kind of wanted to try it with 𝍲𝍳𝍴𝍵𝍶(the kanji ideographic tally marks), but besides the facts that i've just noticed now while writing this issue that it would have problems because there is no 0 and that the way it should be converted into would be 1="1", 2="2", 3="3", 4="4", 5="5", 6="51", 7="52", etc etc... isn't supported, the problem the title refers to is that for characters 𐀀 to 􏿽(and i suppose 10FFFE and 10FFFF as well but those shouldn't be used) it seems to be using the unicode-16 surrogate characters https://en.wikipedia.org/wiki/Universal_Character_Set_characters#Surrogates and that is an obvious problem
and while im asking for the tally output method(yeah, im doing that as well) do you think you could add one for 𝍷𝍸(fence tally marks) as well? the way they work is 1="1", 2="11", 3="111", 4="1111", 5="5", 6="51", etc etc... with 𝍷="1" and 𝍸="5, also when they encoded these in unicode it seems they though it would be better to make it so that "2", "3" and "4" should be handle at the font level using multiple 𝍷, so you'll see how to best handle that in the output(and perhaps even the input)...... and obviously a way to use custom characters for those tally ones as well
thanks in advance.
edit: ps, i've noticed that you can output bizarre stuff like 0123454321 and it's converted correctly, i like it please don't remove it, either say in the page(and code) that is something that can be done although its somewhat rather pointless and leave it, or put it behind a "for fun" option that is by default off(and has the explanation of what it does on a widget), thanks again.
edit 2:and i just thought of something, perhaps you could make it so that if either the input or output fields see " ##"(a space followed by two hastags) at the end(so "0123456789 ##") the converter interprets that as "hold on, there might be a parameter i have to listen for there" so say stuff like ##paddingchar="#" or ##tallymark , what do you think?

Support multiple alphabets, inputs, and outputs.

Map alphabets 1:1 with inputs and outputs.

Bijective numeration

Space, tab, new line, carriage return on input.

random:256
Only permitted on in.
In button in extras section.
New random is generated only by button in extras.