2010-02-14 14 views
9

GUID es un gran número aleatorio mostrar en una base HEX. Quiero mostrar este número en un formato más corto, digamos que basado en todas las letras y números. Eso es una base 36.Mostrar un GUID en formato de 36 letras

Digamos que: 2f1e4fc0-81fd-11da-9156-00036a0f876a se convertirá en 3jEl9x6eZi.

¿Hay algún algoritmo 'listo' para esto en .Net?

tiene que ser bidireccional.

Editar: usando Base64 es una solución aún mejor. El único problema es que Base64 contiene / char que no es compatible con el uso en URI.

+0

Para la base 64, se puede sustituir caracteres no válidos con los válidos (pero no están siendo utilizados). IIRC, hay un poco menos de 96 caracteres ASCII imprimibles. – Steve314

+0

Mire mi respuesta para ver cómo resolví el número ==,/y + – Fredou

Respuesta

1

base 64 es lo que yo uso, se this solucionar el problema con == y/e +

2

No es posible, ya que lo presentó. Tendría que perder información:

>>> 16 ** len('2f1e4fc081fd11da915600036a0f876a') 
340282366920938463463374607431768211456 
>>> 36 ** len('3jEl9x6eZi') 
3656158440062976 

Necesitará muchos más dígitos base 36 para cubrir todos los valores posibles. ¿Por qué no usar la base 64 en su lugar? El resultado sería más corto (y estoy asumiendo que este es el objetivo aquí) y hay una solución estándar para eso en .NET.

+0

El valor '3jEl9x6eZi' es solo por ejemplo, y no es un valor 'real'. –

0

Creo que lo más cercano que encontrará es Base36, pero no funcionará con un tipo GIUD (solo un Int16, Int32 o Int64).

8

No hay nada incorporado para tal conversión. Algo cercano que se construye en base 64 está utilizando codificación:

string base64 = Convert.ToBase64String(theGuid.ToByteArray()) 
+0

Buena solución. Pero, ¿por qué cada cadena termina con '=='? '=' no es un valor válido en formato Base64. –

+2

@Mendy: El carácter = se usa para completar el último grupo de caracteres. (Está especificado en el estándar RFC 1421). – Guffa