RACCOURCISSEUR D'URL
X_Cli
Messages postés
44
Date d'inscription
dimanche 12 mars 2006
Statut
Membre
Dernière intervention
2 mars 2013
-
7 mars 2010 à 10:21
dieng444 Messages postés 3 Date d'inscription lundi 11 juin 2012 Statut Membre Dernière intervention 6 avril 2013 - 6 avril 2013 à 15:48
dieng444 Messages postés 3 Date d'inscription lundi 11 juin 2012 Statut Membre Dernière intervention 6 avril 2013 - 6 avril 2013 à 15:48
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51389-raccourcisseur-d-url
https://codes-sources.commentcamarche.net/source/51389-raccourcisseur-d-url
6 avril 2013 à 15:48
moi j'ai une question , je suis débutant en Php et j'ai un projet de réalisation de raccourcisseur d'url, j'aimerai savoir si quelqu'un parmi vous saurai où est ce que je pourrai trouver un cours très détaillé qui explique le fonctionnement et la conception de ce genre de technologie car j'aimerai comprendre le mécanisme de fonctionnement avant de me lancé , je compte énormément sur vos aides et réponses merci d'avance.
15 avril 2010 à 14:28
mettre tous les string dans un fichier séparé pour une traduction facilitée
8 mars 2010 à 20:37
tout d'abord merci pour vos commentaires constructifs.
L'intérêt de la BDD est de prévoir de futures améliorations, comme un panel d'administration, etc
Effectivement la table était assez crade, j'ai modifié la structure pour cette version.
Pour ce qui est de la sanitization, je l'ai également ajoutée.
Pour le compteur étant donné que le site de base n'était pas trés visitée ce n'était pas dérangeant,
maintenant, il est configurable, et il y a la possibilité de le desactiver, de l'utiliser en mode simple ou de l'utiliser avec APC,
le principe est simple, les informations sont stockées dans un tableau en cache jusqu'à atteindre une limite configurable,
puis tout est ajouté dans la base. Cela permet de gagner en performances.
La table est également maintenant en UTF-8.
Merci LEFAUVE42 pour ta fonction de verification des URL, je l'ai ajoutée quasiment telle quelle, elle marche bien :)
Voila voila, encore une fois merci et n'hésitez pas à me donner vos impressions sur ce nouveau code :)
8 mars 2010 à 13:03
Ensuite, j'ajouterai même que l'utilisation de regexp tout court pour tester si ca commence par http:// ou https:// est aussi excessif : substr ou substr_compare est suffisant.
VARCHAR(100) est trop court pour une URL. Les RFC disent qu'un nom de domaine fait maximum 255 caractères. Il faut ajouter ensuite la requête plus la query string. Je dirais qu'un VARCHAR(1000) est adéquat (depuis mysql 5.x (x>=1 il me semble), les varchar peuvent faire plus de 255).
Faire les requêtes après l'envoi des headers ne changera rien : le navigateur (ou même le serveur web (apache + mod_deflate par exemple)) va attendre la fin de chargement de la page pour interpréter (réciproquement envoyer).
8 mars 2010 à 11:46
C'est sympa comme point de depart, mais j'ai quelques petites remarques :
- Tes requetes SQL utilisent beaucoup de conversion de collation. Pourquoi ne pas creer directement tes tables en UTF8 plutot que de te trainer le latin1_swedish_ci ?
- Tu n'as pas besoin de stoquer le code dans ta base, puisque tu peux l'obtenir simplement a partir de l'id, et inversement. Comme ca tu n'utilises plus que le champs id pour retrouver tes donnees, qui est deja indexe (les indexes sont importants comme le faisait remarquer X_Cli).
- Le type "LongText" me parait un peu "overkill" pour stoquer une URL. Un VARCHAR(100) devrait suffire, non ?
- Tu n'as aucune protection contre les SQL injection. Regarde un peu les fonctions mysql_escape_string() et mysql_real_escape_string() pour corriger ca.
- Ta fonction CheckURL est plutot maladroite. Tu devrais pouvoir la remplacer par une seule expression reguliere, et comme le disait aussi X_Cli, utiliser les expressions regulieres PERL au lieux des POSIX qui sont obsoletes depuis PHP 5.3. Ca devrait donner quelque chose comme ca :
function CheckURL($url)
{
return preg_match('@^https?://.+$@i',urldecode(trim($url)),$matches)?$matches[0]:'error';
}
(a tester, mais ca devrait etre bon).
- Ta fonction CheckURL() appelait deux fois urldecode(). Ca peut poser des problemes avec les url contenant des '+' ou des '%' par exemple.
- Faire deux requetes par redirection est quand meme couteux. Si tu veux vraiment garder un compteur, tu peux peut-etre faire renvoyer la redirection avant de faire la seconde requete. La charge sera sensiblement la meme sur tou serveur, mais le client attendra un peu moins longtemps.
Voila, il doit y avoir d'autres ameliorations, mais c'est deja un bon depart :o)
Bon courrage,
Eric
7 mars 2010 à 10:27
Par ailleurs, faire deux requêtes SQL à chaque requête de redir est un performance killer très important. Ce genre de compte se fait plutôt, par exemple avec un envoi de trame UDP à un petit script serveur qui compte en RAM et met à jour périodiquement la base de données.
7 mars 2010 à 10:21
Je vois également des utilisations de fonction ereg* qui sont considérées comme deprecated.
Je trouve bien en revanche d'avoir pensé à la déduplication des URLs.