Tout a coup un script foire avec l'erreur "headers already sent by line 1".
Je recherche : pas d'espace au debut du script.
Je le reduit a ça et toujours la même erreur:
<?php header("Content-Length: 250"); ?>
J'ai l'impression que ca vient du transfert encoding chunked qui envoi au
debut la taille des données. J'ai regarde la FAQ qui ne parle pas de ce
probleme.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Tout a coup un script foire avec l'erreur "headers already sent by line 1". Je recherche : pas d'espace au debut du script. Je le reduit a ça et toujours la même erreur: <?php header("Content-Length: 250"); ?>
Quelqu'un a eu le problème récemment avec un script en UTF-8. J'avais suggéré que le fichier était peut-être sauvé avec un « Byte-Order Mark » (BOM) quoique ce soit parfaitement stupide pour de l'UTF-8, et en effet c'était bien le cas.
Ne serait-ce pas la même chose pour toi ?
J'ai l'impression que ca vient du transfert encoding chunked qui envoi au debut la taille des données.
Je n'en crois rien (toutes mes pages semblent utiliser la même chose sans aucun problème).
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Tout a coup un script foire avec l'erreur "headers already sent by line 1".
Je recherche : pas d'espace au debut du script.
Je le reduit a ça et toujours la même erreur:
<?php header("Content-Length: 250"); ?>
Quelqu'un a eu le problème récemment avec un script en UTF-8. J'avais
suggéré que le fichier était peut-être sauvé avec un « Byte-Order Mark »
(BOM) quoique ce soit parfaitement stupide pour de l'UTF-8, et en effet
c'était bien le cas.
Ne serait-ce pas la même chose pour toi ?
J'ai l'impression que ca vient du transfert encoding chunked qui envoi au
debut la taille des données.
Je n'en crois rien (toutes mes pages semblent utiliser la même chose
sans aucun problème).
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Tout a coup un script foire avec l'erreur "headers already sent by line 1". Je recherche : pas d'espace au debut du script. Je le reduit a ça et toujours la même erreur: <?php header("Content-Length: 250"); ?>
Quelqu'un a eu le problème récemment avec un script en UTF-8. J'avais suggéré que le fichier était peut-être sauvé avec un « Byte-Order Mark » (BOM) quoique ce soit parfaitement stupide pour de l'UTF-8, et en effet c'était bien le cas.
Ne serait-ce pas la même chose pour toi ?
J'ai l'impression que ca vient du transfert encoding chunked qui envoi au debut la taille des données.
Je n'en crois rien (toutes mes pages semblent utiliser la même chose sans aucun problème).
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Thierry
Olivier Miakinen <om+ écrivait news:45b7ed23$:
Quelqu'un a eu le problème récemment avec un script en UTF-8.
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu. A moins que ce soit FileZilla qu'a fait du zele...
Quelqu'un a eu le problème récemment avec un script en UTF-8.
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu. A moins que ce soit FileZilla qu'a fait du zele...
Merci beaucoup.
A ce sujet, commet fait on pour connaitre le charset d'un ou de plusieurs fichiers textes simplement ?
Olivier Miakinen
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu. A moins que ce soit FileZilla qu'a fait du zele...
A ce sujet, commet fait on pour connaitre le charset d'un ou de plusieurs fichiers textes simplement ?
Pour un texte qu'on a soi-même écrit : au moment de le sauver, on fait gaffe au jeu de caractères dans lequel l'éditeur envisage de l'écrire.
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de caractères donné, on regarde s'il est lisible ou non. Si oui, c'est qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner quel *autre* jeu de caractères cela pourrait être.
Par exemple, si chaque caractère accentué d'un texte en français se retrouve transformé en deux caractères quand on le lit avec un jeu mono-octet, les lettres non accentuées restant lisibles, on peut supposer que qu'on a affaire à de l'UTF-8. Ceci est particulièrement vrai si on l'a lu comme si c'était de l'ISO-8859-1 ou du cp1252, et que le premier caractère de chaque paire est un Â, un à ou un Å.
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu.
A moins que ce soit FileZilla qu'a fait du zele...
A ce sujet, commet fait on pour connaitre le charset d'un ou de
plusieurs fichiers textes simplement ?
Pour un texte qu'on a soi-même écrit : au moment de le sauver, on fait
gaffe au jeu de caractères dans lequel l'éditeur envisage de l'écrire.
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de
caractères donné, on regarde s'il est lisible ou non. Si oui, c'est
qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner
quel *autre* jeu de caractères cela pourrait être.
Par exemple, si chaque caractère accentué d'un texte en français se
retrouve transformé en deux caractères quand on le lit avec un jeu
mono-octet, les lettres non accentuées restant lisibles, on peut
supposer que qu'on a affaire à de l'UTF-8. Ceci est particulièrement
vrai si on l'a lu comme si c'était de l'ISO-8859-1 ou du cp1252, et
que le premier caractère de chaque paire est un Â, un à ou un Å.
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu. A moins que ce soit FileZilla qu'a fait du zele...
A ce sujet, commet fait on pour connaitre le charset d'un ou de plusieurs fichiers textes simplement ?
Pour un texte qu'on a soi-même écrit : au moment de le sauver, on fait gaffe au jeu de caractères dans lequel l'éditeur envisage de l'écrire.
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de caractères donné, on regarde s'il est lisible ou non. Si oui, c'est qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner quel *autre* jeu de caractères cela pourrait être.
Par exemple, si chaque caractère accentué d'un texte en français se retrouve transformé en deux caractères quand on le lit avec un jeu mono-octet, les lettres non accentuées restant lisibles, on peut supposer que qu'on a affaire à de l'UTF-8. Ceci est particulièrement vrai si on l'a lu comme si c'était de l'ISO-8859-1 ou du cp1252, et que le premier caractère de chaque paire est un Â, un à ou un Å.
Olivier Miakinen
Le 25/01/2007 16:34, je répondais à Thief13 :
A ce sujet, commet fait on pour connaitre le charset d'un ou de plusieurs fichiers textes simplement ?
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de caractères donné, on regarde s'il est lisible ou non. Si oui, c'est qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner quel *autre* jeu de caractères cela pourrait être.
Noter qu'à ce jeu de devinette il arrive que plusieurs jeux de caractères soient également possibles tant que l'on n'utilise que leur dénominateur commun.
Par exemple, un texte qui ne contient que de l'ASCII restera correct si on le lit en ISO-8859-1, ou en cp1252, voire en CP850 ou CP437, et même en UTF-8.
Un texte écrit en CP1252 restera indistinguable de l'ISO-8859-1 ou de l'ISO-8859-15 dans l'immense majorité des cas. Seuls certains caractères permettent de faire la différence, par exemple un « ½ » qui existe à la position 9C (hexa) dans cp1252, à la position BD dans ISO-8859-15, et pas du tout dans ISO-8859-1. Autre exemple, le Ç se trouve à la position C7 dans ISO-8859-1, ISO-8859-15 et CP1252, mais à la position 80 dans CP850 et CP437.
Sinon, il y a aussi des jeux de caractères qui ne conservent même pas l'ASCII tel quel : sans même parler des EBCDIC, il y a par exemple les UTF-16 (little endian ou big endian) qui rajoutent un 00 entre deux octets ASCII.
Le 25/01/2007 16:34, je répondais à Thief13 :
A ce sujet, commet fait on pour connaitre le charset d'un ou de
plusieurs fichiers textes simplement ?
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de
caractères donné, on regarde s'il est lisible ou non. Si oui, c'est
qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner
quel *autre* jeu de caractères cela pourrait être.
Noter qu'à ce jeu de devinette il arrive que plusieurs jeux de
caractères soient également possibles tant que l'on n'utilise que
leur dénominateur commun.
Par exemple, un texte qui ne contient que de l'ASCII restera correct si
on le lit en ISO-8859-1, ou en cp1252, voire en CP850 ou CP437, et même
en UTF-8.
Un texte écrit en CP1252 restera indistinguable de l'ISO-8859-1 ou de
l'ISO-8859-15 dans l'immense majorité des cas. Seuls certains caractères
permettent de faire la différence, par exemple un « ½ » qui existe à la
position 9C (hexa) dans cp1252, à la position BD dans ISO-8859-15, et
pas du tout dans ISO-8859-1. Autre exemple, le Ç se trouve à la position
C7 dans ISO-8859-1, ISO-8859-15 et CP1252, mais à la position 80 dans
CP850 et CP437.
Sinon, il y a aussi des jeux de caractères qui ne conservent même pas
l'ASCII tel quel : sans même parler des EBCDIC, il y a par exemple les
UTF-16 (little endian ou big endian) qui rajoutent un 00 entre deux
octets ASCII.
A ce sujet, commet fait on pour connaitre le charset d'un ou de plusieurs fichiers textes simplement ?
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de caractères donné, on regarde s'il est lisible ou non. Si oui, c'est qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner quel *autre* jeu de caractères cela pourrait être.
Noter qu'à ce jeu de devinette il arrive que plusieurs jeux de caractères soient également possibles tant que l'on n'utilise que leur dénominateur commun.
Par exemple, un texte qui ne contient que de l'ASCII restera correct si on le lit en ISO-8859-1, ou en cp1252, voire en CP850 ou CP437, et même en UTF-8.
Un texte écrit en CP1252 restera indistinguable de l'ISO-8859-1 ou de l'ISO-8859-15 dans l'immense majorité des cas. Seuls certains caractères permettent de faire la différence, par exemple un « ½ » qui existe à la position 9C (hexa) dans cp1252, à la position BD dans ISO-8859-15, et pas du tout dans ISO-8859-1. Autre exemple, le Ç se trouve à la position C7 dans ISO-8859-1, ISO-8859-15 et CP1252, mais à la position 80 dans CP850 et CP437.
Sinon, il y a aussi des jeux de caractères qui ne conservent même pas l'ASCII tel quel : sans même parler des EBCDIC, il y a par exemple les UTF-16 (little endian ou big endian) qui rajoutent un 00 entre deux octets ASCII.
John GALLET
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Oui bien sûr.
<FLAME ME="ON"> Je propose l'ajout suivant :
"Une bande d'abrutis incompétents ayant arbitrairement décidé que la terre entière devait désormais avoir des programmes qui ne marchent pas en UTF-8 au lieu d'avoir des programmes qui marchent en charset localisé, il se peut que vos éditeurs pourrissent vos fichiers à l'insu de votre plein gré au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets non imprimables partout. Pour résoudre ce problème, vriez ces merdes et utilisez vi."
Ca convient ? </FLAME>
JG -- edlin rulezzzzzz
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Oui bien sûr.
<FLAME ME="ON">
Je propose l'ajout suivant :
"Une bande d'abrutis incompétents ayant arbitrairement décidé que la terre
entière devait désormais avoir des programmes qui ne marchent pas en UTF-8
au lieu d'avoir des programmes qui marchent en charset localisé, il se
peut que vos éditeurs pourrissent vos fichiers à l'insu de votre plein gré
au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets
non imprimables partout. Pour résoudre ce problème, vriez ces merdes et
utilisez vi."
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Oui bien sûr.
<FLAME ME="ON"> Je propose l'ajout suivant :
"Une bande d'abrutis incompétents ayant arbitrairement décidé que la terre entière devait désormais avoir des programmes qui ne marchent pas en UTF-8 au lieu d'avoir des programmes qui marchent en charset localisé, il se peut que vos éditeurs pourrissent vos fichiers à l'insu de votre plein gré au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets non imprimables partout. Pour résoudre ce problème, vriez ces merdes et utilisez vi."
Ca convient ? </FLAME>
JG -- edlin rulezzzzzz
Thierry
<FLAME ME="ON"> Je propose l'ajout suivant :
"Une bande d'abrutis incompétents ayant arbitrairement décidé que la terre entière devait désormais avoir des programmes qui ne marchent pas en UTF-8 au lieu d'avoir des programmes qui marchent en charset localisé, il se peut que vos éditeurs pourrissent vos fichiers à l'insu de votre plein gré au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets non imprimables partout. Pour résoudre ce problème, vriez ces merdes et utilisez vi."
Ca convient ?
Non. On s'en fout de savoir de qui entre l'editeur, le client FTP ou les debris de cacahouetes dans le clavier generant un caractere a la con est la cause du pb. L'important est a la solution.
<FLAME ME="ON">
Je propose l'ajout suivant :
"Une bande d'abrutis incompétents ayant arbitrairement décidé que la terre
entière devait désormais avoir des programmes qui ne marchent pas en UTF-8
au lieu d'avoir des programmes qui marchent en charset localisé, il se
peut que vos éditeurs pourrissent vos fichiers à l'insu de votre plein gré
au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets
non imprimables partout. Pour résoudre ce problème, vriez ces merdes et
utilisez vi."
Ca convient ?
Non. On s'en fout de savoir de qui entre l'editeur, le client FTP ou les
debris de cacahouetes dans le clavier generant un caractere a la con est la
cause du pb. L'important est a la solution.
"Une bande d'abrutis incompétents ayant arbitrairement décidé que la terre entière devait désormais avoir des programmes qui ne marchent pas en UTF-8 au lieu d'avoir des programmes qui marchent en charset localisé, il se peut que vos éditeurs pourrissent vos fichiers à l'insu de votre plein gré au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets non imprimables partout. Pour résoudre ce problème, vriez ces merdes et utilisez vi."
Ca convient ?
Non. On s'en fout de savoir de qui entre l'editeur, le client FTP ou les debris de cacahouetes dans le clavier generant un caractere a la con est la cause du pb. L'important est a la solution.
Thierry Boudet
On 2007-01-28, John GALLET wrote:
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Oui bien sûr.
au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets non imprimables partout. Pour résoudre ce problème, vriez ces merdes et utilisez vi."
Ca convient ?
s/vi/Vim/
-- bref SQL est plus structuré que XML et PICK puisque tout est en vrac dans SQL on doit pas avoir la même notion de structure ce qui explique que tu végète dans le SQL --{ Helios, théoricien du chaos }--
On 2007-01-28, John GALLET <john.gallet@wanadoo.fr> wrote:
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Oui bien sûr.
au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets
non imprimables partout. Pour résoudre ce problème, vriez ces merdes et
utilisez vi."
Ca convient ?
s/vi/Vim/
--
bref SQL est plus structuré que XML et PICK puisque tout est en vrac
dans SQL on doit pas avoir la même notion de structure ce qui explique
que tu végète dans le SQL
--{ Helios, théoricien du chaos }--
J'ai regarde la FAQ qui ne parle pas de ce probleme.
John, on peut rajouter quelque chose à ce sujet dans la FAQ ?
Oui bien sûr.
au lieu de faire ce qu'on leur demande à savoir ne pas foutre des octets non imprimables partout. Pour résoudre ce problème, vriez ces merdes et utilisez vi."
Ca convient ?
s/vi/Vim/
-- bref SQL est plus structuré que XML et PICK puisque tout est en vrac dans SQL on doit pas avoir la même notion de structure ce qui explique que tu végète dans le SQL --{ Helios, théoricien du chaos }--
Thief13
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu. A moins que ce soit FileZilla qu'a fait du zele... A ce sujet, commet fait on pour connaitre le charset d'un ou de
plusieurs fichiers textes simplement ?
Pour un texte qu'on a soi-même écrit : au moment de le sauver, on fait gaffe au jeu de caractères dans lequel l'éditeur envisage de l'écrire.
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de caractères donné, on regarde s'il est lisible ou non. Si oui, c'est qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner quel *autre* jeu de caractères cela pourrait être.
Par exemple, si chaque caractère accentué d'un texte en français se retrouve transformé en deux caractères quand on le lit avec un jeu mono-octet, les lettres non accentuées restant lisibles, on peut supposer que qu'on a affaire à de l'UTF-8. Ceci est particulièrement vrai si on l'a lu comme si c'était de l'ISO-8859-1 ou du cp1252, et que le premier caractère de chaque paire est un Â, un à ou un Å.
je parlait en php, pas à vue d'oeil, c'est pas possible ?
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu.
A moins que ce soit FileZilla qu'a fait du zele...
A ce sujet, commet fait on pour connaitre le charset d'un ou de
plusieurs fichiers textes simplement ?
Pour un texte qu'on a soi-même écrit : au moment de le sauver, on fait
gaffe au jeu de caractères dans lequel l'éditeur envisage de l'écrire.
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de
caractères donné, on regarde s'il est lisible ou non. Si oui, c'est
qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner
quel *autre* jeu de caractères cela pourrait être.
Par exemple, si chaque caractère accentué d'un texte en français se
retrouve transformé en deux caractères quand on le lit avec un jeu
mono-octet, les lettres non accentuées restant lisibles, on peut
supposer que qu'on a affaire à de l'UTF-8. Ceci est particulièrement
vrai si on l'a lu comme si c'était de l'ISO-8859-1 ou du cp1252, et
que le premier caractère de chaque paire est un Â, un à ou un Å.
je parlait en php, pas à vue d'oeil, c'est pas possible ?
Bingo. Cet ****** d'Ultraedit a enregistré le fichier en UTF a mon insu. A moins que ce soit FileZilla qu'a fait du zele... A ce sujet, commet fait on pour connaitre le charset d'un ou de
plusieurs fichiers textes simplement ?
Pour un texte qu'on a soi-même écrit : au moment de le sauver, on fait gaffe au jeu de caractères dans lequel l'éditeur envisage de l'écrire.
Pour un texte de quelqu'un d'autre : une fois lu en supposant un jeu de caractères donné, on regarde s'il est lisible ou non. Si oui, c'est qu'on avait bien intuité ; sinon, un peu d'habitude permet de deviner quel *autre* jeu de caractères cela pourrait être.
Par exemple, si chaque caractère accentué d'un texte en français se retrouve transformé en deux caractères quand on le lit avec un jeu mono-octet, les lettres non accentuées restant lisibles, on peut supposer que qu'on a affaire à de l'UTF-8. Ceci est particulièrement vrai si on l'a lu comme si c'était de l'ISO-8859-1 ou du cp1252, et que le premier caractère de chaque paire est un Â, un à ou un Å.
je parlait en php, pas à vue d'oeil, c'est pas possible ?
