You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that this library has the same problem as the Tuupola Base62 encoder in that it is intolerant of corruption - even a single bit error will destroy the entire output. This is not true of PHP's built-in base64 encoders.
To be fair, this is an edge case, but URLs cannot always relied on to remain intact - for example it's common for email clients to truncate them, and if this happens, the URL will always break completely if it used this encoder.
I suspect it fails for exactly the same reason - the encoding treats the entire string as single arbitrary precision number, and so it results in the corruption we see. If the encoder used a chunk based approach (which is especially appropriate for base62 since it does not fit evenly into 8-bit chars), it would not suffer this fragility.
I've noticed that this library has the same problem as the Tuupola Base62 encoder in that it is intolerant of corruption - even a single bit error will destroy the entire output. This is not true of PHP's built-in base64 encoders.
To be fair, this is an edge case, but URLs cannot always relied on to remain intact - for example it's common for email clients to truncate them, and if this happens, the URL will always break completely if it used this encoder.
I suspect it fails for exactly the same reason - the encoding treats the entire string as single arbitrary precision number, and so it results in the corruption we see. If the encoder used a chunk based approach (which is especially appropriate for base62 since it does not fit evenly into 8-bit chars), it would not suffer this fragility.
Steps to reproduce, backtrace or example script
Example output:
The text was updated successfully, but these errors were encountered: