[Résolu] Point-virgule dans requête MYSQL

(reprise du message précédent)

Salut,

je comprends pas tout a tes explications mais bon

Je n'utilise presque jamais excel mais je trouve très étonnant que tu ne puisse pas importer (ou exporter ? j'ai pas compris..) un csv en utf8 avec excel.

Ensuite, j'ai l'impression que tu parses le fichier csv en php. Cela ne me semble pas une bonne idée de le faire avec explode .
Je dirais de plutôt regarder du coté des fonctions php pour manipuler du csv : https://www.php.net/manual/en/function.str-getcsv.php (ou du coté des trucs avec des regex genre https://www.php.net/manual/fr/function.preg-split.php )

Bonjour Mathieuu,

Il s'agit d'importer un fichier Excel codé en .csv.

1) Avec Excel je n'ai pas trouvé comment coder en UTF-8 et il me semble avoir pas mal cherché.

2) Je vais regarder les fonctions PHP de traitement des CSV, si elles existent c'est qu'elles doivent mieux faire qu'un explode ().
Merci pour la piste.

JENCAL a écrit :
C'est pas parce que j'ai mis des volets chez moi, que les cambrioleurs peuvent pas cambrioler

D'accord mais dans un script d'administration il n'y a ni porte ni fenêtre.

En cherchant un peu je viens de tomber sur ce site web qui détails plusieurs façons d'exporter un tableau en csv utf8 : https://support.collegekickstart.com/hc/en-us/articles/11386233650445-How-do-I-export-a-file-as-a-CSV-in-UTF-8

TLDR : Save As -> Choisir CSV UTF8 dans la liste des formats

Lien intéressant, merci.

Concernant Excel j'ai une version un peu ancienne, le choix UTF-8 n'est pas permis.
Mais possibilité de passer sur Calc qui est gratuit.
Modifié par boteha_2 (15 Oct 2024 - 15:30)

"j'utilise quand même une protection bien connue : le typage des variables risquant d'être injectées."

Le cast via intval est en effet suffisant pour les nombres entier, par contre le cast en string n'apporte aucune protection.
Revoir l'exemple de JENCAL avec "OR 1=1" pour s'en rendre compte.

"Comme il s'agit d'un programme d'administration je n'ai aucun risque d'injection, donc une requête préparée me semble inutile."

Même les utilisateurs légitimes (non malveillant) de ton application peuvent faire malgré eux une injection ou au moins faire planter la requête sql si ils renseignent un caractère réservé en sql en paramètre.

L'utilisation des requêtes préparées (ou l'utilisation de PDO::quote si on utilise pas les requêtes préparées) n'est jamais inutile et devrait être systématique (hormis quelques cas spécifiques pour les noms de table ou colonne par exemple)

Bonjour Pitet,

Ok, c'est noté, je vais généraliser les requêtes préparées.

Autrement, j'utilise à présent str-getcsv.php au lieu de explode, pas de souci.

Bonjour,

Une chose qui m'échappe à propos des requêtes préparées.

mysqli_stmt_bind_param

PHP.net a écrit :
i correspond à une variable de type int
d correspond à une variable de type float
s correspond à une variable de type string
b correspond à une variable de type BLOB, qui sera envoyé par paquets

Si DATE ou BOOL, comment fait-on ?

Bonjour,

Je coche Résolu après avoir ouvert une nouvelle discussion sir les requêtes préparées.

Encire merci pour votre suivi.