[Résolu] Rapberry Pi vs DSM : problème export php / csv

[bruno78]

Bonjour,

• j'ai un site qui tourne sur mon DS918, sous wordpress / nginx / mariadb / PHP. Une des fonctionnalité est l'export de tableaux sql en csv via un script PHP. Pour cela, j'ai entre autre appliqué la méthode qui se trouve ici (https://gist.github.com/janschoepke/3e7a3639546d0d740c023e11289cf13d)
• donc j'ai un code comme ceci : ($ress étant le résultat de ma requête sql)

			// creation du fichier csv à exporter
			// gestion du BOM (pour MS Excel) Byte Order Mark
			// compatibilité MS Excel Windows 
			$bom = chr(0xEF) . chr(0xBB) . chr(0xBF);
			/* vars for export */
			// database record to be exported
			$db_record = 'Liste_Noms';
			// optional where query
			$where = 'WHERE 1 ORDER BY 1';
			// filename for export
			$csv_filename = 'OSL_'.$db_record.'_'.date('Y-m-d').'.csv';
			$csv_export = '';
			$field = mysqli_field_count($dbconnect);
			// create line with field names
			for($i = 0; $i < $field; $i++) {
				$csv_export.= mysqli_fetch_field_direct($ress, $i)->name.';';				
			}
			// newline
			$csv_export .= PHP_EOL;
			// loop through database query and fill export variable
			while($row = mysqli_fetch_array($ress)) {
				// create line with field values
				for($i = 0; $i < $field; $i++) {
					$csv_export.= '"'.$row[mysqli_fetch_field_direct($ress, $i)->name].'";';
				}
			// newline 
			$csv_export .= PHP_EOL;
			}

			// ajout BOM au fichier pour passage en UTF8-BOM
			// pour MS Excel (Byte Order Mark)
			// compatibilité MS Excel Windows 
			$csv_export = $bom . $csv_export;
			
			// Export the data and prompt a csv file for download
			header("Content-type: text/x-csv; charset=utf-8");
			header("Content-Disposition: attachment; filename=".$csv_filename."");
			echo($csv_export);

 

=> cela fonctionne nickel sur le DSM.

MAIS :

faisant quelque fois des essais sur le Syno, j'ai installé le site à l'identique sur un Rasp Pi 3B+ pour pouvoir basculer au cas ou.. Après quelques réglages (wordpress, nginx, php) tout fonctionne à merveille et à l'identique, ... sauf cet export csv !!

Symptôme : Excel me dit "fichier corrompu", et quand je regarde de plus près, je m'apperçois que le fichier csv transféré contient une première ligne "parasite" :

Ce sont cette tabulation et "LF" en ligne 1 qui empêche Excel d'ouvrir le fichier. (alors que OpenOffice Calc s'en moque royalement et ignore cette ligne)

Le même code sur le Syno donne un résultat propre, sans cette première ligne.

Je crois avoir à peu près tout essayé pour supprimer cette ligne parasite (text/csv, application/csv, fputcsv, trim, ltrim, ....) Rien à faire.

=> je ne sais plus où chercher ..... J'ai tenté de regarder les configurations de PHP, c'est touffu, mais rien d'évident.

Si quelqu'un à une idée géniale , je suis preneur.

Merci d'avance,

Bruno78

Modifié le 18 novembre 2020 par bruno78

[bruno78]

Bonjour,

je reviens sur ce post car j'avais besoin de faire quelques tests complémentaires, étant complètement dans le flou.

La seule configuration que j'ai réussi à faire tourner sur le Pi, c'est un mettant un lien de chargement sur le site. Soit un syntaxe de ce type :

file_put_contents($csv_filename, $csv_export);
header('Location: http://pisl.ndd.tld/'.$csv_filename.'');

qui donne le lien de chargement du fichier à rapatrier. Toute autre méthode a échoué et m'a toujours mis ces 2 octets d'entête parasites (0x09 0x0a  càd <tab> <LF>). En faisant une trace réseau, j'ai confirmé que c'est bien au départ, sur le Rasp Pi, que se produit l'ajout des ces 2 octets, phénomène qui n'apparait pas lorsque le même code est hébergé sur le Syno.

Je cherche toujours quelle est la différence de config. qui pourrait expliquer ce comportement bizarre :

PHP7.3 d'un côté, PHP7.4 de l'autre ?  LANG=en_US.utf8 d'un côté, LANG=fr_FR.UTF8 de l'autre ?

Modifié le 16 novembre 2020 par bruno78

[.Shad.]

Peut-être auras-tu plus d'infos sur le forum de la fondation Raspberry ?

[bruno78]

Problème résolu :

• ayant fini par trouvé ce post (https://stackoverflow.com/questions/8384122/php-downloaded-binary-file-gets-an-additional-byte-0x0a-at-the-end ) , j'ai regardé de plus près mes balises php ...
• la balise PHPfermante d'un fichier include était suivie d'un "blanc" (donc peu détectable sauf à le chercher explicitement), pris en compte par la commande echo du fichier principal, et provoquait cet entête indésirable.

PS : ça veut aussi dire que ce que je croyais être des tests à configuration "strictement identique" ne l'était pas tant que cela. Le diable se niche dans les détails.