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

52 lines
2.0 KiB
Markdown
Raw Normal View History

lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
---
layout: "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
page_title: "textencodebase64 - Functions - Configuration Language"
sidebar_current: "docs-funcs-encoding-textencodebase64"
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 textencodebase64 function encodes the unicode characters in a given string using a
specified character encoding, returning the result base64 encoded.
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
# `textencodebase64` 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
`textencodebase64` encodes the unicode characters in a given string using a
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
specified character encoding, returning the result base64 encoded because
Terraform language strings are always sequences of unicode characters.
```hcl
substr(string, encoding_name)
```
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. In particular Terraform supports
`UTF-16LE`, which is the native character encoding for the Windows API and
therefore sometimes expected by Windows-originated software such as PowerShell.
Terraform also accepts the encoding name `UTF-8`, which will produce the same
result as [`base64encode`](./base64encode.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
> textencodebase64("Hello World", "UTF-16LE")
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
SABlAGwAbABvACAAVwBvAHIAbABkAA==
```
## 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
* [`textdecodebase64`](./textdecodebase64.html) performs the opposite operation,
lang/funcs: Functions for encoding text in specific character encodings
2020-07-03 14:01:40 +02:00
decoding Base64 data and interpreting it as a particular character encoding.
* [`base64encode`](./base64encode.html) applies Base64 encoding of the UTF-8
encoding of a string.
* [`filebase64`](./filebase64.html) reads a file from the local filesystem
and returns its raw bytes with Base64 encoding, without creating an
intermediate Unicode string.