Pasar cadenas codificadas base64 en URL

Hay especificaciones base64 adicionales. (Vea la tabla aquí para detalles). Pero esencialmente necesitas 65 caracteres para codificar: 26 minúsculas + 26 mayúsculas + 10 dígitos = 62.

Necesitas dos más [ ' + ' ,'/'] y un relleno char '='. Pero ninguno de ellos es amigable con la url, así que solo usa diferentes caracteres para ellos y listo. Los estándares de la tabla de arriba son ['-', '_'], pero podría usar otros caracteres siempre y cuando los decodificara de la misma manera, y no necesitara compartirlos con otros.

Yo recomendaría simplemente escribir sus propios ayudantes. Como estos de los comentarios en la página de manual de php para base64_encode :

function base64_url_encode($input) {
 return strtr(base64_encode($input), '+/=', '._-');
}

function base64_url_decode($input) {
 return base64_decode(strtr($input, '._-', '+/='));
}

@joeshmo O en lugar de escribir una función auxiliar, podría simplemente codificar urlencode la cadena codificada en base64. Esto haría exactamente lo mismo que su función de ayuda, pero sin la necesidad de dos funciones adicionales.

$str = 'Some String';

$encoded = urlencode( base64_encode( $str ) );
$decoded = base64_decode( urldecode( $encoded ) );

Nota introductoria Me inclino a publicar algunas aclaraciones ya que algunas de las respuestas aquí eran un poco engañosas (si no incorrectas).

La respuesta es NO , no puede simplemente pasar un parámetro codificado base64 dentro de una cadena de consulta URL ya que los signos más se convierten en un ESPACIO dentro de la matriz global $_GET. En otras palabras, si enviaste prueba.php?myVar = stringwith + sign to

//test.php
print $_GET['myVar'];

El resultado sería be:
stringwith sign

La manera fácil de resolver esto es simplemente urlencode() su cadena base64 antes de agregarla a la cadena de consulta para escapar de los caracteres+, = y / a los códigos%##. Por ejemplo, urlencode("stringwith+sign") devuelve stringwith%2Bsign

Cuando procesa la acción, PHP se encarga de decodificar la cadena de consulta automáticamente cuando rellena el archivo global _GET global. Por ejemplo, si envío prueba.php?myVar = stringwith%2Bsign a

//test.php
print $_GET['myVar'];

El resultado sería:
stringwith+sign

Lo haces no quiere urldecode() la cadena returned _GET devuelta como +'s se convertirá en espacios.
En otras palabras, si enviara la misma prueba .php?myVar = stringwith%2Bsign a

//test.php
$string = urldecode($_GET['myVar']);
print $string;

El resultado es un inesperado:
stringwith sign

Sería seguro rawurldecode() la entrada, sin embargo, sería redundante, y por tanto innecesaria.

Sí y no.

El conjunto de caracteres básico de base64 puede en algunos casos colisionar con las convenciones tradicionales utilizadas en las URL. Pero muchas de las implementaciones de base64 le permiten cambiar el conjunto de caracteres para que coincida mejor con las URL o incluso vienen con una (como la de Python urlsafe_b64encode()).

Otro problema que puede estar enfrentando es el límite de longitud de URL o más bien la falta de dicho límite. Debido a que los estándares no especifican ninguna longitud máxima, navegadores, servidores, bibliotecas y otro software que funciona con HTTP el protocolo puede definir sus propios límites. Puede echar un vistazo a este artículo: WWW FAQs: ¿Cuál es la longitud máxima de una URL?

Es una codificación base64url que puedes probar, es solo una extensión del código de joeshmo anterior.

function base64url_encode($data) {
return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
}

function base64url_decode($data) {
return base64_decode(str_pad(strtr($data, '-_', '+/'), strlen($data) % 4, '=', STR_PAD_RIGHT));
}

No creo que esto sea seguro porque, por ejemplo, el carácter "=" se usa en raw base 64 y también se usa para diferenciar los parámetros de los valores en un HTTP GET.

En teoría, sí, siempre y cuando no exceda la longitud máxima de la url y/oor cadena de consulta para el cliente o servidor.

En la práctica, las cosas pueden ponerse un poco más complicadas. Por ejemplo, puede activar una HttpRequestValidationException en ASP.NET si el valor pasa a contener un " on "y se deja en el final"==".

Sí, siempre es seguro. por supuesto base64 contiene: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/= pero una cadena codificada en base64 normalmente no tiene +. + se convertirá en un espacio en blanco, lo que resultará en una cadena descodificada incorrecta. / es seguro en un par de parámetros get. = siempre está al final de la cadena codificada en base64 y el lado del servidor puede resolver = directamente.