FGETCSV () ignore les caractères spéciaux lorsqu'ils sont au début de la ligne!

Question

J'ai un script simple qui accepte un fichier CSV et lit chaque ligne dans un tableau. Je passe ensuite à travers chaque colonne de la première ligne (dans mon cas, il contient les questions d'une enquête) et je les imprime. L'enquête est en français et chaque fois que le premier caractère d'une question est un personnage spécial (é, ou, ç, etc.) FGETCSV l'offre simplement.

Les caractères spéciaux au milieu de la valeur ne sont pas affectés uniquement lorsqu'ils sont le premier caractère.

J'ai essayé de déboguer mais je suis déconcerté. J'ai fait un var_dump avec le contenu du fichier et les caractères sont définitivement là:

var_dump(utf8_encode(file_get_contents($_FILES['csv_file']['tmp_name'])));

Et voici mon code:

if(file_exists($_FILES['csv_file']['tmp_name']) && $csv = fopen($_FILES['csv_file']['tmp_name'], "r"))
    {
        $csv_arr = array();

        //Populate an array with all the cells of the CSV file
        while(!feof($csv))
        {
            $csv_arr[] = fgetcsv($csv);
        }

        //Close the file, no longer needed
        fclose($csv);

        // This should cycle through the cells of the first row (questions)
        foreach($csv_arr[0] as $question)
        {
            echo utf8_encode($question) . "<br />";
        }

    }

Answer 1

Avez-vous déjà vérifié le Page manuelle sur FGETCSV? Il n'y a rien qui parle de ce problème spécifique, mais un certain nombre de contributions méritent peut-être de parcourir si rien ne revient ici.

Il y a ceci, par exemple:

Remarque: le paramètre des paramètres régionaux est pris en compte par cette fonction. Si Lang est eg en_us.utf-8, les fichiers en codage à un octet sont mal lus par cette fonction.

De plus, étant donné que c'est toujours au début de la ligne, se pourrait-il que ce soit vraiment un problème de rupture de ligne cachée? Il y a ceci:

Remarque: Si PHP ne reconnaît pas correctement les terminaisons de ligne lors de la lecture de fichiers ou créé par un ordinateur Macintosh, l'activation de l'option de configuration d'exécution Auto_Detect_Line_endings peut aider à résoudre le problème.

Vous pouvez également essayer d'enregistrer le fichier avec différentes fins de ligne.

Answer 2

Définissez-vous correctement votre paramètre local avant d'appeler fgetcsv()?

setlocale(LC_ALL, 'fr_FR.UTF-8');

Autrement, fgetcsv() n'est pas en sécurité multi-octe.

Assurez-vous que vous le définissez sur quelque chose qui apparaît dans votre liste de lieux disponibles. Sur Linux (certainement sur Debian), vous pouvez voir cela en faisant

locale -a

Tu devrais avoir quelque chose comme ...

C
en_US.utf8
POSIX

Pour UTF8 Support, choisissez un encodage avec UTF8 à la fin. Si votre entrée est encodée avec quelque chose d'autre, vous devrez utiliser les paramètres régionaux appropriés - mais assurez-vous que votre système d'exploitation le prend en charge en premier.

Si vous définissez le lieu sur un lieu qui n'est pas disponible sur votre système, il ne vous aidera pas.

Answer 3

Ce comportement a un rapport d'erreur déposé pour cela, mais apparemment n'est pas un bug.

Answer 4

Nous avons vu le même résultat avec LANG mis à C, et a travaillé autour de lui en s'assurant que de telles valeurs étaient enveloppées dans des guillemets. Par exemple, la ligne

a,"a",é,"é",óú,"óú",ó&ú,"ó&ú"

génère le tableau suivant lorsqu'il est passé par fgetcsv():

array (
  0 => 'a',
  1 => 'a',
  2 => '',
  3 => 'é',
  4 => '',
  5 => 'óú',
  6 => '&ú',
  7 => 'ó&ú',
)

Bien sûr, vous devrez échapper à tous les guillemets dans la valeur en les doublant, mais c'est beaucoup moins de tracas que de réparer les personnages manquants.

Curieusement, cela se produit avec les encodages UTF-8 et CP1252 pour le fichier d'entrée.