URL Shortening: Quel est le meilleur encodage à utiliser?

Question

J'ajoute une fonctionnalité à mon projet où nous générons des liens vers des éléments internes de notre site Web, et nous voulons que ces liens soient aussi courts que possible, nous allons donc créer notre propre "URL Shortener".

Je me demande quel est le meilleur codage/alphabet à utiliser pour les URL courtes générées. Il s'agit en grande partie d'une question subjective, j'aimerais savoir ce que vous pensez de la meilleure approche/compromis.

Plusieurs options que j'ai pensé:
- Digits, majuscules en minuscules + (base 62)
- Digits, seule minuscule (base 36)
- base 32 (http://www.crockford.com/wrmg/base32.html)
- (linkpot.net en utilisant des mots anglais courts communs)

Bien sûr, les deux autres sont meilleurs pour des utilisations autres que le clic, et les deux premiers sont meilleurs pour Twitter.

Aussi, si je vais avec des URL "cliquables seulement", je voudrais faire l'alphabet aussi grand que possible, en ajoutant d'autres symboles.

• Quels symboles puis-je utiliser dans les URL qui n'obtiendront pas d'URL codée?
• Quels symboles utiliser ? Est-ce que certains d'entre eux pourraient s'avérer problématiques? Je pense à slash et dot, par exemple.

Qu'en pensez-vous?

REMARQUE: La cible principale pour ces URL est Twitter. Gardant cela à l'esprit, nous devrions probablement avoir le plus grand alphabet possible, puisque la plupart des gens vont cliquer. Cependant, je m'intéresse à votre expérience avec des personnes qui utilisent des URL courtes d'autres façons (par téléphone, sur papier imprimé, etc.). Quelle est la probabilité que cela arrive?

NOTE 2: Je ne fais pas "encore un autre raccourcisseur d'URL", s'il vous plaît ne me condamnez pas avec des downvotes. Nous générons des URL courtes pour des éléments internes sur notre site, ne permettant à personne de raccourcir une URL. Imaginez Google Maps vous donnant des URL courtes lorsque vous générez un lien vers une coordonnée spécifique.

Answer 1

S'il s'agit de "URLs cliquables uniquement", j'utiliserais probablement un encodage en base 64. MIME base-64 utilise un couple de caractères que vous ne devriez pas utiliser, mais il y a suffisamment de caractères sûrs non réservés dans les URL que vous pouvez simplement les échanger. (De plus, vous n'avez pas besoin du rembourrage que la base-64 de MIME utilise, puisque vous savez quand votre URL se termine.)

Voici a page that discusses one way to do this.

Vous pouvez regarder RFC2396 pour savoir exactement quels caractères sont sûrs dans les URI si vous voulez vérifier.

Answer 2

Je serais curieux d'en savoir un peu plus sur la mise en œuvre. Comment ces URL seront-elles «réduites», ou les pages internes accédées seront-elles enregistrées en tant qu'URL raccourcies? Dans les deux cas, même si vous avez utilisé l'encodage de [A-Z], vous pourrez référencer 26 * 26 * 26 = 17 576 pages avec seulement 3 caractères; De combien de pages Web internes parlez-vous?

En général, je m'appuierais sur les exigences de votre cas d'utilisation pour choisir le bon jeu d'encodage. Envisagez-vous d'avoir ces liens disponibles pour des «utilisations autres que le clic»? Quelles seraient ces utilisations, et comment pensez-vous qu'ils vont modifier l'encodage?(Par exemple, l'utilisation de parties de l'URL comme nom de fichier sur un système de fichiers insensible à la casse réduit le jeu de caractères disponible.)

Here's une page informative sur le jeu de caractères dont vous disposez lorsque vous écrivez une URL.

Answer 3

J'irais avec Base-62, c'est le plus court. Une URL raccourcie n'est pas destinée à une entrée manuelle de toute façon, donc ne vous inquiétez pas de la sensibilité à la casse.