C# chaîne de raccourcissement pour l'URL

Question

Je veux raccourcir de façon unique les ids de fichiers-chaînes à utiliser dans les URL comme celles sur bit.ly, etc. Je peux utiliser les ID d'une base de données mais je veux que les URL soient aléatoires.

quelle serait la meilleure solution?

site sera un site mobile donc je veux à la plus courte possible

Answer 1

Vous ne pouvez pas « réduire de façon unique » des chaînes arbitraires. Principe du pigeonnier et tout. Ce que vous voulez faire (et, AFAIK ce que font les services de raccourcissement d'url faire) est de garder une base de données de tout soumis, et la chaîne courte utilisée. Ensuite, vous pouvez le rechercher dans la base de données.

Vous pouvez générer les chaînes courtes en incrémentant simplement un nombre et en l'encodant en Base64 à chaque fois.

Answer 2

stockez une chaîne alphanumérique aléatoire et utilisez-la pour votre URL courte. faites-en la longueur que vous pensez être la meilleure pour votre site et ses utilisateurs quelque chose comme www.yoursite.com/d8f3

Answer 3

Vous pouvez utiliser un hachage (par exemple CRC32) pour produire des URL assez courtes. Vous ne serez jamais en mesure d'obtenir des URL «uniques» lorsque vous réduisez les données. Il doit donc y avoir des collisions.

Answer 4

Il existe deux méthodes pour implémenter un service de mappage tel que celui que vous décrivez.

1. Les clients soumettent globalement ids uniques ou
2. Server génère globalement ids uniques

clients soumettent globalement ids uniques

Pour autant que je sache, 1. ne devrait être tentée avec Guid s, à moins que vous ne conceviez un moyen similaire pour entasser des informations suffisamment distinctes dans un court flux d'octets. De toute façon, si vous avez un flux d'octets qui représentent un identificateur global unique, vous pouvez faire quelque chose comme ça

// source is either a Guid, or some other globally unique byte stream 
byte[] bytes = Guid.NewGuid().ToByteArray(); 
string base64String = Convert.ToBase64String (bytes).Trim ("="); 

pour obtenir une chaîne lisible par l'utilisateur de caractères alphanumériques qui apparaît au hasard, mais évite les collisions inhérentes à d'autres au hasard régimes. Un Guid contient 16 octets ou 128 bits, ce qui correspond à environ 19 caractères pour un codage Base64 complet.

L'avantage de cette approche est que les clients peuvent générer leur propre Uris minuscule sans autorité centrale. L'inconvénient est la bonne longueur si vous roulez avec Guid, ou l'implémentation de votre propre flux d'octets unique au monde qui - avouons-le - est sujet aux erreurs.

Si vous suivez cet itinéraire, pensez à Google en ajoutant des flux d'octets uniques au monde. Oh, et Restez à l'écart des octets aléatoires, sinon vous devrez construire la résolution de collision sur le dessus de votre petit générateur Uri.

Server génère globalement ids uniques

Encore une fois, le principal avantage de ce qui précède est que peut générer du client leur Uris un priori. Particulièrement pratique si vous êtes sur le point de soumettre une demande de longue durée que vous souhaitez vérifier. Cela peut ne pas être particulièrement pertinent pour votre situation et peut ne fournir qu'une valeur limitée. Donc, à part cela, une approche centrée sur le serveur, dans laquelle une seule autorité génère et distribue des identifiants, peut être plus attrayante. Si c'est la route que vous choisissez, la seule question est combien de temps voulez-vous votre Uri? En supposant une longueur désirée de 5 caractères, et disons que vous allez avec un encodage Base64, chaque identifiant peut représenter jusqu'à 5 caractères par 7 bits par caractère soit 35 bits ou 2^35 [34 359 738 368] valeurs distinctes . C'est un domaine assez large. *

Ensuite, il devient question de renvoyer une valeur pour une soumission donnée. Il y a probablement un grand nombre de façons de le faire, mais je voudrais aller avec quelque chose comme ça,

• Énumérer toutes les valeurs possibles dans une « liste libre » dans votre base de données
• valeur Supprimer de la liste libre lorsqu'ils sont consommés
• Ajouter une valeur à la liste libre lorsqu'il est libéré

Améliorations ou optimisations peuvent inclure

• Ne pas énumérer toutes les valeurs de la plage [0, 2^35], énumérer plutôt un sous-ensemble gérable, disons 100 000 valeurs à la fois, et quand toutes les valeurs sont consommées, générer simplement 100 000 autres valeurs et continuer
• Ajouter une date d'expiration aux valeurs et recycler les valeurs expiré fin de la journée
• distribuez votre service lorsque parallélisation votre service tout simplement distribuer des petits sous-ensembles mutuellement exclusifs de votre liste libre aux services distribués

Conclusion

Le résultat est, vous voulez guara l'unicité de ntee - donc les collisions sont un grand non-non.

---

* = 34 359 738 368 est la taille du domaine brut, tout cela est ids de 0 à 5 longueur longueur. Si vous êtes intéressé à restreindre tous les identifiants à un minimum et un maximum de 5 longueurs, alors votre domaine ressemble à tous les identifiants de longueur 0 à 5 (2^35) moins tous les identifiants de longueur 0 à 4 (2^28) est 2^35 - 2^28 = 34 091 302 912, qui est encore assez grande :)

Answer 5

Hey nll, comme plusieurs autres personnes vous l'ont dit .. Si vous commencez à compresser l'URL en quelque chose de petit, il vous sera impossible de Gardez-le unique. Cela dit, vous devez faire votre propre code pour chaque URL qui vous est soumise. Une façon (facile) de le faire est d'essayer de créer une base de données à partir des urls soumises puis de générer un champ guid pour chacune, puis d'en obtenir une sous-chaîne en s'assurant que chaque chose est totalement différente.

Par exemple: www.google.com avec le guid F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4 ->http://www.mysite.com/?q=CEB2

Comme plus de caractères que vous utilisez, plus de liens que vous pouvez suivre. pour cet exemple, vous aurez 65536 liens différents (avec seulement 4 caractères en hexadécimal).

Espérons que cela aide.