(Courriels de diversion: <percevrai@suralimentes-supposant.com> <ressoudaient@residuelles-oppresseras.com> <regentee@accorde-tisses.com> <pochee@urgees-invariabilite.com> <transcoderions@deposent-nichiez.com> <microfilmerais@reboises-contre-attaquais.com> <paraissait@cartonnerai-rebattraient.com> <allechait@denonceras-intelligibles.com> <rebiffee@crachin-concentrationnaires.com> <arraisonneras@redemptrice-comptabiliserent.com> )
Bonjour, Je risque de donner une réponse à côté de la plaque car je ne suis pas certain de bien comprendre votre besoin et la signification de LFS (Linux From Scratch ?). Mais j'essaie quand même. popov a écrit : | Linuxien sous LFS, je me retrouve un peu coincé, j'ai rappatrié un tas | de fichier de doc. | Helas certains fichiers sont accentués, ce qui me pose un pb sous | LFS puisque il n'est pas capable de reconnaitre les [é]. J'ai decidé | de faire du menage en ecrivant un script shell qui va prendre tous | les fichiers comportant le [é] et les remplacer par [e] mais je | m'aperçois qui je ne dispose pas du caracteres [é] (a faire passer | dans le regex de sed) . Le problème de la conversion de fichiers MS-Word est un tantinet complexe. Sa résolution dépend notamment du jeu de caractères que vous utilisez sur votre système. Il faut en fait procéder à deux opérations : 1. Extraire du document MS-Word le texte brut. 2. Convertir le texte brut (encodé avec un jeu de caractères MS-Windows) en un texte lisible sous GNU/Linux. Antiword est censé s'occuper de cela tout seul mais, pour plusieurs raisons, il le fait mal si on ne prend pas un minimum de précautions et que l'on ne retraite pas sa sortie... Avant de présenter la solution, il faut dresser un état des lieux. Généralement, en Europe de l'Ouest, on utilise : - sous MS-Windows, le jeu de caractères CP1252, avec une fin de ligne encodée par la paire de caractères <CR><LF> ou '\r\n' en notation C ; - sous GNU/linux, le jeu de caractères ISO-8859-15 (Latin-9) ou le désuet ISO-8859-1 (Latin-1), avec une fin de ligne encodée par l'unique caractère <LF> ou '\n' en notation C. Le problème est que ces jeux de caractères ne sont pas strictement équivalents dans la mesure où certains caractères d'un jeu n'ont pas d'équivalent dans l'autre jeu. Il en va ainsi du caractère « 3 points de suspension » du jeu CP1252, sans équivalent en Latin-9. Il faut alors remplacer ce caractère par 3 caractères « point ». Or, Antiword ne sait pas faire cela. )c: Heureusement, Recode sait le faire ! Mais ce dernier ne sait par contre pas extraire le texte brut d'un fichier MS-Word... )c: Argh... Dilemme, comment faire ? Il faut passer par le jeu de caractères Unicode et utiliser de manière combinée Antiword et Recode. En effet, l'Unicode est complet dans la mesure où il reprend notamment l'ensemble des caractères des autres jeux. Il est donc toujours possible de convertir un texte vers l'Unicode (la réciproque n'étant évidemment pas vraie). Par conséquent : 1. Il faut demander à Antiword d'extraire le texte brut du document MS-Word en encodant la sortie en Unicode : $ antiword -w 0 -m UTF-8.txt document.doc > document.tmp NB : le « -w 0 » demande une sortie « au kilomètre ». Autrement dit, chaque paragraphe est rendu sur une seule ligne, sans insertion de sauts de ligne pour formatage du texte. 2. Il faut demander à Recode de convertir la sortie d'Antiword en Latin-9 : $ recode u8..l9 < document.tmp > document.txt On peut écrire cela sur une seule ligne en redirigeant le flux de sortie d'Antiword : $ antiword -w 0 -m UTF-8.txt document.doc | recode u8..l9 > document.txt Pour être exhaustif, je dois revenir sur le problème des fins de lignes que j'évoquais en début de mail. En effet, si le texte que vous devez convertir a été écrit sous MS-Windows non pas avec MS-Word mais avec un simple Notepad ou autre éditeur de texte, ce problème se pose. Les sauts de lignes font partie des éléments que Recode baptise « surfaces ». Pour notre plus grand bonheur, Recode sait gérer les surfaces et propose de nombreuses conversions. Dans note cas, nous avons le plus souvent en entrée un texte encodé en CP1252/<CR><LF> et, en sortie, nous voulons du Latin-9/<LF>. La commande Recode correspondante est : $ recode cp1252/cl..l9/ document.txt ou, pour ne pas écraser l'entrée : $ recode cp1252/cl..l9/ < entree.txt > sortie.txt Pour ce qui est de la valeur associée à chaque caractère, Recode en fournit la liste commentée sous forme décimale, octale et héxadécimale en tapant la commande : $ recode -lf l9 ou : $ recode -lf cp1252 selon le jeu de caractères considéré. Dernière remarque sur Antiword. Ce dernier sait traiter les fichiers contenant plus de 1 ko de texte brut (fichiers d'environ 10 ko) mais pas ceux de taille inférieure. J'ai contacté voici quelques temps le développeur d'Antiword à ce sujet. Il m'a dit que cela venait d'un encodage différent des données selon que le texte était court ou long (blocs de taille différente). S'il a compris comment étaient encodés les blocs longs, il n'a pas encore eu le même succès avec les blocs courts mais il y travaille... Voilà ! En espérant ne pas avoir été hors sujet... Sébastien -- Sébastien Dinot, sdinot@april.orgSecrétaire de l'APRIL (http://www.april.org) Association pour la Promotion et la Recherche en Informatique Libre -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>