Les contenus en trois langues sont gérés par un seul et même script par
l'intermédiaire de trois bloc de if successifs :
if ($_SESSION["langue"] == "fr") {
bla bla en fr
}
if ($_SESSION["langue"] == "jp") {
bla bla en us
}
if ($_SESSION["langue"] == "jp") {
bla bla en jp avec les signes qui vont bien
}
Je me heurte à un petit souci :
Quand je passe de la langue français ou de la langue anglaise vers le
japonais, il m'arrive souvant d'avoir une page totalement blanche.
Internet Explorer me donne aucune source.
Si j'appuie sur F5 afin de rafraichir la page, celle si s'affiche
correctement.
Quelqu'un aurait il eu ce souci ? Il y a t'il une config particulière au
niveau du PHP
Précision : Suite à des tests le problème ne se pose pas pour des fichiers
HTML classiques.
"loufoque" a écrit dans le message de news: 4253ed9f$0$11986$
Cleo a dit le 06/04/2005 à 15:35:
La SEULE SOLUTION qui reste à ta disposition, est d'utiliser un encodage te permettant d'embarquer toutes les langues c-à-d UTF-8.
Ce n'est pas la seule solution. On peut par exemple utiliser EUC-JP qui est compatible ASCII, et donc on peut alors écrire des bouts de html ou autres éléments globaux en ASCII pour que ça passe sur les deux encodages. Quoique de toutes façons, sjis a quand même un grand bout d'ASCII donc on devrait pouvoir bidouiller et s'en sortir. ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de
trouver un encodage permettant de produire un seul document source (php) et un seul type de flux quelque soit la langue.
On peut aussi, dans une optique plus généraliste, convertir en leur équivalent les données ASCII pour les encodages non ASCII. Tu édites en hexa du coup .. et tu mets quel encodage finalement dans tes
headers ? ... forcement EUC-JP ou UTF-8 pour que le flux soit interprété correctement par le navigateur. Donc autant éditer directement tes sources en EUC-JP ou UTF-8 .
Enfin on peut utiliser des références numériques Unicode dans un document ISO-8859-1 pour insérer n'importe quel caractère sans passer par utf-8. Dans ce cas c'est plus la peine de parler d'encodage ...
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les utiliser directement ?
Voici une page sympa: http://www.thbz.org/japonais/encodages.html
-- Cléo.
"loufoque" <mat.wilmots.remove@nospam.wanadoo.fr> a écrit dans le message de
news: 4253ed9f$0$11986$626a14ce@news.free.fr...
Cleo a dit le 06/04/2005 à 15:35:
La SEULE SOLUTION qui reste à ta disposition, est d'utiliser un encodage
te
permettant d'embarquer toutes les langues c-à-d UTF-8.
Ce n'est pas la seule solution.
On peut par exemple utiliser EUC-JP qui est compatible ASCII, et donc on
peut alors écrire des bouts de html ou autres éléments globaux en ASCII
pour que ça passe sur les deux encodages. Quoique de toutes façons, sjis a
quand même un grand bout d'ASCII donc on devrait pouvoir bidouiller et
s'en sortir.
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de
trouver un encodage permettant de produire un seul document source (php) et
un seul type de flux quelque soit la langue.
On peut aussi, dans une optique plus généraliste, convertir en leur
équivalent les données ASCII pour les encodages non ASCII.
Tu édites en hexa du coup .. et tu mets quel encodage finalement dans tes
headers ?
... forcement EUC-JP ou UTF-8 pour que le flux soit interprété correctement
par le navigateur.
Donc autant éditer directement tes sources en EUC-JP ou UTF-8 .
Enfin on peut utiliser des références numériques Unicode dans un document
ISO-8859-1 pour insérer n'importe quel caractère sans passer par utf-8.
Dans ce cas c'est plus la peine de parler d'encodage ...
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines
entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les
utiliser directement ?
Voici une page sympa:
http://www.thbz.org/japonais/encodages.html
"loufoque" a écrit dans le message de news: 4253ed9f$0$11986$
Cleo a dit le 06/04/2005 à 15:35:
La SEULE SOLUTION qui reste à ta disposition, est d'utiliser un encodage te permettant d'embarquer toutes les langues c-à-d UTF-8.
Ce n'est pas la seule solution. On peut par exemple utiliser EUC-JP qui est compatible ASCII, et donc on peut alors écrire des bouts de html ou autres éléments globaux en ASCII pour que ça passe sur les deux encodages. Quoique de toutes façons, sjis a quand même un grand bout d'ASCII donc on devrait pouvoir bidouiller et s'en sortir. ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de
trouver un encodage permettant de produire un seul document source (php) et un seul type de flux quelque soit la langue.
On peut aussi, dans une optique plus généraliste, convertir en leur équivalent les données ASCII pour les encodages non ASCII. Tu édites en hexa du coup .. et tu mets quel encodage finalement dans tes
headers ? ... forcement EUC-JP ou UTF-8 pour que le flux soit interprété correctement par le navigateur. Donc autant éditer directement tes sources en EUC-JP ou UTF-8 .
Enfin on peut utiliser des références numériques Unicode dans un document ISO-8859-1 pour insérer n'importe quel caractère sans passer par utf-8. Dans ce cas c'est plus la peine de parler d'encodage ...
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les utiliser directement ?
Voici une page sympa: http://www.thbz.org/japonais/encodages.html
-- Cléo.
loufoque
Cleo a dit le 06/04/2005 à 18:00:
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de trouver un encodage permettant de produire un seul document source (php) et un seul type de flux quelque soit la langue.
EUC-JP ne contient pas l'ensemble des caractères latins, seulement ASCII. Et puis si on choisit EUC-JP plutôt qu'UTF-8, c'est parce que le rendu au final est souvent moins long (on octets) pour du japonais.
Tu édites en hexa du coup .. et tu mets quel encodage finalement dans tes headers ? ... forcement EUC-JP ou UTF-8 pour que le flux soit interprété correctement par le navigateur. Donc autant éditer directement tes sources en EUC-JP ou UTF-8 .
Tu n'as pas du comprendre ce que je veux dire. Il suffit de faire convertToCharset('<balise attribut="valeur">Truc bidule') au lieu d'afficher directement, la fonction convertissant l'ASCII en truc qui correspond dans Shift_JIS par exemple. Ecrire en dur en Shift_JIS n'est pas possible, PHP ne le supporte pas à part on convertissant avec mbstring. iconv et compagnie font le boulot sans problème.
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les utiliser directement ?
En POST, les navigateurs envoient les caractères en dehors du charset courant avec des références numériques Unicode. D'ailleurs ce qui est énervant, c'est que du coup il n'y a aucun moyen de faire la différence entre la référence et le caractère réellement tapé. Attention par contre, beaucoup font la confusion entre latin-1 et windows-1252.
Cleo a dit le 06/04/2005 à 18:00:
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de
trouver un encodage permettant de produire un seul document source (php) et
un seul type de flux quelque soit la langue.
EUC-JP ne contient pas l'ensemble des caractères latins, seulement ASCII.
Et puis si on choisit EUC-JP plutôt qu'UTF-8, c'est parce que le rendu
au final est souvent moins long (on octets) pour du japonais.
Tu édites en hexa du coup .. et tu mets quel encodage finalement dans tes
headers ?
... forcement EUC-JP ou UTF-8 pour que le flux soit interprété correctement
par le navigateur.
Donc autant éditer directement tes sources en EUC-JP ou UTF-8 .
Tu n'as pas du comprendre ce que je veux dire.
Il suffit de faire
convertToCharset('<balise attribut="valeur">Truc bidule') au lieu
d'afficher directement, la fonction convertissant l'ASCII en truc qui
correspond dans Shift_JIS par exemple.
Ecrire en dur en Shift_JIS n'est pas possible, PHP ne le supporte pas à
part on convertissant avec mbstring.
iconv et compagnie font le boulot sans problème.
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines
entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les
utiliser directement ?
En POST, les navigateurs envoient les caractères en dehors du charset
courant avec des références numériques Unicode. D'ailleurs ce qui est
énervant, c'est que du coup il n'y a aucun moyen de faire la différence
entre la référence et le caractère réellement tapé.
Attention par contre, beaucoup font la confusion entre latin-1 et
windows-1252.
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de trouver un encodage permettant de produire un seul document source (php) et un seul type de flux quelque soit la langue.
EUC-JP ne contient pas l'ensemble des caractères latins, seulement ASCII. Et puis si on choisit EUC-JP plutôt qu'UTF-8, c'est parce que le rendu au final est souvent moins long (on octets) pour du japonais.
Tu édites en hexa du coup .. et tu mets quel encodage finalement dans tes headers ? ... forcement EUC-JP ou UTF-8 pour que le flux soit interprété correctement par le navigateur. Donc autant éditer directement tes sources en EUC-JP ou UTF-8 .
Tu n'as pas du comprendre ce que je veux dire. Il suffit de faire convertToCharset('<balise attribut="valeur">Truc bidule') au lieu d'afficher directement, la fonction convertissant l'ASCII en truc qui correspond dans Shift_JIS par exemple. Ecrire en dur en Shift_JIS n'est pas possible, PHP ne le supporte pas à part on convertissant avec mbstring. iconv et compagnie font le boulot sans problème.
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les utiliser directement ?
En POST, les navigateurs envoient les caractères en dehors du charset courant avec des références numériques Unicode. D'ailleurs ce qui est énervant, c'est que du coup il n'y a aucun moyen de faire la différence entre la référence et le caractère réellement tapé. Attention par contre, beaucoup font la confusion entre latin-1 et windows-1252.
Cleo
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de trouver un encodage permettant de produire un seul document source (php) et un seul type de flux quelque soit la langue. Pardon pas UTF-16, car le parser php serait aux fraises ...
Enfin on peut utiliser des références numériques Unicode dans un document ISO-8859-1 pour insérer n'importe quel caractère sans passer par utf-8. Dans ce cas c'est plus la peine de parler d'encodage ...
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les utiliser directement ?
Pour terminer sur cette partie, si tu utilises un encodage ISO-8859-1 pour ta page, tu imposes indirectement que le navigateur envoie les informations de post suivant ce même encodage. Ce qui interdit, pour notre ami, toute saisie d'informations par ces clients japonais.
-- Cléo.
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de
trouver un encodage permettant de produire un seul document source (php)
et un seul type de flux quelque soit la langue.
Pardon pas UTF-16, car le parser php serait aux fraises ...
Enfin on peut utiliser des références numériques Unicode dans un document
ISO-8859-1 pour insérer n'importe quel caractère sans passer par utf-8.
Dans ce cas c'est plus la peine de parler d'encodage ...
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines
entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les
utiliser directement ?
Pour terminer sur cette partie, si tu utilises un encodage ISO-8859-1 pour
ta page, tu imposes indirectement que le navigateur envoie les informations
de post suivant ce même encodage. Ce qui interdit, pour notre ami, toute
saisie d'informations par ces clients japonais.
ok EUC-JP, UTF-8 ou UTF-16 ... ça change pas grand chose, le but étant de trouver un encodage permettant de produire un seul document source (php) et un seul type de flux quelque soit la langue. Pardon pas UTF-16, car le parser php serait aux fraises ...
Enfin on peut utiliser des références numériques Unicode dans un document ISO-8859-1 pour insérer n'importe quel caractère sans passer par utf-8. Dans ce cas c'est plus la peine de parler d'encodage ...
Mais pour ce qui est du contenu dynamique, tu vas stocker les chaines entrées par nos amis japonais sous la forme U+XXXX, pour pouvoir les utiliser directement ?
Pour terminer sur cette partie, si tu utilises un encodage ISO-8859-1 pour ta page, tu imposes indirectement que le navigateur envoie les informations de post suivant ce même encodage. Ce qui interdit, pour notre ami, toute saisie d'informations par ces clients japonais.
-- Cléo.
Olivier Miakinen
Salut, après quelques recherches il ressort que: - iso-8859-1 est en encodage monooctet (1glyph = 1octet) - Shift_JIS est en encodage multioctets (1glyph = 2octets)
Sauf que les caractères ASCII sont représentés sur un seul octet, comme indiqué sur la page dont tu as toi-même donné le lien : <http://www.thbz.org/japonais/encodages.html>.
[...]
Mais tu abortis finalement à une impasse car, en faisant ça, tout le flux que tu transmets doit être encodé comme indiqué, y compris la structure du document HTML, ce qui n'est pas le cas vu ta façon de procéder.
... il n'y a donc pas de problème insurmontable. Mais il n'empêche que c'est quand même plus propre d'envoyer les bons entêtes HTTP, ce qu'il est si facile de faire en PHP.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Salut, après quelques recherches il ressort que:
- iso-8859-1 est en encodage monooctet (1glyph = 1octet)
- Shift_JIS est en encodage multioctets (1glyph = 2octets)
Sauf que les caractères ASCII sont représentés sur un seul octet, comme
indiqué sur la page dont tu as toi-même donné le lien :
<http://www.thbz.org/japonais/encodages.html>.
[...]
Mais tu abortis finalement à une impasse car, en faisant ça, tout le flux
que tu transmets doit être encodé comme indiqué, y compris la structure du
document HTML, ce qui n'est pas le cas vu ta façon de procéder.
... il n'y a donc pas de problème insurmontable. Mais il n'empêche que
c'est quand même plus propre d'envoyer les bons entêtes HTTP, ce qu'il
est si facile de faire en PHP.
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Salut, après quelques recherches il ressort que: - iso-8859-1 est en encodage monooctet (1glyph = 1octet) - Shift_JIS est en encodage multioctets (1glyph = 2octets)
Sauf que les caractères ASCII sont représentés sur un seul octet, comme indiqué sur la page dont tu as toi-même donné le lien : <http://www.thbz.org/japonais/encodages.html>.
[...]
Mais tu abortis finalement à une impasse car, en faisant ça, tout le flux que tu transmets doit être encodé comme indiqué, y compris la structure du document HTML, ce qui n'est pas le cas vu ta façon de procéder.
... il n'y a donc pas de problème insurmontable. Mais il n'empêche que c'est quand même plus propre d'envoyer les bons entêtes HTTP, ce qu'il est si facile de faire en PHP.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Cleo
Sauf que les caractères ASCII sont représentés sur un seul octet, comme indiqué sur la page dont tu as toi-même donné le lien : <http://www.thbz.org/japonais/encodages.html>.
Tu as raison, la première doc sur laquelle je me suis appuyée pour donner la réponse, définissait que chaque caractère de Shift-JIS était codé sur 2octets alors que c'est faux ...
... il n'y a donc pas de problème insurmontable. Mais il n'empêche que c'est quand même plus propre d'envoyer les bons entêtes HTTP, ce qu'il est si facile de faire en PHP.
Non rien d'insurmontable, mais il est plus simple de travailler dans le codepage envoyé ...
-- Cléo.
Sauf que les caractères ASCII sont représentés sur un seul octet, comme
indiqué sur la page dont tu as toi-même donné le lien :
<http://www.thbz.org/japonais/encodages.html>.
Tu as raison, la première doc sur laquelle je me suis appuyée pour donner la
réponse, définissait que chaque caractère de Shift-JIS était codé sur
2octets alors que c'est faux ...
... il n'y a donc pas de problème insurmontable. Mais il n'empêche que
c'est quand même plus propre d'envoyer les bons entêtes HTTP, ce qu'il
est si facile de faire en PHP.
Non rien d'insurmontable, mais il est plus simple de travailler dans le
codepage envoyé ...
Sauf que les caractères ASCII sont représentés sur un seul octet, comme indiqué sur la page dont tu as toi-même donné le lien : <http://www.thbz.org/japonais/encodages.html>.
Tu as raison, la première doc sur laquelle je me suis appuyée pour donner la réponse, définissait que chaque caractère de Shift-JIS était codé sur 2octets alors que c'est faux ...
... il n'y a donc pas de problème insurmontable. Mais il n'empêche que c'est quand même plus propre d'envoyer les bons entêtes HTTP, ce qu'il est si facile de faire en PHP.
Non rien d'insurmontable, mais il est plus simple de travailler dans le codepage envoyé ...
-- Cléo.
Joe
On 07 Apr 2005 17:57:47 GMT, Cleo wrote:
Tu as raison, la première doc sur laquelle je me suis appuyée pour donner la réponse, définissait que chaque caractère de Shift-JIS était codé sur 2octets alors que c'est faux ...
Et encore... Shift-JIS, c'est l'encodage sous Windows et Mac, mais on trouve aussi EUC (plutôt Unix) et JIS (codage en 7bits avec séquences IN/OUT pour indiquer les parties en japonais vs. parties en ASCII).
On 07 Apr 2005 17:57:47 GMT, Cleo <cleo@no-spam.org> wrote:
Tu as raison, la première doc sur laquelle je me suis appuyée pour donner la
réponse, définissait que chaque caractère de Shift-JIS était codé sur
2octets alors que c'est faux ...
Et encore... Shift-JIS, c'est l'encodage sous Windows et Mac, mais on
trouve aussi EUC (plutôt Unix) et JIS (codage en 7bits avec séquences
IN/OUT pour indiquer les parties en japonais vs. parties en ASCII).
Tu as raison, la première doc sur laquelle je me suis appuyée pour donner la réponse, définissait que chaque caractère de Shift-JIS était codé sur 2octets alors que c'est faux ...
Et encore... Shift-JIS, c'est l'encodage sous Windows et Mac, mais on trouve aussi EUC (plutôt Unix) et JIS (codage en 7bits avec séquences IN/OUT pour indiquer les parties en japonais vs. parties en ASCII).
En POST, les navigateurs envoient les caractères en dehors du charset courant avec des références numériques Unicode. D'ailleurs ce qui est énervant, c'est que du coup il n'y a aucun moyen de faire la différence entre la référence et le caractère réellement tapé. Attention par contre, beaucoup font la confusion entre latin-1 et windows-1252. Tu as raison les caractères hors codepage défini dans le header sont envoyés
sous la forme &#ddddd; (ou ddddd est code unicode décimal du caractère).
Il n'empèche que le plus simple et d'avoir ses sources dans un codepage supportant la/les langues du client final et ASCII pour que l'interpréteur PHP retrouve ses petits. Pour aller jusqu'au bout du raisonnement si vous êtes souvent amenés à coder des sites multilingues ou même directement, le choix de l'UTF-8 s'impose car - compatible ASCII donc parsable - supporte toutes les langues donc pas besoin de iconv, mb_string, et pas de retranscription en &#ddddd; (qui est, quand même, un code HTML dans un flux texte !!!)
Il suffit de - Trouvez un éditeur de code UTF-8, (ex: phpeclipse) - Ajoutez: header("Content-type: text/html; charset="UTF-8") en début de page. - Passer l'encodage à certaines fonctions comme htmlentities qui par défault fonctionnent en ISO-8859-1 - Gérer le stockage en utf-8. (ex: character set utf8 | collation utf8_general_ci | pour de UTF-8 Unicode dans mysql) Et le tour est joué ...
Pour le reste, je ne pense pas que "se prendre la tête à chaque ligne" à savoir si on doit encoder cette ligne ou pas, facilite le travail. C'est possible bien sûr mais ça me parait être du bricolage (ou du travail de précision) alors même qu'on a à disposition tous les moyens pour nous simplifier la vie.
-- Cléo.
En POST, les navigateurs envoient les caractères en dehors du charset
courant avec des références numériques Unicode. D'ailleurs ce qui est
énervant, c'est que du coup il n'y a aucun moyen de faire la différence
entre la référence et le caractère réellement tapé.
Attention par contre, beaucoup font la confusion entre latin-1 et
windows-1252.
Tu as raison les caractères hors codepage défini dans le header sont envoyés
sous la forme &#ddddd; (ou ddddd est code unicode décimal du caractère).
Il n'empèche que le plus simple et d'avoir ses sources dans un codepage
supportant la/les langues du client final et ASCII pour que l'interpréteur
PHP retrouve ses petits. Pour aller jusqu'au bout du raisonnement si vous
êtes souvent amenés à coder des sites multilingues ou même directement, le
choix de l'UTF-8 s'impose car
- compatible ASCII donc parsable
- supporte toutes les langues donc pas besoin de iconv, mb_string, et pas de
retranscription en &#ddddd; (qui est, quand même, un code HTML dans un flux
texte !!!)
Il suffit de
- Trouvez un éditeur de code UTF-8, (ex: phpeclipse)
- Ajoutez: header("Content-type: text/html; charset="UTF-8") en début de
page.
- Passer l'encodage à certaines fonctions comme htmlentities qui par défault
fonctionnent en ISO-8859-1
- Gérer le stockage en utf-8. (ex: character set utf8 | collation
utf8_general_ci | pour de UTF-8 Unicode dans mysql)
Et le tour est joué ...
Pour le reste, je ne pense pas que "se prendre la tête à chaque ligne" à
savoir si on doit encoder cette ligne ou pas, facilite le travail. C'est
possible bien sûr mais ça me parait être du bricolage (ou du travail de
précision) alors même qu'on a à disposition tous les moyens pour nous
simplifier la vie.
En POST, les navigateurs envoient les caractères en dehors du charset courant avec des références numériques Unicode. D'ailleurs ce qui est énervant, c'est que du coup il n'y a aucun moyen de faire la différence entre la référence et le caractère réellement tapé. Attention par contre, beaucoup font la confusion entre latin-1 et windows-1252. Tu as raison les caractères hors codepage défini dans le header sont envoyés
sous la forme &#ddddd; (ou ddddd est code unicode décimal du caractère).
Il n'empèche que le plus simple et d'avoir ses sources dans un codepage supportant la/les langues du client final et ASCII pour que l'interpréteur PHP retrouve ses petits. Pour aller jusqu'au bout du raisonnement si vous êtes souvent amenés à coder des sites multilingues ou même directement, le choix de l'UTF-8 s'impose car - compatible ASCII donc parsable - supporte toutes les langues donc pas besoin de iconv, mb_string, et pas de retranscription en &#ddddd; (qui est, quand même, un code HTML dans un flux texte !!!)
Il suffit de - Trouvez un éditeur de code UTF-8, (ex: phpeclipse) - Ajoutez: header("Content-type: text/html; charset="UTF-8") en début de page. - Passer l'encodage à certaines fonctions comme htmlentities qui par défault fonctionnent en ISO-8859-1 - Gérer le stockage en utf-8. (ex: character set utf8 | collation utf8_general_ci | pour de UTF-8 Unicode dans mysql) Et le tour est joué ...
Pour le reste, je ne pense pas que "se prendre la tête à chaque ligne" à savoir si on doit encoder cette ligne ou pas, facilite le travail. C'est possible bien sûr mais ça me parait être du bricolage (ou du travail de précision) alors même qu'on a à disposition tous les moyens pour nous simplifier la vie.
-- Cléo.
Cleo
Il n'empèche que le plus simple EST d'avoir ses sources dans un codepage
oups, je suis rouge de honte ...
-- Cléo.
Il n'empèche que le plus simple EST d'avoir ses sources dans un codepage
