Discussion:
Comment savoir l'encodage d'une chaine de c aracteres ?
(trop ancien pour répondre)
Jean-Francois Ortolo
2008-04-23 08:45:52 UTC
Permalink
Bonjour

J'ai une chaîne de caractères, son encodage peut être uft-8 ou
iso-8859-1 ou iso-8859-15.

Comment faire pour savoir son encodage, dans le but éventuellement,
de faire une conversion avec iconv() , vers l'encodage iso ?

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
Olivier Miakinen
2008-04-23 09:13:27 UTC
Permalink
Bonjour,
Post by Jean-Francois Ortolo
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.
Post by Jean-Francois Ortolo
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
2008-04-23 12:00:47 UTC
Permalink
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 "\r\n", mais cette fonction apparemment dans ce cas, ne me
renvoie pas une chaîne de caractère contenant des sauts de lignes (
"\r\n" ou "\n" ), ou bien ne renvoie rien.

Merci beaucoup pour votre aide.

Bien à vous.

Amicalement.

Jean-François Ortolo
Olivier Miakinen
2008-04-23 12:15:26 UTC
Permalink
Post by Jean-Francois Ortolo
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.
Post by Jean-Francois Ortolo
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>.
Post by Jean-Francois Ortolo
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 "\r\n", mais cette fonction apparemment dans ce cas, ne me
renvoie pas une chaîne de caractère contenant des sauts de lignes (
"\r\n" 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
2008-04-23 21:00:17 UTC
Permalink
Post by Olivier Miakinen
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
2008-04-23 22:36:28 UTC
Permalink
Post by Olivier Miakinen
<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.
Continuer la lecture sur narkive:
Loading...