Bonjour,
on me signale que l'export des réponses d'un formidable en fichier .XLS
n'est plus en UTF-8 mais en LATIN
?exec=formulaires_reponses&id_formulaire=XX
ce qui ne permet plus d'ouvrir directement le fichier dans excel
Comme je ne sais pas bien où ça se joue je remonte ici le problème.
Voilou, merci 
touti
Hop,
Le 10/10/2019 à 15:49, toutati a écrit :
Bonjour,
on me signale que l'export des réponses d'un formidable en fichier .XLS
n'est plus en UTF-8 mais en LATIN
Je crois bien que ça a toujours été le cas, cf :
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/exporter_csv.php#L70
Et ça semble bien être aussi le cas dans la fonction embarquée par spip-bonux :
++
b_b
Salut,
Le 10/10/2019 à 15:58, Bruno Bergot a écrit :
Le 10/10/2019 à 15:49, toutati a écrit :
on me signale que l'export des réponses d'un formidable en fichier .XLS
n'est plus en UTF-8 mais en LATINJe crois bien que ça a toujours été le cas
C'est pas plutôt Excel qui, à la différence de LibreOffice, ne sait pas les ouvrir par défaut et qu'il faut passer par Importer (de mémoire) ?
jean marie
toutati a écrit le 10/10/2019 à 15:49 :
Bonjour,
on me signale que l'export des réponses d'un formidable en fichier .XLS
n'est plus en UTF-8 mais en LATIN
Voir aussi :
--
RealET
Le 10/10/2019 à 16:12, RealET a écrit :
toutati a écrit le 10/10/2019 à 15:49 :
Bonjour,
on me signale que l'export des réponses d'un formidable en fichier .XLS
n'est plus en UTF-8 mais en LATINVoir aussi :
Formidable, le générateur de formulaires - SPIP-Contrib
J'utilise aussi une lib de ce type (PHPexcel) et un peu de surcharge pour générer de _vrais_ fichiers .xlsx pour les exports de réponses (100% compatibles Libre Office et Excel, sans manipulation).
Ça pourrait être intégré nativement à spip-bonux à la place du traitement bancal actuel en faux CSV, en plus ça servirait à tout le monde, pas que à formidable.
--
nicod_
Ben voila 
merci de toutes vos réponses,
en effet quand je regarde le code ça cafouille pas mal. Déjà pour
retrouver ce qui concerne uniquement xls, on pourrait éclaircir et
séparer les fonctions pour excel de celles de csv, rien que la fonction
qui est appelé depuis formidable et qui est dans le core sur
ecrire/inc/exporter_csv.php est difficilement compréhensible. Il y a (il
me semble) de nouvelles fonctions depuis PHP5 orienté objet pour les CSV
plutot claires.
Donc ce serait surtout bien d'avoir un traitement de fichiers CSV et
Excel autonome dans un plugin avec une librairie qui va bien, et sortir
ces fonctions du core, nope ?
Des bises
++
touti
Le 10/10/2019 à 17:55, nicod_ a écrit :
Le 10/10/2019 à 16:12, RealET a écrit :
toutati a écrit le 10/10/2019 à 15:49 :
Bonjour,
on me signale que l'export des réponses d'un formidable en fichier .XLS
n'est plus en UTF-8 mais en LATINVoir aussi :
Formidable, le générateur de formulaires - SPIP-ContribJ'utilise aussi une lib de ce type (PHPexcel) et un peu de surcharge
pour générer de _vrais_ fichiers .xlsx pour les exports de réponses
(100% compatibles Libre Office et Excel, sans manipulation).Ça pourrait être intégré nativement à spip-bonux à la place du
traitement bancal actuel en faux CSV, en plus ça servirait à tout le
monde, pas que à formidable.
Le 10/10/2019 à 18:18, toutati a écrit :
en effet quand je regarde le code ça cafouille pas mal. Déjà pour
retrouver ce qui concerne uniquement xls, on pourrait éclaircir et
séparer les fonctions pour excel de celles de csv, rien que la fonction
qui est appelé depuis formidable et qui est dans le core sur
ecrire/inc/exporter_csv.php est difficilement compréhensible. Il y a (il
me semble) de nouvelles fonctions depuis PHP5 orienté objet pour les CSV
plutot claires.
Formidable nécessite spip_bonux, c'est donc ses fonctions qui sont utilisées, pas celles du core :
/spip-bonux-3/inc/exporter_csv.php
Donc ce serait surtout bien d'avoir un traitement de fichiers CSV et
Excel autonome dans un plugin avec une librairie qui va bien, et sortir
ces fonctions du core, nope ?
Oui, il faudrait faire un plugin qui propose exporter_xlsx() et importer_xlsx(), avec la même signature, basée sur une lib comme Spout ou PHPexcel.
Et modifier exporter_formulaires_reponses() dans formidable pour qu'elle appelle l'une ou l'autre.
J'ai pas du tout le temps en ce moment, mais si tu te le sens, j'ai du code sous la main
Ou bien RealEt peut fournir le sien (Spout a l'air plus rapide comme lib que PHPexcel).
--
nicod_
Historiquement ce qui marchait pour un import facile dans Excel c’est en effet du CSV tabulé en iso-truc exclusivement.
C’est pourquoi la fonction d’export CSV a ce type d’option pour assurer a minima un peu de compat avec le truc proprio.
Pour les vrais exports csv c’est plutôt fonctionnel, même si on peut sans doute se reposer sur une librairie plus moderne — mais je pense que ça vaudra surtout pour les exports dans les formats natifs excel.
Sur le fond on a un vrai problème sur les exports qui actuellement cassent tout dès que les données sont un peu trop volumineuses, ce qui est très gênant (par exemple avec formidable, notamment).
Si on doit refaire des nouvelles fonctions et une nouvelle API, il serait vraiment bien de prendre ce problème en compte.
Une des pistes est que tant qu’on push le fichier généré sur la sortie, on est pas coupé par le timeout. Mais ça implique d’exporter au fur et à mesure qu’on construit les lignes de l’export, car si on commence par construire un gros tableau de données pour pouvoir l’exporter ensuite on meurt avant d’avoir commencer à générer le fichier.
Je dis ça pour partager car je sais pas si on sait faire ça dans le cas générique…
--
Cédric
Le 10 oct. 2019 à 18:31 +0200, nicod_ <nicod@lerebooteux.fr>, a écrit :
Le 10/10/2019 à 18:18, toutati a écrit :
> en effet quand je regarde le code ça cafouille pas mal. Déjà pour
> retrouver ce qui concerne uniquement xls, on pourrait éclaircir et
> séparer les fonctions pour excel de celles de csv, rien que la fonction
> qui est appelé depuis formidable et qui est dans le core sur
> ecrire/inc/exporter_csv.php est difficilement compréhensible. Il y a (il
> me semble) de nouvelles fonctions depuis PHP5 orienté objet pour les CSV
> plutot claires.Formidable nécessite spip_bonux, c'est donc ses fonctions qui sont
utilisées, pas celles du core :
/spip-bonux-3/inc/exporter_csv.php> Donc ce serait surtout bien d'avoir un traitement de fichiers CSV et
> Excel autonome dans un plugin avec une librairie qui va bien, et sortir
> ces fonctions du core, nope ?Oui, il faudrait faire un plugin qui propose exporter_xlsx() et
importer_xlsx(), avec la même signature, basée sur une lib comme Spout
ou PHPexcel.Et modifier exporter_formulaires_reponses() dans formidable pour qu'elle
appelle l'une ou l'autre.J'ai pas du tout le temps en ce moment, mais si tu te le sens, j'ai du
code sous la mainOu bien RealEt peut fournir le sien (Spout a l'air plus rapide comme lib
que PHPexcel).--
nicod_
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
Le 10/10/2019 à 19:23, Cerdic a écrit :
Historiquement ce qui marchait pour un import facile dans Excel c’est en effet du CSV tabulé en iso-truc exclusivement.
C’est pourquoi la fonction d’export CSV a ce type d’option pour assurer a minima un peu de compat avec le truc proprio.
Pour les vrais exports csv c’est plutôt fonctionnel, même si on peut sans doute se reposer sur une librairie plus moderne — mais je pense que ça vaudra surtout pour les exports dans les formats natifs excel.
Pour le CSV, ça marche très bien, le code est léger et facile à maintenir, ça ne vaut pas le coup d'y coller une lib spécifique je pense.
Sur le fond on a un vrai problème sur les exports qui actuellement cassent tout dès que les données sont un peu trop volumineuses, ce qui est très gênant (par exemple avec formidable, notamment).
Oui.
C'est entre autres pour ça qu'on a ajouté des dates (du ... au ...) dans l'export des réponses de formidable, pour pouvoir extraire par "paquets".
Mais bon, c'est une façon de contourner le problème.
Si on doit refaire des nouvelles fonctions et une nouvelle API, il serait vraiment bien de prendre ce problème en compte.
Une des pistes est que tant qu’on push le fichier généré sur la sortie, on est pas coupé par le timeout. Mais ça implique d’exporter au fur et à mesure qu’on construit les lignes de l’export, car si on commence par construire un gros tableau de données pour pouvoir l’exporter ensuite on meurt avant d’avoir commencer à générer le fichier.
Ça serait peut être bien oui, d'abord faire du batch par paquet de lignes/réponses pour construire un tableau brut, puis le transformer, tu penses à un truc comme ça ?
--
nicod_