Bonjour,
J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
Connaissez-vous d'autres axes de récherche en VB6 ?
Bonjour,
J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
Connaissez-vous d'autres axes de récherche en VB6 ?
Bonjour,
J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
Connaissez-vous d'autres axes de récherche en VB6 ?
Dans : news:,
aski écrivait :Bonjour,
Bonjour,J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI sur
cette plage.Connaissez-vous d'autres axes de récherche en VB6 ?
Dans : news:OTHAbD4AJHA.1628@TK2MSFTNGP02.phx.gbl,
aski écrivait :
Bonjour,
Bonjour,
J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI sur
cette plage.
Connaissez-vous d'autres axes de récherche en VB6 ?
Dans : news:,
aski écrivait :Bonjour,
Bonjour,J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI sur
cette plage.Connaissez-vous d'autres axes de récherche en VB6 ?
En complément de la réponse déjà très complète de Fred, tu peux
aussi chercher (dans le cas d'un document html) l'attribut "charset"
qui doit normalement spécifier l'encodage:
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
En complément de la réponse déjà très complète de Fred, tu peux
aussi chercher (dans le cas d'un document html) l'attribut "charset"
qui doit normalement spécifier l'encodage:
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
En complément de la réponse déjà très complète de Fred, tu peux
aussi chercher (dans le cas d'un document html) l'attribut "charset"
qui doit normalement spécifier l'encodage:
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
Dans : news:,
aski écrivait :Bonjour,
Bonjour,J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI sur
cette plage.
Connaissez-vous d'autres axes de récherche en VB6 ?
- Regarder en début de fichier s'il y a un Byte Order Mark (BOM).
- Analyser le fichier sommairement pour voir si la séquence d'octets est
conforme avec de l'UTF-8
Peut-être d'autres méthodes que j'ignore.
Pour l'analyse, les points suivants peuvent t'aider :
si l'octet est supérieur à 127, alors le nombre N de bits de poids fort à
1 (avant le premier à 0 donc), correspond à la longueur de la séquence.
(une séquence = un caractère)
Les N-1 octets qui suivents doivent tous avoir leurs deux bits de poids
fort respectivement à 1 et 0.
http://fr.wikipedia.org/wiki/UTF-8
Dans : news:OTHAbD4AJHA.1628@TK2MSFTNGP02.phx.gbl,
aski écrivait :
Bonjour,
Bonjour,
J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI sur
cette plage.
Connaissez-vous d'autres axes de récherche en VB6 ?
- Regarder en début de fichier s'il y a un Byte Order Mark (BOM).
- Analyser le fichier sommairement pour voir si la séquence d'octets est
conforme avec de l'UTF-8
Peut-être d'autres méthodes que j'ignore.
Pour l'analyse, les points suivants peuvent t'aider :
si l'octet est supérieur à 127, alors le nombre N de bits de poids fort à
1 (avant le premier à 0 donc), correspond à la longueur de la séquence.
(une séquence = un caractère)
Les N-1 octets qui suivents doivent tous avoir leurs deux bits de poids
fort respectivement à 1 et 0.
http://fr.wikipedia.org/wiki/UTF-8
Dans : news:,
aski écrivait :Bonjour,
Bonjour,J'ai utilisé, pour détecter le codage UTF-8 dans un fichier (php,
html ou autre fichier texte), les fonctions API WideCharToMultiByte()
et MultiByteToWideChar() appelées successivement.
Cette méthode ne fonctionne évidemment que s'il existe des codes ASCII
supérieurs à 127.
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI sur
cette plage.
Connaissez-vous d'autres axes de récherche en VB6 ?
- Regarder en début de fichier s'il y a un Byte Order Mark (BOM).
- Analyser le fichier sommairement pour voir si la séquence d'octets est
conforme avec de l'UTF-8
Peut-être d'autres méthodes que j'ignore.
Pour l'analyse, les points suivants peuvent t'aider :
si l'octet est supérieur à 127, alors le nombre N de bits de poids fort à
1 (avant le premier à 0 donc), correspond à la longueur de la séquence.
(une séquence = un caractère)
Les N-1 octets qui suivents doivent tous avoir leurs deux bits de poids
fort respectivement à 1 et 0.
http://fr.wikipedia.org/wiki/UTF-8
Salut Fred,
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI
sur cette plage.
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Connaissez-vous d'autres axes de récherche en VB6 ?
- Regarder en début de fichier s'il y a un Byte Order Mark (BOM).
Cela, c'est facile et déjà fait, mais on peut être avec ou sans BOM.
- Analyser le fichier sommairement pour voir si la séquence d'octets
est conforme avec de l'UTF-8
Les API citées sont les seules que j'ai trouvées pour le faire.
En convertissant la chaîne en ANSi puis le résultat en UTF-8, la
chaîne résultante doit être le même que la chaîne initiale.
http://fr.wikipedia.org/wiki/UTF-8
Merci, j'avais lu mais cela n'a pu me dépanner pour une détection
rapide.
Malheureusement, il y a
ambiguïté lorsque les codes des caractères sont inférieurs à 128.
Salut Fred,
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI
sur cette plage.
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Connaissez-vous d'autres axes de récherche en VB6 ?
- Regarder en début de fichier s'il y a un Byte Order Mark (BOM).
Cela, c'est facile et déjà fait, mais on peut être avec ou sans BOM.
- Analyser le fichier sommairement pour voir si la séquence d'octets
est conforme avec de l'UTF-8
Les API citées sont les seules que j'ai trouvées pour le faire.
En convertissant la chaîne en ANSi puis le résultat en UTF-8, la
chaîne résultante doit être le même que la chaîne initiale.
http://fr.wikipedia.org/wiki/UTF-8
Merci, j'avais lu mais cela n'a pu me dépanner pour une détection
rapide.
Malheureusement, il y a
ambiguïté lorsque les codes des caractères sont inférieurs à 128.
Salut Fred,
S'il n'existe pas d'octets supérieurs à 127, le fichier peut-être
considéré comme encodé en UTF-8 car il y a compatibilité avec l'ASKI
sur cette plage.
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Connaissez-vous d'autres axes de récherche en VB6 ?
- Regarder en début de fichier s'il y a un Byte Order Mark (BOM).
Cela, c'est facile et déjà fait, mais on peut être avec ou sans BOM.
- Analyser le fichier sommairement pour voir si la séquence d'octets
est conforme avec de l'UTF-8
Les API citées sont les seules que j'ai trouvées pour le faire.
En convertissant la chaîne en ANSi puis le résultat en UTF-8, la
chaîne résultante doit être le même que la chaîne initiale.
http://fr.wikipedia.org/wiki/UTF-8
Merci, j'avais lu mais cela n'a pu me dépanner pour une détection
rapide.
Malheureusement, il y a
ambiguïté lorsque les codes des caractères sont inférieurs à 128.
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Idem, sur la plage 0 - 127, ASCII = ANSI
Mais dès qu'on dépasse 127 (en UTF-8), on est en présence d'un caractère
codé sur plusieurs octets.
Donc pas du tout compatible, ni avec ASCII, ni ANSI, ni n'importe quel
codage mono-octet.
(voir les «hiéroglyphes» que l'on peut parfois observer sur les newsgroups
lorque l'on réponds à un message UTF-8 posté du site MS avec un lecteur
mal configuré).
Merci, j'avais lu mais cela n'a pu me dépanner pour une détection
rapide.
Rapide en temps d'écriture du code ;-)
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être extrêmement
rapide !
Sans compter que tu peux ne lire les octets que par blocs et ne pas
charger le fichier entièrement en mémoire.
Malheureusement, il y a
ambiguïté lorsque les codes des caractères sont inférieurs à 128.
Ben non, c'est justement le seul cas où il n'y a jamais ambiguïté, puisque
tous les encodages (je parle de ASCII, ANSI(s), ISO, UTF-8) sont
équivalents sur cette plage.
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Idem, sur la plage 0 - 127, ASCII = ANSI
Mais dès qu'on dépasse 127 (en UTF-8), on est en présence d'un caractère
codé sur plusieurs octets.
Donc pas du tout compatible, ni avec ASCII, ni ANSI, ni n'importe quel
codage mono-octet.
(voir les «hiéroglyphes» que l'on peut parfois observer sur les newsgroups
lorque l'on réponds à un message UTF-8 posté du site MS avec un lecteur
mal configuré).
Merci, j'avais lu mais cela n'a pu me dépanner pour une détection
rapide.
Rapide en temps d'écriture du code ;-)
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être extrêmement
rapide !
Sans compter que tu peux ne lire les octets que par blocs et ne pas
charger le fichier entièrement en mémoire.
Malheureusement, il y a
ambiguïté lorsque les codes des caractères sont inférieurs à 128.
Ben non, c'est justement le seul cas où il n'y a jamais ambiguïté, puisque
tous les encodages (je parle de ASCII, ANSI(s), ISO, UTF-8) sont
équivalents sur cette plage.
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Idem, sur la plage 0 - 127, ASCII = ANSI
Mais dès qu'on dépasse 127 (en UTF-8), on est en présence d'un caractère
codé sur plusieurs octets.
Donc pas du tout compatible, ni avec ASCII, ni ANSI, ni n'importe quel
codage mono-octet.
(voir les «hiéroglyphes» que l'on peut parfois observer sur les newsgroups
lorque l'on réponds à un message UTF-8 posté du site MS avec un lecteur
mal configuré).
Merci, j'avais lu mais cela n'a pu me dépanner pour une détection
rapide.
Rapide en temps d'écriture du code ;-)
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être extrêmement
rapide !
Sans compter que tu peux ne lire les octets que par blocs et ne pas
charger le fichier entièrement en mémoire.
Malheureusement, il y a
ambiguïté lorsque les codes des caractères sont inférieurs à 128.
Ben non, c'est justement le seul cas où il n'y a jamais ambiguïté, puisque
tous les encodages (je parle de ASCII, ANSI(s), ISO, UTF-8) sont
équivalents sur cette plage.
Re,Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être
extrêmement rapide !
Je ne joue pas dans la même catégorie de Jean-Marc et je le regrette.
:-(
Re,
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être
extrêmement rapide !
Je ne joue pas dans la même catégorie de Jean-Marc et je le regrette.
:-(
Re,Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être
extrêmement rapide !
Je ne joue pas dans la même catégorie de Jean-Marc et je le regrette.
:-(
Re,
"Fred" a écrit dans le message de groupe de
discussion :Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Idem, sur la plage 0 - 127, ASCII = ANSI
Mais dès qu'on dépasse 127 (en UTF-8), on est en présence d'un
caractère codé sur plusieurs octets.
Tu veux bien dire que c'est un cas très spécifique à l'UTF-8 et que
l'on ne retrouve pas sur sur les autres codes ?
C'est ce que je veux dire dans mon jargon trop simpliste .... Notepad
indique un format ANSI dans ce cas alors qu'il devrait indiquer par
exemple "neutre" ou "non détectable"
Re,
"Fred" <foleide@free.fr.invalid> a écrit dans le message de groupe de
discussion : ukorBn6AJHA.4940@TK2MSFTNGP05.phx.gbl...
Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Idem, sur la plage 0 - 127, ASCII = ANSI
Mais dès qu'on dépasse 127 (en UTF-8), on est en présence d'un
caractère codé sur plusieurs octets.
Tu veux bien dire que c'est un cas très spécifique à l'UTF-8 et que
l'on ne retrouve pas sur sur les autres codes ?
C'est ce que je veux dire dans mon jargon trop simpliste .... Notepad
indique un format ANSI dans ce cas alors qu'il devrait indiquer par
exemple "neutre" ou "non détectable"
Re,
"Fred" a écrit dans le message de groupe de
discussion :Pourquoi pas ANSI (voir comment NotePad ++ l'interprète) ?.
Idem, sur la plage 0 - 127, ASCII = ANSI
Mais dès qu'on dépasse 127 (en UTF-8), on est en présence d'un
caractère codé sur plusieurs octets.
Tu veux bien dire que c'est un cas très spécifique à l'UTF-8 et que
l'on ne retrouve pas sur sur les autres codes ?
C'est ce que je veux dire dans mon jargon trop simpliste .... Notepad
indique un format ANSI dans ce cas alors qu'il devrait indiquer par
exemple "neutre" ou "non détectable"
aski wrote:Re,
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être
extrêmement rapide !
Je confirme :o) Couplé avec une lecture binaire rapide si le fichier
n'est pas trop volumineux
(http://faq.vb.free.fr/index.php?question5), ce devrait être
extrèmement efficace !
aski wrote:
Re,
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être
extrêmement rapide !
Je confirme :o) Couplé avec une lecture binaire rapide si le fichier
n'est pas trop volumineux
(http://faq.vb.free.fr/index.php?question5), ce devrait être
extrèmement efficace !
aski wrote:Re,
Mais analyser le fichier en le lisant avec, pourquoi pas, un petit
automate d'état fini dont Jean-Marc a le secret, devrait être
extrêmement rapide !
Je confirme :o) Couplé avec une lecture binaire rapide si le fichier
n'est pas trop volumineux
(http://faq.vb.free.fr/index.php?question5), ce devrait être
extrèmement efficace !
Non, pas exactement.
(UTF-8) => (critères vérifiés)
(critères non vérifiés) => (non UTF-8)
mais (critères vérifiés) n'implique pas UTF-8
ex : Dans un fichier ANSI je place, avec Notepad, les deux caractères
suivants :
é
J'obtiens, si on ne considère pas le BOM qui sera absent, un fichier qui
satisfait les critères UTF-8.
Interprété comme de l'UTF-8, les deux octets du fichier représentent le
caractère é.
Bien sûr la probabilité que les critères soient vérifiés et que le fichier
ne soit pas de l'UTF-8 est faible.
Mais je pense que dans ce cas, même les APIs se «plantent».
Oui, c'est moi qui ai mal compris ce que tu voulais dire.
Pourquoi ANSI ? Peut-être parce que c'est l'encodage par défaut du système
?
Non, pas exactement.
(UTF-8) => (critères vérifiés)
(critères non vérifiés) => (non UTF-8)
mais (critères vérifiés) n'implique pas UTF-8
ex : Dans un fichier ANSI je place, avec Notepad, les deux caractères
suivants :
é
J'obtiens, si on ne considère pas le BOM qui sera absent, un fichier qui
satisfait les critères UTF-8.
Interprété comme de l'UTF-8, les deux octets du fichier représentent le
caractère é.
Bien sûr la probabilité que les critères soient vérifiés et que le fichier
ne soit pas de l'UTF-8 est faible.
Mais je pense que dans ce cas, même les APIs se «plantent».
Oui, c'est moi qui ai mal compris ce que tu voulais dire.
Pourquoi ANSI ? Peut-être parce que c'est l'encodage par défaut du système
?
Non, pas exactement.
(UTF-8) => (critères vérifiés)
(critères non vérifiés) => (non UTF-8)
mais (critères vérifiés) n'implique pas UTF-8
ex : Dans un fichier ANSI je place, avec Notepad, les deux caractères
suivants :
é
J'obtiens, si on ne considère pas le BOM qui sera absent, un fichier qui
satisfait les critères UTF-8.
Interprété comme de l'UTF-8, les deux octets du fichier représentent le
caractère é.
Bien sûr la probabilité que les critères soient vérifiés et que le fichier
ne soit pas de l'UTF-8 est faible.
Mais je pense que dans ce cas, même les APIs se «plantent».
Oui, c'est moi qui ai mal compris ce que tu voulais dire.
Pourquoi ANSI ? Peut-être parce que c'est l'encodage par défaut du système
?