You can use StringToAnsiBase64 in OCL or EAL to encode text as Base64 from Windows-1252 (ANSI) bytes when an external or legacy integration requires that byte encoding.
What it does
StringToAnsiBase64 converts a string to its Windows-1252 byte representation and returns those bytes as a Base64 string.
Base64 is a text representation of bytes. It does not preserve the original character encoding by itself: the receiving system must decode the Base64 value as Windows-1252 to recover the intended text.
Syntax
<string expression>.StringToAnsiBase64()Example
Encode an ASCII string:
'Hello World'.StringToAnsiBase64()The result is:
SGVsbG8gV29ybGQ=
When to use it
Use this operator when the receiving system explicitly requires Base64 content built from Windows-1252 bytes.
For example, if a legacy endpoint expects a Windows-1252-encoded text field as Base64, apply the operator to the value you send:
self.CustomerName.StringToAnsiBase64()Do not choose this operator only because the result is Base64. The byte encoding matters for characters outside ASCII. ASCII characters such as A, spaces, and digits have the same byte values in Windows-1252 and UTF-8, so an ASCII-only test value such as Hello World cannot demonstrate an encoding difference.
Choose the required encoding
Confirm the encoding required by the receiving system before implementing the integration.
| Requirement from the receiving system | Operator to use |
|---|---|
| Base64 created from Windows-1252 (ANSI) bytes | StringToAnsiBase64()
|
| Base64 created from UTF-8 bytes | StringToBase64 |
Use in an integration expression
- Identify the string value that the external system expects in Base64 form.
- Confirm that the system expects Windows-1252 rather than UTF-8.
- Apply
StringToAnsiBase64()to that value. - Send the returned Base64 text in the field required by the integration.
For example:
self.Description.StringToAnsiBase64()If the receiving system decodes the result using UTF-8 instead of Windows-1252, characters that differ between those encodings can be interpreted incorrectly. Agree on both Base64 and character encoding with the integration endpoint.