utf-8
Les codes de plugins et autres contribs devraient être en ascii, pas en
utf-8 ; d'où des é partout (pas beau, mais portable sur des sites
dans n'importe quel charset).
-- Fil
utf-8
Les codes de plugins et autres contribs devraient être en ascii, pas en
utf-8 ; d'où des é partout (pas beau, mais portable sur des sites
dans n'importe quel charset).
-- Fil
Fil a écrit :
utf-8
Les codes de plugins et autres contribs devraient être en ascii, pas en
utf-8 ;
ah bon ?
tu parles de plugin.xml ou des fichiers en general ?
moi j'ai tout basculé en utf-8 pensant bien faire...
d'où des é partout (pas beau, mais portable sur des sites
dans n'importe quel charset).
sinon on a qu'a pas mettre les accents...
![]()
tu parles de plugin.xml ou des fichiers en general ?
des fichiers en général
moi j'ai tout basculé en utf-8 pensant bien faire...
lol
sinon on a qu'a pas mettre les accents...
comme dans les fichiers de langue, quoi...
ou alors on décide que tout est en utf-8 par défaut, et on voncertit à la
volée pour les autres. Mais ça va demander de coder des trucs en plus à pas
mal d'endroits.
-- Fil
Fil a écrit :
moi j'ai tout basculé en utf-8 pensant bien faire...
lol
en fait, j'ai eu pas mal de soucis avec qqun sous mac qui me pourrissait les fichiers à chaque fois qu'il y touchait (sans doute son client FTP)
le probleme ne se posait pas avec les fichiers en utf-8
je croyais qu'au niveau du SVN ca risquait d'etre pareil...
Mais ca ne me pause aucun probleme de repasser en ISO, ca devrait mieux se passer que dans l'autre sens ...
sinon on a qu'a pas mettre les accents...
comme dans les fichiers de langue, quoi...ou alors on décide que tout est en utf-8 par défaut, et on voncertit à la
volée pour les autres. Mais ça va demander de coder des trucs en plus à pas
mal d'endroits.
???
en fait, je ne comprend rien du tout...
si les plugins balancent de l'iso au milieu d'une page utf-8, je vois bien le souci si il y a des é.
Mais l'inverse ne devrait pas poser de probleme, si ?
J'ai encore des sites en iso et spipcarto qui est en utf-8 n'a pas l'air de poser de problemes.
c'est dans quels cas que ca coince ?
@++
ps : désolé, je fais j'arrete pas de me planter d'adresse sortante...
c'est dans quels cas que ca coince ?
ça coince pour un site en iso et un plugin en utf-8, ou pour un site en
utf-8 et un plugin en iso... ça ne coince jamais si le plugin est en ascii
(+entites html ou {![]()
-- Fil
Fil a écrit :
c'est dans quels cas que ca coince ?
ça coince pour un site en iso et un plugin en utf-8, ou pour un site en
utf-8 et un plugin en iso... ça ne coince jamais si le plugin est en ascii
(+entites html ou {
oui d'accord, je viens de comprendre.
mais si on ne met jamais de caracteres speciaux, on a pas le probleme normalement, si ?
de 0 à 127, l'unicode et l'ASCII, c'est pareil, non ?
j'ai fait la convertion de spipcarto en ASCII, le client SVN ne voit pas de changement.
Normalement, il devait y avoir le petit caractere qui dit utf-8 au debut des fichiers avant et plus maintenant, non ?
si oui, vous savez comment on force le commit ?
merci.
@++
mais si on ne met jamais de caracteres speciaux, on a pas le probleme
normalement, si ?
Non, en effet. D'ailleurs dans le code de SPIP on n'a (normalement) aucun
caractère >127.
Normalement, il devait y avoir le petit caractere qui dit utf-8 au debut
des fichiers avant et plus maintenant, non ?
Ah, le BOM : ça il faut absolument éviter, car s'il est présent dans un
fichier (par ex mes_options), il démarre le flux de données, et tu ne peux
plus faire header()... Là je dirais que ça concerne plutôt l'interpréteur
php.
-- Fil
Fil a écrit :
mais si on ne met jamais de caracteres speciaux, on a pas le probleme normalement, si ?
Non, en effet. D'ailleurs dans le code de SPIP on n'a (normalement) aucun
caractère >127.Normalement, il devait y avoir le petit caractere qui dit utf-8 au debut des fichiers avant et plus maintenant, non ?
Ah, le BOM : ça il faut absolument éviter, car s'il est présent dans un
fichier (par ex mes_options), il démarre le flux de données, et tu ne peux
plus faire header()... Là je dirais que ça concerne plutôt l'interpréteur
php.
c'est bon, en fait, mon editeur ne le met pas.
donc c'est normal que la convertion de spip_carto n'ait pas provoqué de changement, n'ayant que des caracteres ASCII dans mes fichiers
Donc la solution, c'est de regler nos editeurs en US-ASCII, comme ca plus de problemes, c'est ca ?
Bill wrote:
Fil a écrit :
moi j'ai tout basculé en utf-8 pensant bien faire...
lol
en fait, j'ai eu pas mal de soucis avec qqun sous mac qui me pourrissait les fichiers à chaque fois qu'il y touchait (sans doute son client FTP)
Je parie qu'elle ou il utilisait dreamweaver.
le probleme ne se posait pas avec les fichiers en utf-8
je croyais qu'au niveau du SVN ca risquait d'etre pareil...
L'encoding est dans le fichier (sans BOM ça se reconnait)
Mais ca ne me pause aucun probleme de repasser en ISO, ca devrait mieux se passer que dans l'autre sens ...
sinon on a qu'a pas mettre les accents...
comme dans les fichiers de langue, quoi...
ou alors on décide que tout est en utf-8 par défaut, et on voncertit à la
volée pour les autres. Mais ça va demander de coder des trucs en plus à pas
mal d'endroits.
???
en fait, je ne comprend rien du tout...
si les plugins balancent de l'iso au milieu d'une page utf-8, je vois bien le souci si il y a des é.
Mais l'inverse ne devrait pas poser de probleme, si ?J'ai encore des sites en iso et spipcarto qui est en utf-8 n'a pas l'air de poser de problemes.
c'est dans quels cas que ca coince ?
cette put1 de directive apache peut tout changer
AddDefaultCharset
moi je mets
AddDefaultCharset off
comme ça c'est le fichier appelé qui détermine
mais si apache force un charset ...
Voilà , fil ne peut pas avoir tort ![]()
Ces directives apache sont du client.
Donc éventuellement ISO (nan pas toi _izo)
Donc on ne peut produire que 7 bits ascii
héhé
vive spip.php6 !
(je rigole pas ... c'est vraiement un gros point de discussion chez php.internal)
(ceux qui on participé au dernier marathon mbstring savent)
Malheur ! qu'on y vienne !
Un langage sans accents est mort.
Rao
--
toggg
Donc la solution, c'est de regler nos editeurs en US-ASCII, comme ca
plus de problemes, c'est ca ?
Non, ce qu'il faut, c'est ne pas mettre d'accents du tout dans le code -- et
donc encoder les accents et autres caractères sous la forme é ou é.
-- Fil