peut on faire des recherche critere dans un fichier en php
26 réponses
dav
au lieu de gérer une base MySql j'envisage pour un petit annuaire de
gérer mes données dans un fichier texte.
je vais donc utiliser fopen() et fputs. mais est il possible
d'envisager, par le biais de données récupérées dans un formulaire, de
faire une recherche avec des criteres, comme en sql, sur ce fichier
texte de façon a afficher dans un tableau les données trouvées ?
mon idée est d'afficher les résultats trouvés sous forme de liens, et
quand l'utilisateur cliquera dessus, de refaire une seconde recherche
dans le fichier de façon à n'afficher en fin de compte que
l'enregistrement voulu. (nom + prénom + service + numémro_tél)
Oui, si on ecrit un enregistrement par ligne, il me semble... que justement, le seek d'un fichier teste est en fait le numero de la ligne à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne. En fait pour faire la vérification, il faut que tu te déplace au caractere précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien "n"
-- Vincent
Oui, si on ecrit un enregistrement par ligne, il me semble... que
justement, le seek d'un fichier teste est en fait le numero de la ligne
à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0)
précédentes sont vides (puisqu'il y a au moins un caractère par ligne :
"n"). C'est assez inutile. Le seek n'est probablement pas le numéro de
ligne.
En fait pour faire la vérification, il faut que tu te déplace au caractere
précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien
"n"
Oui, si on ecrit un enregistrement par ligne, il me semble... que justement, le seek d'un fichier teste est en fait le numero de la ligne à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne. En fait pour faire la vérification, il faut que tu te déplace au caractere précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien "n"
-- Vincent
(¯`·..Yttrium ...·´¯)
"Vincent Lascaux" a écrit dans le message de news: 4295b568$0$6797$
Oui, si on ecrit un enregistrement par ligne, il me semble... que justement, le seek d'un fichier teste est en fait le numero de la ligne à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne. En fait pour faire la vérification, il faut que tu te déplace au caractere précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien
"n"
-- Vincent
Lapin compris .. Du tout ... :-(
"Vincent Lascaux" <nospam@nospam.org> a écrit dans le message de news:
4295b568$0$6797$636a15ce@news.free.fr...
Oui, si on ecrit un enregistrement par ligne, il me semble... que
justement, le seek d'un fichier teste est en fait le numero de la ligne
à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0)
précédentes sont vides (puisqu'il y a au moins un caractère par ligne :
"n"). C'est assez inutile. Le seek n'est probablement pas le numéro de
ligne.
En fait pour faire la vérification, il faut que tu te déplace au caractere
précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne
bien
"Vincent Lascaux" a écrit dans le message de news: 4295b568$0$6797$
Oui, si on ecrit un enregistrement par ligne, il me semble... que justement, le seek d'un fichier teste est en fait le numero de la ligne à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne. En fait pour faire la vérification, il faut que tu te déplace au caractere précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien
"n"
-- Vincent
Lapin compris .. Du tout ... :-(
Olivier Miakinen
Oui, si on ecrit un enregistrement par ligne, il me semble... que justement, le seek d'un fichier teste est en fait le numero de la ligne à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne. En fait pour faire la vérification, il faut que tu te déplace au caractere précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien "n"
Lapin compris .. Du tout ... :-(
Ça me semble normal, en tout cas pour la première partie de la réponse de Vincent. Je ne suis pas sûr qu'il se soit relu... ;-) En revanche, la dernière phrase me semble à la fois compréhensible et juste.
Prenons l'exemple suivant, en supposant des fins de ligne « à la Unix » (n seul). Je ne suis pas sûr que le seek fonctionne bien avec des fins de ligne « à la Windows » (rn) dans un fichier ouvert en mode texte (ce qui remplace donc rn par n seul à la lecture).
<début de fichier> Voici le premier enregistrementn Ceci est le secondn En voilà un autren Enfin voici le derniern <fin de fichier>
Les valeurs possibles pour les "seek" en début de ligne sont : 0, 32, 51 et 69. Quant aux positions des n, ce sont 31, 50, 68 et 91.
Si la valeur est 0, tu es tranquille : c'est forcément un début de ligne, puisque c'est le début de la première ligne. Si ce n'est pas zéro, alors il faut vérifier que le caractère à "seek-1" est bien un n (ce qui fonctionne pour 32-1 = 31, 51-1 = 50, et 69-1 = 68). Pour être complet, il faut aussi vérifier qu'on n'est pas à la fin du fichier (à 92-1 = 91 on trouve bien un n, mais il n'y a pas de ligne derrière).
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Oui, si on ecrit un enregistrement par ligne, il me semble... que
justement, le seek d'un fichier teste est en fait le numero de la ligne
à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0)
précédentes sont vides (puisqu'il y a au moins un caractère par ligne :
"n"). C'est assez inutile. Le seek n'est probablement pas le numéro de
ligne.
En fait pour faire la vérification, il faut que tu te déplace au caractere
précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien
"n"
Lapin compris ..
Du tout ... :-(
Ça me semble normal, en tout cas pour la première partie de la
réponse de Vincent. Je ne suis pas sûr qu'il se soit relu... ;-)
En revanche, la dernière phrase me semble à la fois compréhensible
et juste.
Prenons l'exemple suivant, en supposant des fins de ligne « à la Unix »
(n seul). Je ne suis pas sûr que le seek fonctionne bien avec des fins
de ligne « à la Windows » (rn) dans un fichier ouvert en mode texte
(ce qui remplace donc rn par n seul à la lecture).
<début de fichier>
Voici le premier enregistrementn
Ceci est le secondn
En voilà un autren
Enfin voici le derniern
<fin de fichier>
Les valeurs possibles pour les "seek" en début de ligne sont : 0, 32, 51
et 69. Quant aux positions des n, ce sont 31, 50, 68 et 91.
Si la valeur est 0, tu es tranquille : c'est forcément un début de
ligne, puisque c'est le début de la première ligne. Si ce n'est pas
zéro, alors il faut vérifier que le caractère à "seek-1" est bien un
n (ce qui fonctionne pour 32-1 = 31, 51-1 = 50, et 69-1 = 68). Pour
être complet, il faut aussi vérifier qu'on n'est pas à la fin du fichier
(à 92-1 = 91 on trouve bien un n, mais il n'y a pas de ligne derrière).
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Oui, si on ecrit un enregistrement par ligne, il me semble... que justement, le seek d'un fichier teste est en fait le numero de la ligne à 2-3 trucs près...
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne. En fait pour faire la vérification, il faut que tu te déplace au caractere précédent (sauf si seek est 0), et que tu vérifies que fgetc() retourne bien "n"
Lapin compris .. Du tout ... :-(
Ça me semble normal, en tout cas pour la première partie de la réponse de Vincent. Je ne suis pas sûr qu'il se soit relu... ;-) En revanche, la dernière phrase me semble à la fois compréhensible et juste.
Prenons l'exemple suivant, en supposant des fins de ligne « à la Unix » (n seul). Je ne suis pas sûr que le seek fonctionne bien avec des fins de ligne « à la Windows » (rn) dans un fichier ouvert en mode texte (ce qui remplace donc rn par n seul à la lecture).
<début de fichier> Voici le premier enregistrementn Ceci est le secondn En voilà un autren Enfin voici le derniern <fin de fichier>
Les valeurs possibles pour les "seek" en début de ligne sont : 0, 32, 51 et 69. Quant aux positions des n, ce sont 31, 50, 68 et 91.
Si la valeur est 0, tu es tranquille : c'est forcément un début de ligne, puisque c'est le début de la première ligne. Si ce n'est pas zéro, alors il faut vérifier que le caractère à "seek-1" est bien un n (ce qui fonctionne pour 32-1 = 31, 51-1 = 50, et 69-1 = 68). Pour être complet, il faut aussi vérifier qu'on n'est pas à la fin du fichier (à 92-1 = 91 on trouve bien un n, mais il n'y a pas de ligne derrière).
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Vincent Lascaux
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne.
Ça me semble normal, en tout cas pour la première partie de la réponse de Vincent. Je ne suis pas sûr qu'il se soit relu... ;-)
Exacte... Je crois que je voulais dire ca :
Le "seek" d'un fichier est le numéro de la ligne (en commencant à compter les lignes à 0) ssi les toute les lignes précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile [d'avoir un fichier avec plein de lignes vides]. Le seek n'est probablement pas le numéro de ligne.
-- Vincent
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0)
précédentes sont vides (puisqu'il y a au moins un caractère par ligne :
"n"). C'est assez inutile. Le seek n'est probablement pas le numéro de
ligne.
Ça me semble normal, en tout cas pour la première partie de la
réponse de Vincent. Je ne suis pas sûr qu'il se soit relu... ;-)
Exacte... Je crois que je voulais dire ca :
Le "seek" d'un fichier est le numéro de la ligne (en commencant à compter
les lignes à 0)
ssi les toute les lignes précédentes sont vides (puisqu'il y a au moins un
caractère par ligne :
"n"). C'est assez inutile [d'avoir un fichier avec plein de lignes vides].
Le seek n'est probablement pas le numéro de
ligne.
Le "seek" d'un fichier est le numéro de la ligne (en commencant à 0) précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile. Le seek n'est probablement pas le numéro de ligne.
Ça me semble normal, en tout cas pour la première partie de la réponse de Vincent. Je ne suis pas sûr qu'il se soit relu... ;-)
Exacte... Je crois que je voulais dire ca :
Le "seek" d'un fichier est le numéro de la ligne (en commencant à compter les lignes à 0) ssi les toute les lignes précédentes sont vides (puisqu'il y a au moins un caractère par ligne : "n"). C'est assez inutile [d'avoir un fichier avec plein de lignes vides]. Le seek n'est probablement pas le numéro de ligne.
-- Vincent
Olivier Miakinen
Je crois que je voulais dire ca :
Le "seek" d'un fichier est le numéro de la ligne [...] Le seek n'est probablement pas le numéro de ligne.
;-)
En principe, le seek est la position dans le fichier en octets.
Je crois que je voulais dire ca :
Le "seek" d'un fichier est le numéro de la ligne
[...]
Le seek n'est probablement pas le numéro de ligne.
;-)
En principe, le seek est la position dans le fichier en octets.
Le "seek" d'un fichier est le numéro de la ligne [...] Le seek n'est probablement pas le numéro de ligne.
;-)
En principe, le seek est la position dans le fichier en octets.
bibi.skuk
Bon, effectivement, j'ai raconté pas mal de betises...
Mais par hasard, si je fait une serie de fgets( ) sur un fichier, je recupere des lignes non ? Donc, ensuite, en prenant le seek à ce moment la... j'ai les debuts de chaque lignes non ?
Bon, effectivement, j'ai raconté pas mal de betises...
Mais par hasard, si je fait une serie de fgets( ) sur un fichier, je
recupere des lignes non ?
Donc, ensuite, en prenant le seek à ce moment la... j'ai les debuts de
chaque lignes non ?
Bon, effectivement, j'ai raconté pas mal de betises...
Mais par hasard, si je fait une serie de fgets( ) sur un fichier, je recupere des lignes non ? Donc, ensuite, en prenant le seek à ce moment la... j'ai les debuts de chaque lignes non ?
__marc.quinton__
wrote:
Mais par hasard, si je fait une serie de fgets( ) sur un fichier, je recupere des lignes non ? Donc, ensuite, en prenant le seek à ce moment la... j'ai les debuts de chaque lignes non ?
oui, peut-etre, mais dans ce cas, pourquoi ne pas compter les n° de ligne plutot que la position dans le fichier avec seek.
* une ligne = un enregistrement,
alors ca donne :
http://.../index.php?id3 # la je veux l'enregistrement 123
et l'enregistrement 123, dans notre cas précis ce serait :
* la ligne 123, solution que je propose, meme si elle nécessite de recompter les lignes a chque fois ; sur des petits fichiers, ca devrait pas etre trop lourd, * 123 pourrait etre aussi le deplacement dans le fichier (seek).
maintenant, il va falloir gerer les acces concurentiels :
* ma solution est un peu plus solide, juste un peu * le seek tombe a terre ! si je supprime un enregistrement, ca decale tout * en fait l'idéal est de passer par un format CSV, il y a des API de lecture ecriture de fichiers au format CSV. Et probablement des interface facon SQL.
quel intéret pour se sujet, etonnant non ...
bibi.skuk@gmail.com wrote:
Mais par hasard, si je fait une serie de fgets( ) sur un fichier, je
recupere des lignes non ?
Donc, ensuite, en prenant le seek à ce moment la... j'ai les debuts de
chaque lignes non ?
oui, peut-etre, mais dans ce cas, pourquoi ne pas compter les n° de ligne
plutot que la position dans le fichier avec seek.
* une ligne = un enregistrement,
alors ca donne :
http://.../index.php?id3 # la je veux l'enregistrement 123
et l'enregistrement 123, dans notre cas précis ce serait :
* la ligne 123, solution que je propose, meme si elle nécessite
de recompter les lignes a chque fois ; sur des petits fichiers,
ca devrait pas etre trop lourd,
* 123 pourrait etre aussi le deplacement dans le fichier (seek).
maintenant, il va falloir gerer les acces concurentiels :
* ma solution est un peu plus solide, juste un peu
* le seek tombe a terre ! si je supprime un enregistrement,
ca decale tout
* en fait l'idéal est de passer par un format CSV, il y a
des API de lecture ecriture de fichiers au format CSV. Et probablement
des interface facon SQL.
Mais par hasard, si je fait une serie de fgets( ) sur un fichier, je recupere des lignes non ? Donc, ensuite, en prenant le seek à ce moment la... j'ai les debuts de chaque lignes non ?
oui, peut-etre, mais dans ce cas, pourquoi ne pas compter les n° de ligne plutot que la position dans le fichier avec seek.
* une ligne = un enregistrement,
alors ca donne :
http://.../index.php?id3 # la je veux l'enregistrement 123
et l'enregistrement 123, dans notre cas précis ce serait :
* la ligne 123, solution que je propose, meme si elle nécessite de recompter les lignes a chque fois ; sur des petits fichiers, ca devrait pas etre trop lourd, * 123 pourrait etre aussi le deplacement dans le fichier (seek).
maintenant, il va falloir gerer les acces concurentiels :
* ma solution est un peu plus solide, juste un peu * le seek tombe a terre ! si je supprime un enregistrement, ca decale tout * en fait l'idéal est de passer par un format CSV, il y a des API de lecture ecriture de fichiers au format CSV. Et probablement des interface facon SQL.
quel intéret pour se sujet, etonnant non ...
bibi.skuk
si on supprime un enregistrement, comme les seek sont générés à chaque fois que l'on affiche la liste complete, il n'y a aucuns problemes...
si on supprime un enregistrement, comme les seek sont générés à
chaque fois que l'on affiche la liste complete, il n'y a aucuns
problemes...
si on supprime un enregistrement, comme les seek sont générés à chaque fois que l'on affiche la liste complete, il n'y a aucuns problemes...
Demosthene
maintenant, il va falloir gerer les acces concurentiels :
* ma solution est un peu plus solide, juste un peu * le seek tombe a terre ! si je supprime un enregistrement, ca decale tout * en fait l'idéal est de passer par un format CSV, il y a des API de lecture ecriture de fichiers au format CSV. Et probablement des interface facon SQL.
quel intéret pour se sujet, etonnant non ...
En ce qui me concerne, Apache gère correctement l'accès (de manière atomique) aux fichiers textes. Je n'ai pas stréssé ces systèmes, mais je ne pense pas qu'il y ait de gros problèmes pour l'application envisagée.
Mfiez-vous quand même de ne penser qu'à votre besoin immédiat, vous pourriez avoir très vite l'envie d'en faire une application plus ambitieuse, là où une base de donnée est indispensable.
L'intéret de ce sujet vient peut-être de l'aura de forte technicité des bases de donnée.
Cordialement Démosthène
maintenant, il va falloir gerer les acces concurentiels :
* ma solution est un peu plus solide, juste un peu
* le seek tombe a terre ! si je supprime un enregistrement,
ca decale tout
* en fait l'idéal est de passer par un format CSV, il y a
des API de lecture ecriture de fichiers au format CSV. Et probablement
des interface facon SQL.
quel intéret pour se sujet, etonnant non ...
En ce qui me concerne, Apache gère correctement l'accès (de manière
atomique) aux fichiers textes. Je n'ai pas stréssé ces systèmes, mais je
ne pense pas qu'il y ait de gros problèmes pour l'application envisagée.
Mfiez-vous quand même de ne penser qu'à votre besoin immédiat, vous
pourriez avoir très vite l'envie d'en faire une application plus
ambitieuse, là où une base de donnée est indispensable.
L'intéret de ce sujet vient peut-être de l'aura de forte technicité des
bases de donnée.
maintenant, il va falloir gerer les acces concurentiels :
* ma solution est un peu plus solide, juste un peu * le seek tombe a terre ! si je supprime un enregistrement, ca decale tout * en fait l'idéal est de passer par un format CSV, il y a des API de lecture ecriture de fichiers au format CSV. Et probablement des interface facon SQL.
quel intéret pour se sujet, etonnant non ...
En ce qui me concerne, Apache gère correctement l'accès (de manière atomique) aux fichiers textes. Je n'ai pas stréssé ces systèmes, mais je ne pense pas qu'il y ait de gros problèmes pour l'application envisagée.
Mfiez-vous quand même de ne penser qu'à votre besoin immédiat, vous pourriez avoir très vite l'envie d'en faire une application plus ambitieuse, là où une base de donnée est indispensable.
L'intéret de ce sujet vient peut-être de l'aura de forte technicité des bases de donnée.
Cordialement Démosthène
__marc.quinton__
wrote:
si on supprime un enregistrement, comme les seek sont générés à chaque fois que l'on affiche la liste complete, il n'y a aucuns problemes...
faux !!! soit 2 utilisateurs l'un en edition, l'autre en suppression. * les 2 affichent un listing, obtiennent les id des lignes a modifier * les id sont enregistrés localement dans le navigateur et l'action se declanche au clic de l'utilisateur, * le second efface un enregistrement, * le premier avec un faux id va aller jardiner dans un enregistrement qui n'est plus le bon, mais l'id d'un etat passé du fichier de données.
Conclusion, ca ne marchera jamais en environnement concurentiel.
bibi.skuk@gmail.com wrote:
si on supprime un enregistrement, comme les seek sont générés à
chaque fois que l'on affiche la liste complete, il n'y a aucuns
problemes...
faux !!! soit 2 utilisateurs l'un en edition, l'autre en suppression.
* les 2 affichent un listing, obtiennent les id des lignes a modifier
* les id sont enregistrés localement dans le navigateur et l'action
se declanche au clic de l'utilisateur,
* le second efface un enregistrement,
* le premier avec un faux id va aller jardiner dans un enregistrement
qui n'est plus le bon, mais l'id d'un etat passé du fichier de données.
Conclusion, ca ne marchera jamais en environnement concurentiel.
si on supprime un enregistrement, comme les seek sont générés à chaque fois que l'on affiche la liste complete, il n'y a aucuns problemes...
faux !!! soit 2 utilisateurs l'un en edition, l'autre en suppression. * les 2 affichent un listing, obtiennent les id des lignes a modifier * les id sont enregistrés localement dans le navigateur et l'action se declanche au clic de l'utilisateur, * le second efface un enregistrement, * le premier avec un faux id va aller jardiner dans un enregistrement qui n'est plus le bon, mais l'id d'un etat passé du fichier de données.
Conclusion, ca ne marchera jamais en environnement concurentiel.
