j'ai un fichier texte (convertion pdf/texte faite avec automator) que
j'ai du mal à lire.
le dump du début du fichier donne :
00000000: FF FE 4C 00 6F 00 6F 00 ..L.o.o.
00000008: 6B 00 69 00 6E 00 67 00 k.i.n.g.
00000010: 20 00 66 00 6F 00 72 00 .f.o.r.
00000018: 20 00 52 00 65 00 61 00 .R.e.a.
00000020: 6C 00 20 00 45 00 78 00 l. .E.x.
...
il semblere donc que se soit du 'UTF-16 Little Endian' puisque le
fichier commence avec FF FE.
je lis le fichier de cette manière :
open(FH, "< :encoding(UTF-16)", $fileName)
or die "Error openning $fileName: $!\n";
while (<FH>) {
chomp;
print ">>$_\n";
}
ce qui donne :
>>Looking for Real Exam Questions for IT Certification Exams!
We guarantee you can pass any IT certification exam at your first
attempt with just 10-12
hours study of our guides.
Our study guides contain actual exam questions, you will get word to
word same on your actual test; accurate answers with detailed
explanation verified by experts and all graphics and drag-n-drop
exhibits shown just as on the real test.
To test the quality of our guides, you can download the one-fourth
portion of any guide from http://www.certificationking.com absolutely free.
...
à chaque boucle, plusieurs lignes sont lues dans le fichier.
le CR semble ignoré. pourtant le dump montre bien un CR(0x0D) à la fin
de chaque ligne :
00000070: 61 00 6D 00 73 00 21 00 a.m.s.!.
00000078: 0D 00 57 00 65 00 20 00 ..W.e. .
^^
donc, comment ligne ligne par ligne un fichier en UTF-16 ?
autre problème, à l'execution du perl, il y a des tas d'erreur du genre:
Wide character in print <FH> line X.
perl n'aime pas certain caracteres ?
$ od -c out 0000000 > > O h l e b e l 303 251 l 303 0000020 251 p h a n t r n > > O h l e 0000040 b e l 303 251 l 303 251 p h a n t r n 0000060 > > r n 0000064
-- François Lafont
Bonsoir,
Juste pour info, je n'ai pas de problème pour lire un fichier
utf-16 LE sur ma Debian Wheezy avec Perl 5.14.2 et avec ce bout
de code (test.pl) :
$ od -c out
0000000 > > O h l e b e l 303 251 l 303
0000020 251 p h a n t r n > > O h l e
0000040 b e l 303 251 l 303 251 p h a n t r n
0000060 > > r n
0000064
$ od -c out 0000000 > > O h l e b e l 303 251 l 303 0000020 251 p h a n t r n > > O h l e 0000040 b e l 303 251 l 303 251 p h a n t r n 0000060 > > r n 0000064
-- François Lafont
Olivier Miakinen
Bonjour,
Je ne connais pas (encore) perl et je ne suis pas sur Macintosh, mais peut-être que cette observation pourra être utile :
Le 02/06/2014 02:05, Francois Lafont répondait à kurtz le pirate :
Juste pour info, je n'ai pas de problème pour lire un fichier utf-16 LE sur ma Debian Wheezy avec Perl 5.14.2 et avec ce bout de code (test.pl) :
Ton fichier, lu sur Linux, contient 0d 00 suivi de 0a 00 (CR + LF) alors que le fichier de kurtz le pirate, qui est sur Mac, ne contient que 0D 00 (CR seul).
Cordialement, -- Olivier Miakinen
Bonjour,
Je ne connais pas (encore) perl et je ne suis pas sur Macintosh, mais
peut-être que cette observation pourra être utile :
Le 02/06/2014 02:05, Francois Lafont répondait à kurtz le pirate :
Juste pour info, je n'ai pas de problème pour lire un fichier
utf-16 LE sur ma Debian Wheezy avec Perl 5.14.2 et avec ce bout
de code (test.pl) :
Ton fichier, lu sur Linux, contient 0d 00 suivi de 0a 00 (CR + LF)
alors que le fichier de kurtz le pirate, qui est sur Mac, ne contient
que 0D 00 (CR seul).
Ton fichier, lu sur Linux, contient 0d 00 suivi de 0a 00 (CR + LF) alors que le fichier de kurtz le pirate, qui est sur Mac, ne contient que 0D 00 (CR seul).
Cordialement, -- Olivier Miakinen
Nicolas George
kurtz le pirate , dans le message <538896ab$0$2048$, a écrit :
à chaque boucle, plusieurs lignes sont lues dans le fichier. le CR semble ignoré. pourtant le dump montre bien un CR(0x0D) à la fin de chaque ligne :
Le caractère CR n'a aucune signification particulière pour la délimitation des lignes. Tu confonds avec LF.
kurtz le pirate , dans le message
<538896ab$0$2048$426a34cc@news.free.fr>, a écrit :
à chaque boucle, plusieurs lignes sont lues dans le fichier.
le CR semble ignoré. pourtant le dump montre bien un CR(0x0D) à la fin
de chaque ligne :
Le caractère CR n'a aucune signification particulière pour la délimitation
des lignes. Tu confonds avec LF.
À (at) 02 Jun 2014 07:41:25 GMT, Nicolas George <nicolas$ écrivait (wrote):
kurtz le pirate , dans le message <538896ab$0$2048$, a écrit :
à chaque boucle, plusieurs lignes sont lues dans le fichier. le CR semble ignoré. pourtant le dump montre bien un CR(0x0D) à la fin de chaque ligne :
Le caractère CR n'a aucune signification particulière pour la délimitation des lignes. Tu confonds avec LF.
Quelle drôle d'affirmation ! Il semble que vous n'avez jamais travaillé avec un Mac. Lisez le début de 'perlport' pour en savoir plus...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
espie
Par contre, un fichier en UTF16 avec des CR comme fin de ligne, c'est original. Me semblait que cette horreur d'UTF16 etait restee cantonnee a Windows ? mais peut-etre me trompe-je et rencontre-t-on ca aussi sur mac.
Par contre, un fichier en UTF16 avec des CR comme fin de ligne, c'est
original. Me semblait que cette horreur d'UTF16 etait restee cantonnee a
Windows ? mais peut-etre me trompe-je et rencontre-t-on ca aussi sur mac.
Par contre, un fichier en UTF16 avec des CR comme fin de ligne, c'est original. Me semblait que cette horreur d'UTF16 etait restee cantonnee a Windows ? mais peut-etre me trompe-je et rencontre-t-on ca aussi sur mac.
Nicolas George
Paul Gaborit , dans le message , a écrit :
Quelle drôle d'affirmation ! Il semble que vous n'avez jamais travaillé avec un Mac.
Un OS pourri mort depuis le siècle dernier ? En effet, ça inexiste.
Paul Gaborit , dans le message <wt9tx83itnk.fsf@mirabeau.mines-albi.fr>,
a écrit :
Quelle drôle d'affirmation ! Il semble que vous n'avez jamais travaillé
avec un Mac.
Un OS pourri mort depuis le siècle dernier ? En effet, ça inexiste.
Du troll bien velu ? Ou alors votre expérience sur Mac date du siècle dernier...
Le pseudo-Unix qu'apple fourgue de nos jours utilise LF comme séparateur de lignes.
Paul Gaborit
À (at) 02 Jun 2014 21:03:49 GMT, Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit , dans le message , a écrit :
Du troll bien velu ? Ou alors votre expérience sur Mac date du siècle dernier...
Le pseudo-Unix qu'apple fourgue de nos jours utilise LF comme séparateur de lignes.
C'est un Unix (pas plus pseudo que n'importe quel Linux ou *BSD) qui utilise LF seul. Mais il y aussi de nombreux progammes en GUI qui continuent à utiliser le CR seul. Au passage, rien ne l'interdit même en dehors d'un Mac. C'est une convention comme une autre pour un fichier texte.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) 02 Jun 2014 21:03:49 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
Paul Gaborit , dans le message <wt9lhtfjbdn.fsf@mirabeau.mines-albi.fr>,
a écrit :
Du troll bien velu ? Ou alors votre expérience sur Mac date du siècle
dernier...
Le pseudo-Unix qu'apple fourgue de nos jours utilise LF comme séparateur de
lignes.
C'est un Unix (pas plus pseudo que n'importe quel Linux ou *BSD) qui
utilise LF seul. Mais il y aussi de nombreux progammes en GUI qui
continuent à utiliser le CR seul. Au passage, rien ne l'interdit même en
dehors d'un Mac. C'est une convention comme une autre pour un fichier
texte.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) 02 Jun 2014 21:03:49 GMT, Nicolas George <nicolas$ écrivait (wrote):
Paul Gaborit , dans le message , a écrit :
Du troll bien velu ? Ou alors votre expérience sur Mac date du siècle dernier...
Le pseudo-Unix qu'apple fourgue de nos jours utilise LF comme séparateur de lignes.
C'est un Unix (pas plus pseudo que n'importe quel Linux ou *BSD) qui utilise LF seul. Mais il y aussi de nombreux progammes en GUI qui continuent à utiliser le CR seul. Au passage, rien ne l'interdit même en dehors d'un Mac. C'est une convention comme une autre pour un fichier texte.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Nicolas George
Paul Gaborit , dans le message , a écrit :
C'est un Unix (pas plus pseudo que n'importe quel Linux ou *BSD)
Assez peu respectueux des standards, à part quand apple graisse les rouage des comités de certification. Et absolument pas respectueux des usages.
Au passage, rien ne l'interdit même en dehors d'un Mac. C'est une convention comme une autre pour un fichier texte.
Non. Un fichier texte au sens Unix, et partant au sens Perl, est formé de lignes (de moins de 1024 caractères) terminées par LF. C'est spécifiquement défini. Les applications standard de la toolbox Unix ne sont pas tenues d'être capables de digérer quoi que ce soit d'autres, même si c'est évidemment mieux qu'elles le soient.
Paul Gaborit , dans le message <wt9k38zdjwl.fsf@mirabeau.mines-albi.fr>,
a écrit :
C'est un Unix (pas plus pseudo que n'importe quel Linux ou *BSD)
Assez peu respectueux des standards, à part quand apple graisse les rouage
des comités de certification. Et absolument pas respectueux des usages.
Au passage, rien ne l'interdit même en
dehors d'un Mac. C'est une convention comme une autre pour un fichier
texte.
Non. Un fichier texte au sens Unix, et partant au sens Perl, est formé de
lignes (de moins de 1024 caractères) terminées par LF. C'est spécifiquement
défini. Les applications standard de la toolbox Unix ne sont pas tenues
d'être capables de digérer quoi que ce soit d'autres, même si c'est
évidemment mieux qu'elles le soient.
C'est un Unix (pas plus pseudo que n'importe quel Linux ou *BSD)
Assez peu respectueux des standards, à part quand apple graisse les rouage des comités de certification. Et absolument pas respectueux des usages.
Au passage, rien ne l'interdit même en dehors d'un Mac. C'est une convention comme une autre pour un fichier texte.
Non. Un fichier texte au sens Unix, et partant au sens Perl, est formé de lignes (de moins de 1024 caractères) terminées par LF. C'est spécifiquement défini. Les applications standard de la toolbox Unix ne sont pas tenues d'être capables de digérer quoi que ce soit d'autres, même si c'est évidemment mieux qu'elles le soient.
