iconv UTF8: séquence d'échappement non permise

AnsuzPeorth · Le 11/02/2009, à 19:31

Bjr,

Toujours un problème avec c't'encodage de mer....

En sortie, mplayer indique le nom du fichier et les tagg associé. Le problème, c'est qu'il y a des fichiers avec des encodages differents (tag et nom de fichier).
Mon but, et de recuperer ces inforamtions, et de réecrire un glade (sed -i). Mais le problème, si j'ai des caracteres non utf8, le glade est comrrompu (ca plante tout, faut restaurer l'ancien glade).

J'ai donc esayé iconv
Le message d'erreur : séquence d'échappement non permise.

Si je passe par recode avant et iconv ensuite, j'ai plus de message d'erreur iconv, mais le resultat n'est pas du "bon ut8" non plus....(glade plante sur certain caracteres qd meme)

J'ai essayer de forcer mplayer à envoyer du utf8 (msgcharset), ca marche po...

Je peux traiter la sortie mplayer dans le fichier ou via une variable....

La commande qui est la plus efficasse (mais pas parfaite....)

mplayer ...... | recode latin1..utf8 | iconv -t utf8 >> fichier_log

je sais que c'est un problème cette encodage, alors si qql'un à une recette miracle pour forcer l'encodage en utf8 (valide) depuis une source à multi encodage...je suis preneur !

merci d'avance !

Dernière modification par AnsuzPeorth (Le 12/02/2009, à 01:59)

paladin · Le 14/02/2009, à 15:10

Je ne peux pas te donner la solution, mais je peux t'expliquer ton problème.

Il y a plus de caractères en UTF-8 qu'en Latin-1 :
* L'ISO 8859-1 ou Latin-1 est codée sur 8 bits, elle définit ce qu'elle appelle l'alphabet latin numéro 1. C'est une extension de l'ASCII.
* L'UTF-8 est un codage des caractères définis par Unicode, chaque caractère est codé sur une suite d'un à quatre octets. Il est compatible avec le jeu de caractères ASCII, et son codage de taille variable lui permet d’être moins coûteux en occupation mémoire.

Suivant la version de iconv que tu utilises, tu peux utiliser l'option --unicode-subst=<format>, qui définit le format d'affichage des caractères Unicodes incorrects.
Exemple : iconv -t ISO-8859-1 -f UTF-8 --unicode-subst="<U+%04X>" file.unix.UTF-8.txt > file.unix.ISO-8859-1.txt => convertit un fichier unix de UTF-8 à Latin-1 sans erreurs

Enfin, je n'utilise pas recode mais il a le même problème que faire des caractères qui n'existe pas ?

J'espère t'avoir aidé, bon courage

AnsuzPeorth · Le 14/02/2009, à 17:53

Merci pour la réponse...(c'est tjrs intéressant)

Le problème c'est que je ne sais pas l'encodage en entrée (ce sont des tags mp3, et les noms de fichiers sont parfois eux aussi dans un encodage différent, c'est le bordel koi..., merci windows...).

J'ai donc contourné le problème (merci frafa, il etait mieux inspiré ce soir là ), je récupère les tags via eyeD3 qui converti correctement n'importe quel encodage (c'est donc possible). Bien que j'aime pas devoir ajouter des utilitaires, j'ai pas eu le choix sur ce coup !

Dernière modification par AnsuzPeorth (Le 14/02/2009, à 17:50)

aleph2 · Le 14/02/2009, à 19:27

> AnsuzPeorth

> .... merci windows...

Faut pas mettre sur le dos de Windows son incompétence. Il me semble avoir donné plus d'explications dû moins une ébauche, ici, http://forum.ubuntu-fr.org/viewtopic.php?id=274978

> le bordel koi...

Oui, c'est assez compliqué et ennuyeux. Le codage des noms de fichiers en fonction de la partition est quelque chose d'assez tordu et les conventions utilisées varient selon les plateformes.

Etonnamment, diraient certains, c'est sous Windows que cela fonctionne souvent le mieux. Par ex. "Linux" (Unix ?) ne gère pas la normalisation unicode !

Voir les nombreuses discussions épineuses à ce sujet pendant le développement de Python 3.
-> http://mail.python.org/pipermail/python-3000/

AnsuzPeorth · Le 15/02/2009, à 16:10

aleph2 a écrit :

Faut pas mettre sur le dos de Windows son incompétence.

T'es un champion des phrases sympathique toi....
Mon incompétences s'arrête à essayer de lire des tags de fichiers audio crée sous windows ou autre.
Si on suit ton raisonnement, c'est linux et tout les programmeurs qui y travaillent qui sont incompétents dans la conversion d'encodage d'un système à un autre (propose tes services, tu m'a l'air d'être un champion là dedans aussi).

aleph2 a écrit :

Il me semble avoir donné plus d'explications dû moins une ébauche, ici, http://forum.ubuntu-fr.org/viewtopic.php?id=274978

Des explications, oui, mais aucune ébauche de résolution du problème. Mais il n'existe aucune solution d'après toi, alors que eyeD3 converti n'importe quel encodage en encodage compatible linux, comment il fait lui ?

Mais bon, j'ai des connaissances très limités, je ne codes qu'un peu en bash, c'est tout..... Je suis d'ailleurs sur ce forum pour apprendre, et réduire mon champ "d'incompétences", qui est plutôt important d'ailleurs....

Comme je dis tjrs, "mes connaissances ne sont rien comparées à mon ignorance !" (pas assez de monde se le dit)

aleph2 · Le 15/02/2009, à 17:38

> AnsuzPeorth

Aucune impolitesse de ma part. J'ai écrit "incompétent" et non "incapable". Ce n'est pas la même chose. Il y a des tas de domaines où mon incompétence brille.

----

Ton problème réside probablement dans l'incompréhension (on le manque de compréhension) de tout ce qui touche au codage des caractères. C'est un sujet assez tordu qui pose des problèmes à bien du monde et qui n'est pas lié à un système d'exploitation.

Je n'ai pas la solution à ton problème, tes explications sont assez spartiates. Avec le peu d'informations à disposition, j'imagine que tu veux récupérer un genre de "playlist" à partir de noms de fichiers ou quelque chose comme ça et la manipuler par la suite. Si les noms de fichiers proviennent d'une partition fat, codage mbcs (lecteurs mp3 par ex.) et que ton application utilise une autre codage, cela coincera assez vite.

> ...fichiers audio crée sous windows ou autre....

> Si on suit ton raisonnement, c'est linux et tout les programmeurs qui y travaillent qui sont
> incompétents dans la conversion d'encodage d'un système à un autre (propose tes services, tu
> m'a l'air d'être un champion là dedans aussi).

Comme je l'ai dit, les codages, de façon général, n'ont rien à voir avec le système d'exploitation, et les codages des noms dans les systèmes de fichiers (un sous problème intrinsèque à lui tout seul) sont très variables, non seulement d'un système à l'autre (Windows, Unix, ...) mais aussi par ex. d'un "linux" à l'autre quand celui-ci utilise les "locales".

Je ne peux faire plus si ce n'est que de pointer l'origine du problème, et mon lien vers le développement de Python, illustre ces difficultés.

aleph2 · Le 15/02/2009, à 19:00

>Des explications, oui, mais aucune ébauche de résolution du problème. Mais il n'existe aucune solution d'après toi, alors que eyeD3 converti n'importe quel encodage en encodage compatible linux, comment il fait lui ?

Il y a 10 minutes je ne connaissais pas eyed3, cependant une recherche google, eyed3 + mbcs, donne quelques résultats. Comme d'habitude, il y du lard et du cochon; ne m'en demande pas plus. Ce que j'ai vu est que eyed3 est du Python et Python est très à l'aise avec tout ce qui touche au codage de caractères.

AnsuzPeorth · Le 15/02/2009, à 19:30

Faut vraiment que je me mette au python moi.....
Mais c'est tellement différent du bash, et le bash, finalement, c'est pas si mal pour ce que je fais !

Je pensais qu'il existait un utilitaire quelconque en bash pour effectuer la conversion de texte proprement. J'ai trouvé un truc qui pourrait m'aider, mais c'est du delphi...
http://www.delphifr.com/codes/CONNAITRE … 34491.aspx

Si au moins on pouvait connaître exactement, en bash , quel encodage est utilisé pour un texte ou caractères (j'ai pas trouvé, peut être pas cherché où il fallait...Et c'est vrai que c'est compliqué tout ça) !

aleph2 · Le 15/02/2009, à 20:28

> AnsuzPeorth

A voir bien les messages, il semblerait que les bash, awk et autres ne sont pas toujours à l'aise avec les codages.

Python gére très bien et nativement les codages. Mais, outre le langage, il ne faut pas perdre de vue que les limitations sont bien souvent imposées par le hardware, les os, les systèmes de fichiers.
Si par ex., dans Python 3, il y a deux fonctions os.getcwd() (get the path of the current working direcory) os.getcwd() et os.getcwdb(), l'une renvoyant un unicode et l'autre un byte string, c'est bien parce que la première ne fonctionne pas (par ex. certains Linux).

> Si au moins on pouvait connaître exactement, en bash , quel encodage est utilisé pour un texte ou caractères (j'ai pas trouvé, peut être pas cherché où il fallait...

La réponse est simple, déterminer le codage d'un "string" est impossible. Il faut toujours avoir conscience avec quel encodage l'on travaille. C'est pour cela qu'un fichier texte contient souvent une en-tête indiquant quel est son codage, par ex. le charset dans un "html", une marque, parfois c'est l'ensemble logiciel/os/hardware qui permet de le donner. Exemple : le codage des noms de fichiers Python / Window2000 / fat32 (encore faut il savair que c'est du fat !):

>>> sys.getfilesystemencoding()
mbcs
>>>

> Et c'est vrai que c'est compliqué tout ça) !
Rien d'insurmontable, c'est plus une affaire de compréhension informatique que de technique de programmation.

Hizoka · Le 06/11/2009, à 19:58

hop je remonte ce topic.

AnsuzPeorth as tu reussi à utiliser iconv ?

j'ai le même probleme...

exolium · Le 06/03/2017, à 23:12

Ce sujet date un peu (et je sais pas si la solution a été donné ailleurs) mais j'ai trouvé une solution a un problème similaire

iconv -f utf16 -t utf16 fichier.txt

vu que l'UTF8 a pas assez de caractères utf16 en a

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 11/02/2009, à 19:31

iconv UTF8: séquence d'échappement non permise

#2 Le 14/02/2009, à 15:10

Re : iconv UTF8: séquence d'échappement non permise

#3 Le 14/02/2009, à 17:53

Re : iconv UTF8: séquence d'échappement non permise

#4 Le 14/02/2009, à 19:27

Re : iconv UTF8: séquence d'échappement non permise

#5 Le 15/02/2009, à 16:10

Re : iconv UTF8: séquence d'échappement non permise

#6 Le 15/02/2009, à 17:38

Re : iconv UTF8: séquence d'échappement non permise

#7 Le 15/02/2009, à 19:00

Re : iconv UTF8: séquence d'échappement non permise

#8 Le 15/02/2009, à 19:30

Re : iconv UTF8: séquence d'échappement non permise

#9 Le 15/02/2009, à 20:28

Re : iconv UTF8: séquence d'échappement non permise

#10 Le 06/11/2009, à 19:58

Re : iconv UTF8: séquence d'échappement non permise

#11 Le 06/03/2017, à 23:12

Re : iconv UTF8: séquence d'échappement non permise

Pied de page des forums