TiddlyWiki5/editions/tw5.com/tiddlers/filters/decodebase64 Operator.tid

caption: decodebase64
op-input: a [[selection of titles|Title Selection]]
op-output: the input with base 64 decoding applied
op-suffix: optional: `binary` to produce binary output, `urlsafe` for URL-safe input
op-parameter: 
op-parameter-name: 
op-purpose: apply base 64 decoding to a string
tags: [[Filter Operators]] [[String Operators]]
title: decodebase64 Operator
type: text/vnd.tiddlywiki
from-version: 5.2.6

See Mozilla Developer Network for details of [[base 64 encoding|https://developer.mozilla.org/en-US/docs/Glossary/Base64]]. TiddlyWiki uses [[library code from @nijikokun|https://gist.github.com/Nijikokun/5192472]] to handle the conversion.

The input strings must be base64 encoded. The output strings are the text (or binary data) decoded from base64 format.

The optional `binary` suffix, if present, changes how the input is processed. The input is normally assumed to be [[UTF-8|https://developer.mozilla.org/en-US/docs/Glossary/UTF-8]] text encoded in base64 form (such as what the <<.op "encodebase64">> operator produces), so only certain byte sequences in the input are valid. If the input is binary data encoded in base64 format (such as an image, audio file, video file, etc.), then use the optional `binary` suffix, which will allow all byte sequences. Note that the output will then be binary, ''not'' text, and should probably not be passed into further filter operators.

The optional `urlsafe` suffix, if present, causes the decoder to assume that the base64 input uses `-` and `_` instead of `+` and `/` for the 62nd and 63rd characters of the base64 "alphabet", which is usually referred to as "URL-safe base64" or "bae64url".

<<.operator-examples "decodebase64">>
Add encodebase64/decodebase64 operators Proposed by @ericshulman 2023-02-02 09:55:54 +00:00			`caption: decodebase64`
			`op-input: a [[selection of titles\|Title Selection]]`
			`op-output: the input with base 64 decoding applied`
Fix encodebase64 and decodebase64 filters (#7683) * Fix encodebase64 and decodebase64 filters The documentation for encodebase64 says that the input is treated as binary data, but in fact the input is being treated as text data, with an extra UTF-8 encoding step being performed first. Likewise, the decodebase64 documentation says that it outputs binary data, but in fact it will do a UTF-8 decoding step before producing output, which will in fact garble binary data. This commit changes the behavior of encodebase64 and decodebase64 to match what the documentation says they do. It also adds an optional `text` suffix to both filters to keep the current behavior. Finally, an optional `urlsafe` suffix is added to both filters to allow them to use the "URL-safe" variant of base64 (using `-` instead of `+` and `_` instead of `/`). * Try to fix failing test Turns out a little more than this is going to be needed. * Fix binary base64 encoding, including unit tests * Update base64 filter documentation * Can't use replaceAll, too new Have to use String.replace with a global regex instead * Replace uses of window.btoa() in rest of code Since window.btoa() is not available under Node.js, we'll replace all uses of it with the $tw.utils.base64encode() function that now works correctly for binary data. * Add link to UTF-8 glossary definition at MDN 2023-10-18 15:08:56 +00:00			op-suffix: optional: `binary` to produce binary output, `urlsafe` for URL-safe input
Add encodebase64/decodebase64 operators Proposed by @ericshulman 2023-02-02 09:55:54 +00:00			`op-parameter:`
			`op-parameter-name:`
			`op-purpose: apply base 64 decoding to a string`
			`tags: [[Filter Operators]] [[String Operators]]`
			`title: decodebase64 Operator`
			`type: text/vnd.tiddlywiki`
			`from-version: 5.2.6`

			`See Mozilla Developer Network for details of [[base 64 encoding\|https://developer.mozilla.org/en-US/docs/Glossary/Base64]]. TiddlyWiki uses [[library code from @nijikokun\|https://gist.github.com/Nijikokun/5192472]] to handle the conversion.`

Fix encodebase64 and decodebase64 filters (#7683) * Fix encodebase64 and decodebase64 filters The documentation for encodebase64 says that the input is treated as binary data, but in fact the input is being treated as text data, with an extra UTF-8 encoding step being performed first. Likewise, the decodebase64 documentation says that it outputs binary data, but in fact it will do a UTF-8 decoding step before producing output, which will in fact garble binary data. This commit changes the behavior of encodebase64 and decodebase64 to match what the documentation says they do. It also adds an optional `text` suffix to both filters to keep the current behavior. Finally, an optional `urlsafe` suffix is added to both filters to allow them to use the "URL-safe" variant of base64 (using `-` instead of `+` and `_` instead of `/`). * Try to fix failing test Turns out a little more than this is going to be needed. * Fix binary base64 encoding, including unit tests * Update base64 filter documentation * Can't use replaceAll, too new Have to use String.replace with a global regex instead * Replace uses of window.btoa() in rest of code Since window.btoa() is not available under Node.js, we'll replace all uses of it with the $tw.utils.base64encode() function that now works correctly for binary data. * Add link to UTF-8 glossary definition at MDN 2023-10-18 15:08:56 +00:00			`The input strings must be base64 encoded. The output strings are the text (or binary data) decoded from base64 format.`

			The optional `binary` suffix, if present, changes how the input is processed. The input is normally assumed to be [[UTF-8\|https://developer.mozilla.org/en-US/docs/Glossary/UTF-8]] text encoded in base64 form (such as what the <<.op "encodebase64">> operator produces), so only certain byte sequences in the input are valid. If the input is binary data encoded in base64 format (such as an image, audio file, video file, etc.), then use the optional `binary` suffix, which will allow all byte sequences. Note that the output will then be binary, ''not'' text, and should probably not be passed into further filter operators.

			The optional `urlsafe` suffix, if present, causes the decoder to assume that the base64 input uses `-` and `_` instead of `+` and `/` for the 62nd and 63rd characters of the base64 "alphabet", which is usually referred to as "URL-safe base64" or "bae64url".
Add encodebase64/decodebase64 operators Proposed by @ericshulman 2023-02-02 09:55:54 +00:00
			`<<.operator-examples "decodebase64">>`