Je veux développer quelque chose de similaire à Jsfiddle dans où l'utilisateur peut saisir certaines données, puis "Enregistrer" et obtenir une URL aléatoire unique qui charge ces données.
Je ne veux pas faire les sauvegardes séquentielles parce que je ne veux pas que quiconque attrape toutes mes entrées, car certains peuvent être privés. Toutefois sur le serveur, je voudrais l'enregistrer dans l'ordre séquentiel.
existe une fonction ou une technique qui convertit un nombre en hachage qui comporte 4 characteurs sans collisions avant Par exemple, la première entrée du serveur sera nommée Edit: Je ne sais pas si c'est évident, mais cette fonction de type hash doit être réversible car lorsque l'utilisateur demande (62 * 62 * 62 * 62 === 14776336) entrées?
1 sur le serveur mais iuew3 à l'utilisateur, la prochaine entrée sera 2 Sur le serveur mais uegr à l'utilisateur ...
uegr le serveur doit savoir au fichier informatique de serveur 2 < / code>
6 Réponses :
À mon avis Si vous conservez aussi le Sauvegardez le temps d'entrée sur le serveur, vous pouvez générer une fonction de hachage. Hash = FUNC (ID, TIME) Mais avec uniquement Hash = Func (ID) SOIT ÊTRE FACILE À RESSAGER
Cela ne peut pas vraiment être réversible. Le seul moyen (celui utilisé par les raccourcisseurs d'URL et Jsfiddle) consiste à stocker le hachage généré (en réalité, il est digeste) dans une structure de table / de données de quelque sorte et * RECHERCHez-la à la récupération.
passe de, par exemple 128 caractères de données → A 4 Visible Char Digest, vous Perdez beaucoup de données .
Vous ne pouvez stocker les données restantes dans les fissures magiques entre ces 4 octets, il n'y en a pas.
"Convertit un nombre en hachage qui comporte 4 characteurs sans collisions avant (62 * 62 * 62 * 62 === 14776336) entrées" - il n'y a pas de perte de données.
Voici comment je l'ai mis en œuvre. Voici le fichier sauvegard.php (peut-on me dire s'il y a des défauts de conception de la conception): et voici LOAD.PHP: P> <?php
if (!file_exists('saves/' . $_REQUEST['file'])) {
file_put_contents('saves/data/log', 'requested saves/' . $_REQUEST['file'] . "\n", FILE_APPEND);
die();
}
$file_pointer = file_get_contents('saves/' . $_REQUEST['file']);
if (!file_exists('saves/data/' . $file_pointer)) {
file_put_contents('saves/data/log', 'requested saves/data/' . $file_pointer . 'from ' . $_REQUEST['file'] . "\n", FILE_APPEND);
die();
}
echo file_get_contents('saves/data/' . $file_pointer);
?>
C'est un ensemble étrange de contraintes. J'utilise régulièrement des checksums MD5 pour générer des URL uniques à partir de données. Si l'utilisateur n'a pas déjà les données, ils ne peuvent pas deviner les URL.
Je comprends de ne pas vouloir utiliser une base de données - si vous n'en avez jamais utilisé un avant, la courbe d'apprentissage peut être un peu raide.
Je ne comprends pas la contrainte sur "stocker les choses séquentiellement sur le serveur." Si vous devez connaître l'ordre dans lequel les hachages sont créés, je voudrais simplement mettre ces informations dans un fichier séparé. Vous devrez peut-être devoir faire le verrouillage du fichier ou un autre type de hack pour vous assurer de pouvoir annoncer un hachage à ce fichier de manière incrémentielle.
Si vous voulez des URL courtes, vous pouvez prendre un préfixe d'une somme de contrôle MD5 ou vous pouvez prendre un CRC-32 et Base64 l'encoder. Les deux vous donneront des URL uniques avec une probabilité raisonnablement bonne.
Le dernier paragraphe est une mauvaise suggestion, vous pouvez créer des collisions avec elle.
@Karolyhorvath, je sais, mais OP spécifie des URL courtes. J'ai effectivement eu un bon succès avec les checksums CRC-32; La probabilité de collision est petite. Mais quand je veux quelque chose près d'une garantie, j'utilise juste le MD5 complet et vivez avec les URL longues
Il est possible de le faire, mais je suggérerais d'utiliser 64 caractères, car cela le rendra beaucoup plus facile. 4 caractères 6 bits = 24bits.
Utilisez une combinaison de ceux-ci:
LFSR est fortement recommandé car il fera un bon brouillage. Les autres sont facultatifs. Toutes ces manipulations sont lorsque vous avez calculé le numéro "mélangé", emballez simplement à Une chaîne binaire et le coder avec pour le décodage, effectuez simplement l'inverse de ces opérations. échantillon (2 ^ 24 séquence unique longue): sortie: Remarque: Pour URL, remplacez Remarque: bien que cela fonctionne, pour un scénario simple comme le vôtre, il est probablement plus facile de créer un nom de fichier aléatoire , jusqu'à ce qu'il n'existe pas. Personne ne se soucie du numéro de l'entrée. base64_encode . + et / avec - et _ .
@Khorvath. C'est une excellente solution! Serait-il possible d'élargir ces fonctions pour former une chaîne de caractères de 11 caractères à des ID codé de la même manière que les ID vidéo inclus dans la variable V $ _GET dans les URL de V $ dans YouTube, c'est-à-dire rarlg6Hezzm dans YouTube.com/watch?v=rarlg6Hezzm ?
@Barrybeerman: Oui, c'est possible. Pour toute taille pratique. Vous devez modifier un peu le code. L'article Wikipedia relie ce: xilinx.com/support/documentation/application_notes/xapp052. P DF Il possède des solutions pour des robinets de LFSR de longueur maximale pour une hausse de 168 bits.
@Khorvath: C'est parfait. Si vous avez une chance, seriez-vous capable de répondre à cette question Stackoverflow.com/Questtions/18365607/... avec un exemple de code afin que je puisse l'accepter? Merci encore pour votre aide.
@Khorvath: Je peux ajouter une prime si cela aide. Je viens de voir beaucoup de tentatives de création d'un algorithme similaire au cryptage d'ID vidéo de YouTube et votre approche est facilement la meilleure.
Voici une libernité réversible qui fonctionne avec bcmath
http://blog.kevburnsjr.com/php-unique-hash
Si je faisais cela, alors j'utiliserais probablement un langage de programmation différent et peut donc utiliser The Crypt :: Skip32 :: Base32Crockford Module , qui dit vous permet d'avoir des identifiants numériques de base de données que vous pouvez utiliser en toute sécurité dans des URL en toute sécurité sans laisser les utilisateurs de voir combien d'enregistrements que vous avez ou en les laissez sauter en avant ou en arrière entre les enregistrements . Le code source est disponible cependant, vous pouvez donc porter l'algorithme à PHP si vous le souhaitez.
Pourquoi avez-vous besoin que cela soit réversible? Il suffit de stocker le hachage généré avec l'ID et votre fait.
@Yoshi: Je n'utilise pas une base de données
Oh, alors je suppose que vous devrez chercher une fonction CRYPT (comme Quentin suggère) au lieu d'une fonction de hachage.
Une fonction de hachage est par définition non réversible.
Qu'est-ce que vous utilisez pour stocker les données, sinon une base de données?
@Nickjohnson: fichiers individuels.
@qwertymk alors pourquoi les identifiants doivent-ils être séquentiels? Nommez simplement les fichiers après le hachage. En outre, pourquoi sur Terre n'utilisez-vous pas une base de données? Ils sont construits pour cela.
@HAROLD: en.wikipedia.org/wiki/hash_function#trivial_hash_function et EN.Wikipedia.org/wiki/hash_function#Perfect_hashing
@Karolyhorvath Ils ne sont pas vraiment réversibles non plus, ils ne sont que réversibles quand il y a une limitation de l'entrée.
@HAROLD: Avez-vous le lire en fait? Vous avez souvent une limitation sur l'entrée. L'OP a également donné une limite. Vérifiez ma réponse.
@Karolyhorvath J'avoue que je n'ai pas