ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/website/docs/configuration/functions/textdecodebase64.html.md

42 lines
1.5 KiB
Markdown
Raw Normal View History

lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
---
website: Adopt a ton of pages into the "language" layout As of this commit, that layout doesn't exist yet, but I'm isolating the one-line changes to their own commit to try and keep your eyes from glazing over.
2020-08-15 03:51:06 +02:00
layout: "language"
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
page_title: "textdecodebase64 - Functions - Configuration Language"
sidebar_current: "docs-funcs-encoding-textdecodebase64"
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
description: |-
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
The textdecodebase64 function decodes a string that was previously Base64-encoded,
website: fix malformed yaml in a few function pages
2020-12-02 22:51:29 +01:00
and then interprets the result as characters in a specified character encoding.
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
---
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
# `textdecodebase64` Function
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
-> **Note:** This function is supported only in Terraform v0.14 and later.
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
`textdecodebase64` function decodes a string that was previously Base64-encoded,
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
and then interprets the result as characters in a specified character encoding.
Terraform uses the "standard" Base64 alphabet as defined in
[RFC 4648 section 4](https://tools.ietf.org/html/rfc4648#section-4).
The `encoding_name` argument must contain one of the encoding names or aliases
recorded in
[the IANA character encoding registry](https://www.iana.org/assignments/character-sets/character-sets.xhtml).
Terraform supports only a subset of the registered encodings, and the encoding
support may vary between Terraform versions.
Terraform accepts the encoding name `UTF-8`, which will produce the same result
as [`base64decode`](./base64decode.html).
## Examples
```
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
> textdecodebase64("SABlAGwAbABvACAAVwBvAHIAbABkAA==", "UTF-16LE")
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
Hello World
```
## Related Functions
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
* [`textencodebase64`](./textencodebase64.html) performs the opposite operation,
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
applying target encoding and then Base64 to a string.
* [`base64decode`](./base64decode.html) is effectively a shorthand for
lang/funcs: Rename the base64 character encoding functions These were initially introduced as functions with "encode" and "decode" prefixes, but that doesn't match with our existing convention of putting the encoding format first so that the encode and decode functions will group together in a alphabetically-ordered function list. "text" is not really a defined serialization format, but it's a short word that hopefully represents well enough what these functions are aiming to encode and decode, while being consistent with existing functions like jsonencode/jsondecode, yamlencode/yamldecode, etc. The "base64" at the end here is less convincing because there is precedent for that modifier to appear both at the beginning and the end in our existing function names. I chose to put it at the end here because that seems to be our emergent convention for situations where the base64 encoding is a sort of secondary modifier alongside the primary purpose of the function, as we see with "filebase64". (base64gzip is an exception here, but it seems outvoted by the others.)
2020-10-21 19:56:56 +02:00
`textdecodebase64` where the character encoding is fixed as `UTF-8`.