Funciones de encoding — Referencia de SSJS en Marketing Cloud | Cleon

El encoding aparece en todos lados donde SSJS interactúa con el mundo afuera: headers Authorization: Basic para callouts de API, parámetros de query llevando identificadores de usuario por URLs de CloudPage, payloads firmados pasados a webhooks, tokens opacos guardados en DEs. Marketing Cloud expone las cuatro operaciones que necesitás (Base64Encode, Base64Decode, URLEncode, URLDecode) directamente bajo Platform.Function. Las trampas son sobre qué encoding usar dónde, y qué pasa cuando un string sobrevive un round-trip pero no el siguiente.

Sintaxis oficial

Platform.Load("Core", "1.1.5");

// === BASE64 ===

// Encodear un string a Base64
var b64 = Platform.Function.Base64Encode("hola mundo");
// → "aG9sYSBtdW5kbw=="

// Decodear Base64 de vuelta a string
var raw = Platform.Function.Base64Decode("aG9sYSBtdW5kbw==");
// → "hola mundo"

// Patrón común: header HTTP Basic Auth
var auth = "Basic " + Platform.Function.Base64Encode("clientId:clientSecret");
// → "Basic Y2xpZW50SWQ6Y2xpZW50U2VjcmV0"

// === URL ENCODING ===

// Encodear un valor para uso seguro en una URL
var encoded = Platform.Function.URLEncode("user+name@example.com&id=12");
// → "user%2Bname%40example.com%26id%3D12"

// Decodear un valor URL-encoded de vuelta a su forma original
var decoded = Platform.Function.URLDecode("user%2Bname%40example.com");
// → "user+name@example.com"

// Patrón común: construir una URL de redirect con params del usuario
var redirect = "https://app.example.com/preferences?email="
  + Platform.Function.URLEncode(emailAddress)
  + "&token=" + Platform.Function.URLEncode(token);

// === GUID-to-Base64 (algunos tenants) ===

// Convertir un GUID a una representación Base64 compacta
var compactId = Platform.Function.GuidToBase64(Platform.Function.GUID());
// → ej. "Ks1L7Z+Y0E6XbDtF8H3iAg=="

El set soportado:

| Función | Input | Output | Usar para | |---|---|---|---| | Base64Encode(s) | String | String Base64 | Headers de auth, tokens opacos, binario-como-texto | | Base64Decode(s) | String Base64 | String | Inverso de Base64Encode | | URLEncode(s) | String | String percent-encoded | Params de query URL, URLs de redirect | | URLDecode(s) | String percent-encoded | String | Inverso de URLEncode | | GuidToBase64(guid) | String GUID | String Base64 compacto | Identificadores acortados en URLs / DEs |

Referencia:

Lo que sobrevive en producción

Base64 vs URL encoding — no son intercambiables

Este es el error conceptual que más se manda a producción. Base64 y URL encoding resuelven problemas distintos y no son sustitutos seguros uno del otro.

Base64 convierte bytes arbitrarios en un alfabeto ASCII (A-Z, a-z, 0-9, +, /, =). No hace que un string sea URL-safe — +, / y = tienen todos significado especial en query strings de URL.
URL encoding (también percent-encoding) convierte caracteres con significado en URLs (&, =, +, ?, /, etc.) en secuencias de escape %XX. No convierte binario en texto — asume que el input ya es un string imprimible.

// EN RIESGO — Base64 en una URL sin más encoding
var token = Platform.Function.Base64Encode("clientId:secret");
// → "Y2xpZW50SWQ6c2VjcmV0"  (sin chars especiales en este caso, suerte)

var url = "https://api.example.com/?token=" + token;
// Funciona para ESTE input específico, falla en el momento que el output encodeado contenga "+", "/", o "="

// SEGURO — Base64-después-URLEncode para tokens que van a URLs
var token = Platform.Function.URLEncode(
  Platform.Function.Base64Encode("clientId:secret")
);
var url = "https://api.example.com/?token=" + token;

La regla general: si va a un header HTTP, Base64 solo. Si va a un query string de URL, URL-encodealo lo que pongas ahí — incluso si ya está en Base64.

Round-trip de Base64 no siempre es lossless con whitespace + line endings

Base64 está oficialmente padded con = al final y puede incluir line breaks cada 76 caracteres en algunas implementaciones. El Base64Encode de SFMC produce una línea limpia unpadded-or-padded sin breaks; algunos sistemas externos producen output con líneas rotas que el Base64Decode de SFMC puede manejar o no. La asunción segura: cuando recibís Base64 de fuentes externas, sanitizá whitespace antes de decodear.

// EN RIESGO — Base64 externo con line breaks puede decodear a basura en algunos tenants
var raw = Platform.Function.Base64Decode(externalToken);

// SEGURO — saca el whitespace antes de decodear
var sanitized = String(externalToken).replace(/\s+/g, "");
var raw = Platform.Function.Base64Decode(sanitized);

Lo mismo aplica a padding: algunas fuentes omiten los caracteres = finales. El decoder de SFMC es generalmente lenient, pero si ves errores "Invalid Base64 string" en input que parece válido, padding es lo primero a chequear.

`URLEncode` no encodea la URL entera — solo el valor

Un bug común: pasar la URL entera a URLEncode. El resultado encodea el :// y los slashes y produce nonsense.

// BUG — encodea la URL entera, incluyendo las partes que NO deberían encodearse
var url = Platform.Function.URLEncode("https://api.example.com/?id=12");
// → "https%3A%2F%2Fapi.example.com%2F%3Fid%3D12"
// Inútil como URL — no navega, no fetchea

// CORRECTO — encodeá solo los valores, construí la URL alrededor
var id = "12";
var url = "https://api.example.com/?id=" + Platform.Function.URLEncode(id);
// → "https://api.example.com/?id=12"

// Múltiples params
var url = "https://api.example.com/?email=" + Platform.Function.URLEncode(email)
        + "&id=" + Platform.Function.URLEncode(id)
        + "&action=" + Platform.Function.URLEncode(action);

El modelo mental: URLEncode es para valores, no para URLs.

URL-encodeá valores del usuario antes de la concatenación

Saltearse URLEncode en input del usuario es un vector de XSS / link-injection, no solo un issue de correctness. Un valor malicioso conteniendo &action=delete podría cambiar el significado de la URL si se pega en crudo.

// EN RIESGO — parámetro 'next' del usuario pegado en crudo
var next = Request.GetQueryStringParameter("next");
var redirect = "/done?next=" + next;
// Si next es "anything&injected=value", agregaste un param inyectado

// SEGURO — encodeá el valor
var redirect = "/done?next=" + Platform.Function.URLEncode(next);

Incluso cuando el valor viene de una fuente confiable (un campo de DE que escribiste vos), URL-encodealo a la salida. El costo es una llamada de función por valor; el ahorro es no tener que auditar cada code path que produjo el valor.

Decisión rápida

Usá Base64Encode cuando:

Construís un header HTTP Authorization: Basic (el uso canónico).
Guardás o transmitís un token opaco donde el receptor también habla Base64.
Reducís un string multi-line a una línea para storage en un solo campo de DE.

Usá URLEncode cuando:

Ponés cualquier valor en un query string de URL. Siempre.
Construís URLs de redirect con parámetros del usuario.
Construís hyperlinks programáticamente en SSJS de CloudPage o contenido de email.

Combiná Base64Encode después URLEncode cuando:

Un token Base64 tiene que viajar por una URL. El orden importa — encodeá a Base64 primero, después URL-encodea el resultado.

Usá GuidToBase64 cuando:

Querés un identificador compacto (22 chars vs 36 para un GUID con guiones) para URLs o storage. Reverteilo con Base64ToGuid si está disponible en tu tenant.

No uses estos cuando:

El valor ya está en el encoding correcto para su destino. El doble encoding produce sopa de secuencias de escape que nadie decodea correctamente.

Relacionado

Basics — superficie de lenguaje soportada
Platform.Function — el namespace donde estos helpers viven
Funciones de string — para stringificación antes de encodear
WSProxy — los tokens de auth seguido involucran Base64 (ej. para Basic auth en integraciones SOAP legacy)
MC SSJS gotchas — ver #9 (callouts HTTP) para el contexto más amplio de auth-y-encoding

Próximas páginas de referencia SSJS: Hashing · Util / Variable · Style Guide.

Más snippets how-to para patrones comunes de producción — DE add/update/upsert, manejo de errores, paginación de callouts, etc.