Yo aconsejaría contra una correspondencia 1-1:
Con base 64 codificación que sólo va a ser capaz de disminuir la entrada (4/8)/(6/8) -> 4/6 ~ 66% en tamaño (y esto es asumiendo que lidie con los personajes base "feos" de 64 sin agregar nada nuevo).
Probablemente consideraría un método de búsqueda (secundario) para obtener valores verdaderamente "bonitos". Una vez que haya establecido este método alternativo, elija cómo generar valores en ese rango, p. Números aleatorios: pueden estar libres del valor hash de origen (porque la correspondencia se pierde de todos modos) y se puede usar un conjunto de objetivos arbitrario "bonito", quizás [a-z] [A-Z] [0-9].
Puede convertir a la base (62 arriba) simplemente siguiendo el método de división y transporte y una búsqueda en una matriz. Debería ser un pequeño ejercicio divertido.
Nota: Si elige el número aleatorio de [0, 62^5), obtendrá un valor que empacará por completo la salida codificada (y se ajustará dentro de los valores enteros de 32 bits). A continuación, puede realizar este proceso varias veces seguidas para obtener un buen valor de resultado múltiple de-5, como xxxxxyyyyyzzzzzz (donde x, y, z son grupos diferentes y el valor total está en el rango (62^5)^3 -> 62^15 -> "un enorme valor")
Editar, para hacer comentarios:
Debido sin la correspondencia 1-1 usted puede hacer cosas bonitas verdaderamente cortos - tal vez como "pequeña "como 8 caracteres de largo - con base62, 8 caracteres pueden almacenar hasta 218340105584896 valores, que es probable más de lo que alguna vez necesitará. ¡O incluso 6 caracteres que "solo" permiten el almacenamiento de 56800235584 valores diferentes! (Y aún no puedes almacenar ese número en un entero simple de 32 bits :-) Si bajas a 5 caracteres, una vez más reduces el espacio (a poco menos de mil millones: 916,132,832), pero ahora tienes algo que puede encajar en un entero de 32 bits con signo (aunque es algo derrochador).
La base de datos debe garantizar que no haya duplicados, aunque un índice en este valor se "fragmentará rápidamente" con una fuente aleatoria (pero puede usar contadores o lo que sea). Un PRNG bien distribuido debe tener conflictos mínimos (léase: reintentos) en un rango lo suficientemente grande (suponiendo que mantenga la semilla en funcionamiento y no la restablezca, o reiníciela adecuadamente) - Super 7 incluso puede garantizar NO duplicados durante un ciclo (de solo ~ 32k), pero como puede ver arriba, el espacio de destino sigue siendo grande. Consulte los cálculos en la parte superior de lo que requiere mantener una relación 1-1 en términos de tamaño mínimo codificado.
El método de dividir y transportar simplemente explica cómo obtener su número fuente en una base diferente, tal vez base62. El mismo método general se puede aplicar para pasar de la base "natural" (base10 en PHP) a cualquier base.
Con base 64 codificación que sólo va a ser capaz de disminuir la entrada (4/8)/(6/8) -> 4/6 ~ 66% en el tamaño (y esto es asumiendo que trates con los personajes "feos" de base64 sin agregar nada nuevo). Probablemente consideraría un método de búsqueda (secundario) para obtener valores realmente "bonitos". –
Re "Así que supongo que querré algo que no se convierta directamente de hexágono a base 62". - Si desea codificar 16 bytes en una cadena segura para URL, mi respuesta a continuación (22 caracteres) es probablemente lo mejor que obtendrá. ¿Qué estás realmente tratando de lograr? – dkamins