Gotcha a écrit:
Whiler a écrit:
En fait.. je le vois aussi correctement depuis cette page...
http://piwigo.org/dev/browser/extension … v=head#L36
Ce serait pas chez toi ? (allez... dis oui)Sur le serveur de développement, il n'est pas possible de contrôler en ligne le codage des fichiers. Ils peuvent s'afficher correctement mais être "mal" encodés.
Mais par contre, via SVN, vu que l'on a accès directement (moyennent les autorisations) aux fichiers, j'ai contrôlé que le fichier était bien en UTF8 sans BOM. C'est donc ok.
C'est un peu annexe au questionnement en cours, mais je viens juste de remarquer qu'au moins main.inc.php n'est pas en UTF-8 sans BOM. Je vérifie le reste et, sauf avis contraire, commite tout ce que je trouve en ANSI au format UTF8 sans BOM. (Ça m'aidera à réfléchir aussi...)
Et je convertis les sauts de ligne au format UNIX aussi, je crois que c'était préférable.
Dernière modification par LucMorizur (2010-12-20 22:38:23)
Hors ligne
LucMorizur a écrit:
C'est un peu annexe au questionnement en cours, mais je viens juste de remarquer qu'au moins main.inc.php n'est pas en UTF-8 sans BOM.
???
Bah non, pour moi il (main.inc.php) est bien au format UTF8 sans BOM avec des fins de ligne au format Unix...
Dernière modification par Eric (2010-12-20 22:39:44)
Hors ligne
Eric a écrit:
LucMorizur a écrit:
C'est un peu annexe au questionnement en cours, mais je viens juste de remarquer qu'au moins main.inc.php n'est pas en UTF-8 sans BOM.
???
Bah non, pour moi il (main.inc.php) est bien au format UTF8 sans BOM avec des fins de ligne au format Unix...
Ah ben zut alors... on n'avait pas besoin de ça |-( ...
Hors ligne
Bon, c'est bizarre ; je change rien, ça n'a pas d'importance pour le moment.
Enfin, je crois.
Hors ligne
Par contre ../admin/LCAS_admin.php et ../language/en_UK/plugin.lang.php sont bien en ANSI au lieu de UTF8 pour moi. Tu confirmes ?
Hors ligne
Eric a écrit:
Par contre ../admin/LCAS_admin.php et ../language/en_UK/plugin.lang.php sont bien en ANSI au lieu de UTF8 pour moi. Tu confirmes ?
Euh, trop tard... je les ai déjà modifiés :-/ ...
Mais j'en avais bien un certain nombre qui n'étaient pas en UTF8 sans BOM.
J'avais l'intention de les sauvegarder ailleurs, histoire de pas perturber, et de regarder plus précisément à un prochain téléchargement. Je te tiendrai au courant.
Là, je vais pouvoir éteindre la télé et réfléchir deux minutes pour de vrai avant de m'endormir......
En tous cas chez moi aucun fichier de LCAS n'a de retour chariot UNIX.
Dernière modification par LucMorizur (2010-12-20 23:00:28)
Hors ligne
Oups au fait, attention ! Pour qu'un fichier reste codé en UTF-8 sans BOM, il faut que certains caractères soient présents ! Voir [Forum, post 125076 by LucMorizur in topic 15641] Préparation plugin Event Cats (ça nous rajeunit pas ;-) !).
Dans tous les fichiers de [extension by LucMorizur] Event Cats, j'ai le texte suivant en commentaire :
Keeps file coded in UTF-8 without BOM: é
:-/ ....
Hors ligne
Bon, j'avais une autre copie de LCAS dans un autre dossier, et main.inc.php était bien en UTF-8 sans BOM, je sais pas ce que j'ai fichu. Mais par contre, je persiste : aucun retour chariot UNIX
Eric a écrit:
Par contre ../admin/LCAS_admin.php et ../language/en_UK/plugin.lang.php sont bien en ANSI au lieu de UTF8 pour moi. Tu confirmes ?
Et oui, là je confirme pour ces deux-là.
Par contre, ce que j'évoquais il y a un an, ne se reproduit plus : un fichier ne comportant aucun caractère spécial, sauvegardé en UTF-8 sans BOM reste maintenant tel quel. Alors qu'il y a un an, ce n'était pas le cas, je me souviens vraiment des tests. Pour moi, quelque chose a dû changer dans Notepad++...
Bref............
Hors ligne
LucMorizur a écrit:
Je propose de créer une table <pwg>_LCAS (...)
Je crois que j'ai trouvé mieux :-)) : normalement avec mon commit de ce soir ([Subversion] r8207), l'identification fonctionne pour chacun des quatre cas.
Sinon il y avait un bug (si !) :
le cas 0 est bien casse sensible, accents sensibles ;
le cas 1 est bien casse insensible, accents sensibles ;
mais le cas 2 était en fait casse insensible, accents insensibles, et
3 casse sensible, accents insensibles.
:-)
Allez bonne nuit !
Dernière modification par LucMorizur (2010-12-21 01:01:43)
Hors ligne
LucMorizur a écrit:
Bon, j'avais une autre copie de LCAS dans un autre dossier, et main.inc.php était bien en UTF-8 sans BOM, je sais pas ce que j'ai fichu. Mais par contre, je persiste : aucun retour chariot UNIX
Eric a écrit:
Par contre ../admin/LCAS_admin.php et ../language/en_UK/plugin.lang.php sont bien en ANSI au lieu de UTF8 pour moi. Tu confirmes ?
Et oui, là je confirme pour ces deux-là.
Par contre, ce que j'évoquais il y a un an, ne se reproduit plus : un fichier ne comportant aucun caractère spécial, sauvegardé en UTF-8 sans BOM reste maintenant tel quel. Alors qu'il y a un an, ce n'était pas le cas, je me souviens vraiment des tests. Pour moi, quelque chose a dû changer dans Notepad++...
Bref............
un fichier sans caractère éàè... repasse en ANSI quand tu l'ouvres
Hors ligne
LucMorizur a écrit:
LucMorizur a écrit:
Je propose de créer une table <pwg>_LCAS (...)
Je crois que j'ai trouvé mieux :-)) : normalement avec mon commit de ce soir ([Subversion] r8207), l'identification fonctionne pour chacun des quatre cas.
Sinon il y avait un bug (si !) :
le cas 0 est bien casse sensible, accents sensibles ;
le cas 1 est bien casse insensible, accents sensibles ;
mais le cas 2 était en fait casse insensible, accents insensibles, et
3 casse sensible, accents insensibles.
:-)
Allez bonne nuit !
J'ai testé sur mon environnement et cela fonctionne parfaitement... Cependant, le tableau dans la page d'admin n'affichait plus les bons résultats.. j'ai modifié les constantes dans la page d'admin afin qu'il utilise les bonnes constantes...
Hors ligne
LucMorizur a écrit:
Bon, j'avais une autre copie de LCAS dans un autre dossier, et main.inc.php était bien en UTF-8 sans BOM, je sais pas ce que j'ai fichu. Mais par contre, je persiste : aucun retour chariot UNIX
Eric a écrit:
Par contre ../admin/LCAS_admin.php et ../language/en_UK/plugin.lang.php sont bien en ANSI au lieu de UTF8 pour moi. Tu confirmes ?
Et oui, là je confirme pour ces deux-là.
Par contre, ce que j'évoquais il y a un an, ne se reproduit plus : un fichier ne comportant aucun caractère spécial, sauvegardé en UTF-8 sans BOM reste maintenant tel quel. Alors qu'il y a un an, ce n'était pas le cas, je me souviens vraiment des tests. Pour moi, quelque chose a dû changer dans Notepad++...
Bref............
C'est l'utilisation de Notepad++ qui impose l'ajout de caractères. Personnellement, j'utilise PhpDesigner qui est un éditeur dédié mais payant. Il permet de basculer l'encodage des fichiers comme on le souhaite.
Pour le format Unix, autant pour moi, c'était pour les fichiers sur ma galerie de test que je n'ai pas commité sur le SVN. Donc UTF8 sans Bom et format Windows. ;-)
Hors ligne
LucMorizur a écrit:
LucMorizur a écrit:
Je propose de créer une table <pwg>_LCAS (...)
Je crois que j'ai trouvé mieux :-)) : normalement avec mon commit de ce soir ([Subversion] r8207), l'identification fonctionne pour chacun des quatre cas.
Sinon il y avait un bug (si !) :
le cas 0 est bien casse sensible, accents sensibles ;
le cas 1 est bien casse insensible, accents sensibles ;
mais le cas 2 était en fait casse insensible, accents insensibles, et
3 casse sensible, accents insensibles.
:-)
Allez bonne nuit !
Je testerai ce soir. Mais, à première vue, çà m'a l'air de coller...
Hors ligne
Eric a écrit:
Je testerai ce soir. Mais, à première vue, çà m'a l'air de coller...
Testé et approuvé. Bien joué messieurs !
[Bugtracker] ticket 2069 ;-)
Ce sera tout pour moi, ce soir. A demain !
Hors ligne
ddtddt a écrit:
un fichier sans caractère éàè... repasse en ANSI quand tu l'ouvres
Ça, c'est le comportement que je décrivais il y a un an. Depuis lors, je mettais toujours de tels caractères dans mes fichiers -- j'en traitais pas non plus une tonne, il s'agissait toujours de Event Cats.
Hier soir, j'ai testé, je n'ai plus le même comportement ! Je sauvegarde en UTF-8 sans BOM un fichier ne comportant que "Test (retour chariot) Test", et lorsque je l'ouvre à nouveau, eh bien il est toujours en UTF-8 sans BOM ! Si on ne peut même plus se fier aux bugs :-/ ...
Je recevrais volontiers une confirmation ou une infirmation :-| .
Hors ligne