En utilisant le codage ASCII, combien de caractères composent un GUID ?
Je m'intéresse au style Microsoft, qui inclut les accolades et les tirets.
En utilisant le codage ASCII, combien de caractères composent un GUID ?
Je m'intéresse au style Microsoft, qui inclut les accolades et les tirets.
De MSDN:
Un GUID est une valeur de 128 bits composée d'un groupe de 8 chiffres hexadécimaux, suivi de trois groupes de 4 chiffres hexadécimaux chacun, suivi de un groupe de 12 chiffres hexadécimaux. L'exemple de GUID suivant montre les regroupements de chiffres hexadécimaux dans un GUID : 6B29FC40-CA47-1067-B31D-00DD010662DA
De Wikipedia:
Souvent, des accolades sont ajoutées pour encadrer le format ci-dessus, comme ceci :
{3F2504E0-4F89-11D3-9A0C-0305E82C3301}
Donc un total de 38 caractères dans l'encodage hexadécimal typique avec des accolades.
-Adam
@magnifico -- voir le dernier paragraphe de cette réponse : "Donc un total de 38 caractères dans l'encodage hexadécimal typique avec des accolades."
Pas besoin de se battre avec magnifico - il a posé la question, il décide qui a donné la réponse la plus pertinente. Il a ses raisons de préférer l'autre réponse à celle-ci, j'en suis sûr.
@Beska parce que c'est pour cela que Stack Overflow a été créé. Au lieu de donner un poisson à une personne, donnez le même poisson à un million de personnes.
Comme l'a déclaré Adam Davis, le style Microsoft est l'encodage HEX (avec des accolades et des tirets pour le rendre plus lisible) qui peut être affiché en utilisant un sous-ensemble de caractères ASCII (0-9 et A-F), mais ce n'est pas spécifiquement un encodage ASCII.
Je suppose qu'il est important de se souvenir que le style microsoft d'affichage des GUID n'est qu'une représentation d'un GUID, qui est en réalité une valeur intégrale de 16 octets (comme l'a indiqué Micheal Trausch).
Vous pouvez également le présenter de différentes manières plus compactes en convertissant les octets dans un jeu de caractères différent (comme ASCII).
Théoriquement, vous pourriez afficher chaque octet en tant que caractère ASCII étendu (255 caractères), ce qui vous permettrait d'enregistrer un GUID sous forme de chaîne de 16 caractères de longueur.
Cela n'aurait pas beaucoup de lisibilité car il inclurait des caractères d'espacement (CR, espace, tabulation, etc) et d'autres caractères spéciaux, donc cela n'aurait de sens que si vous voulez enregistrer efficacement un GUID dans un format de caractères non lisible par les humains, par exemple dans une base de données qui ne prend pas nativement en charge les GUID ou l'appariement rapide de petites valeurs binaires : http://en.wikipedia.org/wiki/Extended_ASCII
À mon avis, le moyen le plus lisible d'afficher un GUID de manière plus compacte serait d'utiliser l'encodage Base64, ce qui vous permet de le sauvegarder dans une chaîne de 22 caractères, et cela ressemblerait à ceci :
7v26IM9P2kmVepd7ZxuXyQ==
Mais comme le dit Jeff Atwood sur son site, vous pouvez également insérer un GUID dans une chaîne encodée en ASCII85 avec 20 caractères :
[Rb*hlkkXVW+q4s(YSF0
Pour plus d'inspiration, voir : http://www.codinghorror.com/blog/2005/10/equipping-our-ascii-armor.html
Si seulement cette réponse avait un grand et gras "Aucun" en haut pour attirer les lecteurs et agir comme un TL; DR. ;)
Comme Adam l'a mentionné dans la citation de MSDN, les UUID sont des valeurs de 128 bits. Cela signifie qu'ils prennent 16 octets de RAM pour contenir une valeur. Une représentation textuelle prendra 32 octets (deux octets pour chaque octet unique), plus les 4 tirets, plus les deux crochets si vous souhaitez les inclure; cela représente 38 octets.
N'oubliez pas que si vous exposez des UUID aux utilisateurs de votre logiciel, ils peuvent fournir l'UUID avec ou sans les crochets. Si vous stockez la valeur quelque part, il est préférable de la stocker sous forme de représentation binaire de 16 octets. Si vous interopérez avec d'autres implémentations d'UUID, vous voudrez peut-être utiliser le format texte de base pour l'interopérabilité, car différentes implémentations font des choses différentes pour l'ordre des octets lors de la sauvegarde d'une valeur UUID binaire.
La longueur dépend de l'encodage. Vous pouvez obtenir l'encodage standard et la longueur avec ce extrait de code:
public void Main()
{
var guid = Guid.Empty;
Write(guid, "N"); // 32 caractères
Write(guid, "D"); // 36 caractères (par défaut)
Write(guid, "B"); // 38 caractères
Write(guid, "P"); // 38 caractères
Write(guid, "X"); // 68 caractères
}
private void Write(Guid guid, string format)
{
var guidString = guid.ToString(format);
Console.WriteLine("{0}: {1} ({2} caractères)", format, guidString, guidString.Length);
}
Consultez la méthode Guid.ToString pour plus de détails:
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
2 votes
Ils ont tous exactement la même longueur. Si vous comptez les caractères dans l'un, vous saurez la longueur de tous.
1 votes
@Greg - C'est une supposition très pauvre à faire, à moins que vous ne compreniez que la longueur ne variera pas.
8 votes
Si la longueur variait, alors cette question serait semblable à demander : "quelle est la longueur d'un morceau de ficelle ?" Au lieu de cela, c'est demander "combien y a-t-il d'œufs dans une douzaine ?"
8 votes
Lorsque j'ai googlé cette question, chaque réponse pointait simplement vers une définition d'un guid. Descendez-moi si vous voulez, mais je cherche juste à rendre la réponse à cette question spécifique plus facile à trouver, sans compter nécessaire pour les futurs demandeurs.
2 votes
Je comprends ce que vous dites, mais si quelqu'un vient de découvrir NewDataX, la question de la longueur est valable, et vous ne pouvez pas supposer que ce que vous avez vu exemplifie chaque autre NewDataX jusqu'à ce que vous compreniez ce qu'est un NewDataX.
0 votes
Je ne vois pas où quelqu'un a mentionné quelque chose appelé "NewDataX".