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
Bonjour,
J'ai une chaîne de caractères, son encodage peut être uft-8 ou iso-8859-1 ou iso-8859-15.
Si la chaîne vient d'un utilisateur, elle pourrait aussi bien être en win1252, pris à tort pour de l'iso-8859-1.
Comment faire pour savoir son encodage, dans le but éventuellement, de faire une conversion avec iconv() , vers l'encodage iso ?
Voici comment je procèderais.
1) Commencer par vérifier si c'est de l'UTF-8, qui est le plus facile à reconnaître (et encore plus facile à éliminer). Par exemple, tu peux tenter un iconv depuis UTF-8 vers un autre jeu censé contenir tous les caractères. Je ne sais pas si iconv de UTF-8 vers UTF-8 fait la vérification, mais ça devrait être le cas.
2) Si ce premier test à échoué, chercher s'il y a des caractères entre 128 (80 hexa) et 159 (9F hexa), auquel cas ça a toutes les chances d'être du win1252. En particulier, les caractères numéros 128, 133, 146 et 156 représentent respectivement le sybole euro, les points de suspension, l'apostrophe et la ligature oe. Cf. http://www.miakinen.net/vrac/charsets/?or=4
3) Sinon, chercher s'il y a les caractères numéros 164 et 189, assez caractéristiques d'iso-8859-15 (respectivement l'euro et la ligature oe dans iso-8859-15, mais le symbole monétaire international et la fraction 1/2 dans iso-8859-1. Cf. http://www.miakinen.net/vrac/charsets/?or=3
4) Enfin, en dira que c'est iso-8859-1. Cf. http://www.miakinen.net/vrac/charsets/?or=2
Bonjour,
J'ai une chaîne de caractères, son encodage peut être uft-8 ou
iso-8859-1 ou iso-8859-15.
Si la chaîne vient d'un utilisateur, elle pourrait aussi bien être en
win1252, pris à tort pour de l'iso-8859-1.
Comment faire pour savoir son encodage, dans le but éventuellement,
de faire une conversion avec iconv() , vers l'encodage iso ?
Voici comment je procèderais.
1) Commencer par vérifier si c'est de l'UTF-8, qui est le plus facile à
reconnaître (et encore plus facile à éliminer). Par exemple, tu peux
tenter un iconv depuis UTF-8 vers un autre jeu censé contenir tous les
caractères. Je ne sais pas si iconv de UTF-8 vers UTF-8 fait la
vérification, mais ça devrait être le cas.
2) Si ce premier test à échoué, chercher s'il y a des caractères entre
128 (80 hexa) et 159 (9F hexa), auquel cas ça a toutes les chances
d'être du win1252. En particulier, les caractères numéros 128, 133,
146 et 156 représentent respectivement le sybole euro, les points de
suspension, l'apostrophe et la ligature oe.
Cf. http://www.miakinen.net/vrac/charsets/?or=4
3) Sinon, chercher s'il y a les caractères numéros 164 et 189, assez
caractéristiques d'iso-8859-15 (respectivement l'euro et la ligature oe
dans iso-8859-15, mais le symbole monétaire international et la fraction
1/2 dans iso-8859-1.
Cf. http://www.miakinen.net/vrac/charsets/?or=3
4) Enfin, en dira que c'est iso-8859-1.
Cf. http://www.miakinen.net/vrac/charsets/?or=2
J'ai une chaîne de caractères, son encodage peut être uft-8 ou iso-8859-1 ou iso-8859-15.
Si la chaîne vient d'un utilisateur, elle pourrait aussi bien être en win1252, pris à tort pour de l'iso-8859-1.
Comment faire pour savoir son encodage, dans le but éventuellement, de faire une conversion avec iconv() , vers l'encodage iso ?
Voici comment je procèderais.
1) Commencer par vérifier si c'est de l'UTF-8, qui est le plus facile à reconnaître (et encore plus facile à éliminer). Par exemple, tu peux tenter un iconv depuis UTF-8 vers un autre jeu censé contenir tous les caractères. Je ne sais pas si iconv de UTF-8 vers UTF-8 fait la vérification, mais ça devrait être le cas.
2) Si ce premier test à échoué, chercher s'il y a des caractères entre 128 (80 hexa) et 159 (9F hexa), auquel cas ça a toutes les chances d'être du win1252. En particulier, les caractères numéros 128, 133, 146 et 156 représentent respectivement le sybole euro, les points de suspension, l'apostrophe et la ligature oe. Cf. http://www.miakinen.net/vrac/charsets/?or=4
3) Sinon, chercher s'il y a les caractères numéros 164 et 189, assez caractéristiques d'iso-8859-15 (respectivement l'euro et la ligature oe dans iso-8859-15, mais le symbole monétaire international et la fraction 1/2 dans iso-8859-1. Cf. http://www.miakinen.net/vrac/charsets/?or=3
4) Enfin, en dira que c'est iso-8859-1. Cf. http://www.miakinen.net/vrac/charsets/?or=2
Jean-Francois Ortolo
Merci beaucoup Monsieur
C'est sûr que celà ne peut être que de l'iso-8859-1, ou iso-8859-15, ou de l'utf-8.
Dans mon cas en tout cas, il n'y a pas de problème de ce côté-là.
Mais... J'ai vérifié ( c'est toujours la même url, et le même encodage pour la réponse ), c'est bien de l'iso-8859-15, pas de problème.
Cependant, le contenu est compressé en mode http gzip pour la réponse,et chunked en plus ( protocole http/1/1 hé oui... ), or j'ai bien une fonction qui détecte l'header content-encoding, et quand c'est gzip ou deflate ou compress, lance la fonction gzinflate sur le résultat.
Ce sont des fonctions decode_header() et decode_body() que j'utilise, qui figurent dans les commentaires du PHP Manual, en dessous de la description de la fonction fsockopen() .
Je vais aller voir dans la logique de la fonction decode_body() , théoriquement le saut de ligne dans le résultat de la requête http est toujours "rn", mais cette fonction apparemment dans ce cas, ne me renvoie pas une chaîne de caractère contenant des sauts de lignes ( "rn" ou "n" ), ou bien ne renvoie rien.
Merci beaucoup pour votre aide.
Bien à vous.
Amicalement.
Jean-François Ortolo
Merci beaucoup Monsieur
C'est sûr que celà ne peut être que de l'iso-8859-1, ou iso-8859-15,
ou de l'utf-8.
Dans mon cas en tout cas, il n'y a pas de problème de ce côté-là.
Mais... J'ai vérifié ( c'est toujours la même url, et le même
encodage pour la réponse ), c'est bien de l'iso-8859-15, pas de problème.
Cependant, le contenu est compressé en mode http gzip pour la
réponse,et chunked en plus ( protocole http/1/1 hé oui... ), or j'ai
bien une fonction qui détecte l'header content-encoding, et quand c'est
gzip ou deflate ou compress, lance la fonction gzinflate sur le résultat.
Ce sont des fonctions decode_header() et decode_body() que j'utilise,
qui figurent dans les commentaires du PHP Manual, en dessous de la
description de la fonction fsockopen() .
Je vais aller voir dans la logique de la fonction decode_body() ,
théoriquement le saut de ligne dans le résultat de la requête http est
toujours "rn", mais cette fonction apparemment dans ce cas, ne me
renvoie pas une chaîne de caractère contenant des sauts de lignes (
"rn" ou "n" ), ou bien ne renvoie rien.
C'est sûr que celà ne peut être que de l'iso-8859-1, ou iso-8859-15, ou de l'utf-8.
Dans mon cas en tout cas, il n'y a pas de problème de ce côté-là.
Mais... J'ai vérifié ( c'est toujours la même url, et le même encodage pour la réponse ), c'est bien de l'iso-8859-15, pas de problème.
Cependant, le contenu est compressé en mode http gzip pour la réponse,et chunked en plus ( protocole http/1/1 hé oui... ), or j'ai bien une fonction qui détecte l'header content-encoding, et quand c'est gzip ou deflate ou compress, lance la fonction gzinflate sur le résultat.
Ce sont des fonctions decode_header() et decode_body() que j'utilise, qui figurent dans les commentaires du PHP Manual, en dessous de la description de la fonction fsockopen() .
Je vais aller voir dans la logique de la fonction decode_body() , théoriquement le saut de ligne dans le résultat de la requête http est toujours "rn", mais cette fonction apparemment dans ce cas, ne me renvoie pas une chaîne de caractère contenant des sauts de lignes ( "rn" ou "n" ), ou bien ne renvoie rien.
Merci beaucoup pour votre aide.
Bien à vous.
Amicalement.
Jean-François Ortolo
Olivier Miakinen
C'est sûr que celà ne peut être que de l'iso-8859-1, ou iso-8859-15, ou de l'utf-8.
D'accord. Il est donc possible de ne pas faire le test numéro 2.
Mais... J'ai vérifié ( c'est toujours la même url, et le même encodage pour la réponse ), c'est bien de l'iso-8859-15, pas de problème.
Note que l'iso-8859-15 est indiscernable de l'iso-8859-1 tant que l'on n'utilise aucun des huit caractères qui sont sur fond bleu ou jaune dans <http://www.miakinen.net/vrac/charsets/?or=3>.
Cependant, le contenu est compressé en mode http gzip pour la réponse,et chunked en plus ( protocole http/1/1 hé oui... ), or j'ai bien une fonction qui détecte l'header content-encoding, et quand c'est gzip ou deflate ou compress, lance la fonction gzinflate sur le résultat.
Ce sont des fonctions decode_header() et decode_body() que j'utilise, qui figurent dans les commentaires du PHP Manual, en dessous de la description de la fonction fsockopen() .
Je vais aller voir dans la logique de la fonction decode_body() , théoriquement le saut de ligne dans le résultat de la requête http est toujours "rn", mais cette fonction apparemment dans ce cas, ne me renvoie pas une chaîne de caractère contenant des sauts de lignes ( "rn" ou "n" ), ou bien ne renvoie rien.
Là, j'avoue humblement que je ne comprends pas ce que tu cherches à faire ni où se trouve le problème. Est-ce que ma réponse précédente te suffisait, ou bien y a-t-il encore des points obscurs ?
C'est sûr que celà ne peut être que de l'iso-8859-1, ou iso-8859-15,
ou de l'utf-8.
D'accord. Il est donc possible de ne pas faire le test numéro 2.
Mais... J'ai vérifié ( c'est toujours la même url, et le même
encodage pour la réponse ), c'est bien de l'iso-8859-15, pas de problème.
Note que l'iso-8859-15 est indiscernable de l'iso-8859-1 tant que l'on
n'utilise aucun des huit caractères qui sont sur fond bleu ou jaune dans
<http://www.miakinen.net/vrac/charsets/?or=3>.
Cependant, le contenu est compressé en mode http gzip pour la
réponse,et chunked en plus ( protocole http/1/1 hé oui... ), or j'ai
bien une fonction qui détecte l'header content-encoding, et quand c'est
gzip ou deflate ou compress, lance la fonction gzinflate sur le résultat.
Ce sont des fonctions decode_header() et decode_body() que j'utilise,
qui figurent dans les commentaires du PHP Manual, en dessous de la
description de la fonction fsockopen() .
Je vais aller voir dans la logique de la fonction decode_body() ,
théoriquement le saut de ligne dans le résultat de la requête http est
toujours "rn", mais cette fonction apparemment dans ce cas, ne me
renvoie pas une chaîne de caractère contenant des sauts de lignes (
"rn" ou "n" ), ou bien ne renvoie rien.
Là, j'avoue humblement que je ne comprends pas ce que tu cherches à
faire ni où se trouve le problème. Est-ce que ma réponse précédente te
suffisait, ou bien y a-t-il encore des points obscurs ?
C'est sûr que celà ne peut être que de l'iso-8859-1, ou iso-8859-15, ou de l'utf-8.
D'accord. Il est donc possible de ne pas faire le test numéro 2.
Mais... J'ai vérifié ( c'est toujours la même url, et le même encodage pour la réponse ), c'est bien de l'iso-8859-15, pas de problème.
Note que l'iso-8859-15 est indiscernable de l'iso-8859-1 tant que l'on n'utilise aucun des huit caractères qui sont sur fond bleu ou jaune dans <http://www.miakinen.net/vrac/charsets/?or=3>.
Cependant, le contenu est compressé en mode http gzip pour la réponse,et chunked en plus ( protocole http/1/1 hé oui... ), or j'ai bien une fonction qui détecte l'header content-encoding, et quand c'est gzip ou deflate ou compress, lance la fonction gzinflate sur le résultat.
Ce sont des fonctions decode_header() et decode_body() que j'utilise, qui figurent dans les commentaires du PHP Manual, en dessous de la description de la fonction fsockopen() .
Je vais aller voir dans la logique de la fonction decode_body() , théoriquement le saut de ligne dans le résultat de la requête http est toujours "rn", mais cette fonction apparemment dans ce cas, ne me renvoie pas une chaîne de caractère contenant des sauts de lignes ( "rn" ou "n" ), ou bien ne renvoie rien.
Là, j'avoue humblement que je ne comprends pas ce que tu cherches à faire ni où se trouve le problème. Est-ce que ma réponse précédente te suffisait, ou bien y a-t-il encore des points obscurs ?
Jean-Francois Ortolo
Là, j'avoue humblement que je ne comprends pas ce que tu cherches à faire ni où se trouve le problème. Est-ce que ma réponse précédente te suffisait, ou bien y a-t-il encore des points obscurs ?
Je vous prie de m'excuser
J'avais oublié de dire, que le problème ne se posait plus pour moi, puisque je sais que c'est de l'iso-8859-15, encore que je l'ai testé en lançant l'url à partir de mon navvigateur Firefox, alors que l'url est lancé an réalité via une requête Ajax, qui spécifie un Content-type en utf-8.
Il me semble que le Content-type est uniquement le contenu de la reqûe http, mais je ne sais pas si un Content-type à utf-8, entraîne nécessairement une réponse en utf-8.
Dans ce cas, ce serait la dernière question que je puisse poser.
Merci beaucoup pour votre aide.
Amicalement.
Jean-Francois Ortolo
Là, j'avoue humblement que je ne comprends pas ce que tu cherches à
faire ni où se trouve le problème. Est-ce que ma réponse précédente te
suffisait, ou bien y a-t-il encore des points obscurs ?
Je vous prie de m'excuser
J'avais oublié de dire, que le problème ne se posait plus pour moi,
puisque je sais que c'est de l'iso-8859-15, encore que je l'ai testé en
lançant l'url à partir de mon navvigateur Firefox, alors que l'url est
lancé an réalité via une requête Ajax, qui spécifie un Content-type en
utf-8.
Il me semble que le Content-type est uniquement le contenu de la
reqûe http, mais je ne sais pas si un Content-type à utf-8, entraîne
nécessairement une réponse en utf-8.
Dans ce cas, ce serait la dernière question que je puisse poser.
Là, j'avoue humblement que je ne comprends pas ce que tu cherches à faire ni où se trouve le problème. Est-ce que ma réponse précédente te suffisait, ou bien y a-t-il encore des points obscurs ?
Je vous prie de m'excuser
J'avais oublié de dire, que le problème ne se posait plus pour moi, puisque je sais que c'est de l'iso-8859-15, encore que je l'ai testé en lançant l'url à partir de mon navvigateur Firefox, alors que l'url est lancé an réalité via une requête Ajax, qui spécifie un Content-type en utf-8.
Il me semble que le Content-type est uniquement le contenu de la reqûe http, mais je ne sais pas si un Content-type à utf-8, entraîne nécessairement une réponse en utf-8.
Dans ce cas, ce serait la dernière question que je puisse poser.
Merci beaucoup pour votre aide.
Amicalement.
Jean-Francois Ortolo
Sylvain SF
Olivier Miakinen wrote on 23/04/2008 14:15:
<http://www.miakinen.net/vrac/charsets/?or=3>.
géniale cette page !!
Sylvain.
-- j'aime moins la page / m'interrogeant toujours sur la contradiction entre le désir de respect de sa vie privée et l'étalage intentionel, pardon pour ce hors sujet.
Olivier Miakinen wrote on 23/04/2008 14:15:
<http://www.miakinen.net/vrac/charsets/?or=3>.
géniale cette page !!
Sylvain.
--
j'aime moins la page / m'interrogeant toujours sur la contradiction
entre le désir de respect de sa vie privée et l'étalage intentionel,
pardon pour ce hors sujet.
-- j'aime moins la page / m'interrogeant toujours sur la contradiction entre le désir de respect de sa vie privée et l'étalage intentionel, pardon pour ce hors sujet.
