Export CSV conflit ";" with "cases cochées = 0;0;1;0" (Bug #520)

Lorsqu'on exporte les résultats en CSV, on a l'option de choisir "inclure les cases cochées" et ce en deux formats :

• ABD
• 1;1;0;1

Cependant, lors de l'export vers CSV, ";" est déjà le séparateur part défaut. Donc si on a deux questions à 5 choix on aurait par exemple :

• (encodage ABCD)

Q1;TICKED:Q1;Q2:TICKED;Q2
2;AB;7;AC

Une grille de 2 lignes et 4 colonnes comme attendu.

• (encodage 0;1;0;1)

Q1;TICKED:Q1;Q2:TICKED;Q2
2;1;1;0;0;0;7;1;0;1;0;0

Cela n'est pas vraiment un csv dans le format attendu, on a une grille de 2 lignes et 12 colonnes, avec des cases vides.

• Une solution est donc d'utiliser "," comme séparateur :

Q1,TICKED:Q1,Q2:TICKED,Q2
2,1,1;0;0;0,7,1;0;1;0;0

Cela est déjà possible dans l'interface graphique.
Cependant, cela peut clasher avec les "," du délimiteur décimal.

• Une autre solution serait de mettre les champs entre guillemets.

Q1;TICKED:Q1;Q2:TICKED;Q2
2;"1,1;0;0;0";7;"1;0;1;0;0" 

• ou d'encoder 0;1;0;1 en 0101, ce qui est une mauvaise idée car pourrait être confondu avec l'entier 101,
• ou d'utiliser autre chose que 0 et 1, comme TFTFF (pour True False). Cependant pour un non anglophone la convention serait étonnante.

Je fais remarquer que Microsoft Excel utilise "," comme séparateur avec guillemets quand nécessaire par défaut, avoir donc par défaut ce choix serait naturel pour les utilisateurs de Microsoft Excel (la majorité des utilisateurs ?).
En effet, les utilisateurs de OpenOffice choisiront plutôt le format ods.

Je signale en passant que l'encodage AB se limite à 26 caractères, je pense que AMC devrait refuser d'exporter un projet dans ce format si le test a une question avec plus de 26 choix.
À la place de refuser d'exporter, il pourrait émettre un warning.
Ce cas est rare mais il nous est arrivé de l'avoir lorsque nous utilisons AMC à l'université.
Actuellement, il continue "dans les ascii" et après "dans les unicode" mais cela pourrait créer des problèmes d'encodage.