Skip to content

feat(encoding/unstable): add format option to encodeBase64 and decodeBase64 #6457

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 36 commits into from
Mar 4, 2025

Conversation

BlackAsLight
Copy link
Contributor

Related: #6451

This pull request does three things:

  1. Introduces an unstable version of encodeBase64 and decodeBase64 that merges both Base64 and Base64Url into one with the user providing a string argument to specify which encoding/decoding they want.
  2. Rewrites the underlying encoding/decoding code to introduce better memory management and performance gains.
  3. Introduces encodeRawBase64 and decodeRawBase64 which is a more low level version of the previous functions meant to enable users to encode/decode part of a buffer in place.

- Bring performance to stable packages
- Change how the Raw encoders and decoders work to encode inline in an existing buffer
- Merged Base32, Base32Hex, and Base32Crockford into one file.
- Merged Base64, and Base64Url into one file.
- Added Tests for 100% coverage.
- Added JSDocs
@BlackAsLight BlackAsLight requested a review from kt3k as a code owner March 3, 2025 00:51
Copy link

codecov bot commented Mar 3, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.90%. Comparing base (e9b8e0b) to head (093cd8b).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6457      +/-   ##
==========================================
+ Coverage   95.85%   95.90%   +0.05%     
==========================================
  Files         569      572       +3     
  Lines       42637    42831     +194     
  Branches     6400     6428      +28     
==========================================
+ Hits        40869    41078     +209     
+ Misses       1729     1720       -9     
+ Partials       39       33       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

- Improve encoding/decoding of base64 by simplifying the maths making it a 10th of a microsecond faster and improves readability.
- Reduce code and complexity to validate chars of encoded input when decoding
* assertEquals(buffer, await Deno.readFile("./deno.lock"));
* ```
*/
export function decodeRawBase64(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When do you think the users would prefer this API over decodeBase64?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only real use case for this API and the encodeRawBase64 is if you're input and output is a Uint8Array. Say you're creating a file and part of it needs to be base64 for whatever consumes it, this API lets you skip the conversion to a string and back and in the same instance use less memory.

Outside of where the encoding is embedded in other information, I doubt it would find much use.

Copy link
Member

@kt3k kt3k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kt3k
Copy link
Member

kt3k commented Mar 4, 2025

Note: This conflicts a little bit with the current convention of how to expose the variations of the same algorithm (e.g. encodeBase64 and encodeBase64Url). But this can be a better alternative way to expose such variations as we now have more and more such variations (e.g. base32/base32hex/base32crockford), and some API names look a little strange ( encodeBase32Crockford for example)

@kt3k kt3k merged commit fc167d6 into denoland:main Mar 4, 2025
18 checks passed
@BlackAsLight BlackAsLight deleted the encoding_base64_sync branch March 4, 2025 08:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants