"effectivement je ne rajoute pas un 0 à la fin... mais pourquoi le faire ??"
Parce que que les tableaux de caractères c DOIVENT se terminer par le charactère de valeur entière 0 (\0), sinon, les fonctions de manipulation -calcul de la longueur, affichage, conversion en string- donnent des résultats bizarres... Comme, à l'initialisation, un tableau de chars peut être rempli de caractères nuls, cette nécessité peut être cachée, donnant l'illusion qu'un bout de code marche... mais il vaut mieux le faire explicitement.
En passant, il ne faut pas confondre un caractère et son équivalent entier; exemple, le caractère 'a' a pour valeur, en entier 97 -en decimal- ou 0x61 -en hexa-; le caractère '9' a pour representation entière 57, 0x39 et le carctère '0' est codé en 48 -0x30-
sh-4.1$ python
ordPython 2.7.3 (default, Dec 18 2012, 13:50:09)
[GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
(>>> ord('a')
97
>>> ord('9')
57
>>> ord('0')
48
>>> chr(0x39)
'9'
>>> chr(0x30)
'0'
HBachetti vous indique une piste bien plus prometteuse que le fait de sauter des caractères cachés (et on ne sait pas comment faire, sans bricoler, pour lire , disons, les 3 derniers numéros de téléphone; avec une lecture plus standard de votre fichier, c'est plus facile.
A noter que si votre fichier a été créé sous windows, il y a 2 caractères cachés pour le changement de ligne : \n -10 - et \r -13 (on les montre généralement comme ça...). Sous linux, il n'y en a qu'un (donc, les fichiers texte crées sous GNUlinux peuvent parfois sembler bizarres à des applications d'un autre système).
Il est vraisemblable (mais encore une fois, sans le fichier, on doit faire des paris) que l'on saute les fins de ligne -qui sont des caractères cachés-. A noter enfin que le filtrage que j'utilise fait un pari sur la liste des caractères valides pour les numéros de téléphone (la démarche de HBachetti est plus rationnelle, même si elle "marche" peut être un peu moins vite au début)