Lecture fichier TXT caractère parasite ° → - VB/VBA/VBS - Programmation
Marsh Posté le 18-02-2017 à 17:00:09
ben voila !
sur TXT il apparait
en VBA, il reste visible
en passant sur le forum, il disparait
le voila quand même
question :
comme faire pour que ce caractère spécial ne me fasse pas sortir de la macro ?
si vous lancez le code fourni, vous verrez (si le caractère est présent) que des qu'on arrive a ce caractère, la boucle se termine sans lire les ligne desous
Marsh Posté le 19-02-2017 à 06:30:13
Salut, voir http://silkyroad.developpez.com/VB [...] aracteres/ avec Clean qui supprime les caractères non imprimables ?
Marsh Posté le 19-02-2017 à 11:17:08
je suis allé voir
mais cela semble fonctionner pour excel
Cell.Value = Application.WorksheetFunction.Clean(Cell.Value)
je ne travaille que avec du TXT
j'ai bien essayé avec la fonction REPLACE, mais je n'y arrive pas
j'ai l'impression que cette petite flêche est considéré comme la fin du fichier
Marsh Posté le 19-02-2017 à 12:22:44
je viens de tester une autre solution, avec du VBS
http://wiki.dane.ac-versailles.fr/ [...] hier_texte
j'ai donc remplacé les caractères accentués su lien par
-une fleche
-un °
j'ai enregistré le VBS, et le l'ai lancé
et après verif du VBS , vola ce que je trouve
cette satanée flêche s'est transformée en ?
accents = "?"
pas_accents = "°"
Marsh Posté le 19-02-2017 à 16:33:09
Bonjour,
rien qu'avec un éditeur en hexadécimal pour voir le code du caractère
ou encore en VB / VBA / VBS avec la fonction ASC pour lire son code
bref, ce n'est vraiment pas compliqué de l'effacer via la fonction Replace …
Et comme ce n'est pas un caractère parasite mais faisant bel et bien partie de la source,
ce serait tellement plus judicieux d'intervenir côté SAP afin de produire une extraction propre !
Marsh Posté le 19-02-2017 à 16:38:02
Et si c'est juste une question d'encodage de caractères, donc encore une fois ce n'est pas un caractère parasite,
utiliser par exemple ADODB.Stream (cf documentation sur MSDN) pour effectuer la lecture du fichier texte
en spécifiant le bon encodage source. Qui plus est cet objet est bien plus rapide en lecture / écriture de fichier !
Marsh Posté le 20-02-2017 à 22:16:17
bonsoir
je sais bien qu'il serait judicieux de ne pas avoir ce caractère quand le fais l'extract sous SAP, mais je n'ai pas trouvé de solution via SAP
pour info, notepad++ affiche SUB à la place de ce caractère
il semblerai aussi qu'il soit reconnu comme chr(26)
aujourd'hui la solution la plus simple que j'ai trouvé fonctionne
j'edite avec notepad le fichier TXT
je cherche ce caractère, puis le remplace
ADODB.Stream, je ne connais pas, je ne vais pas me lancer la dessus
je suis quand confiant qu'il y a un moyen de dire a VBA de supprimer, convertir, ou ignorer ce caractère
Marsh Posté le 21-02-2017 à 00:21:45
Citation : aujourd'hui la solution la plus simple que j'ai trouvé fonctionne |
Si c'est ça la méthode retenu ça peut s'automatiser. L'outil Linux "sed" existe aussi pour Windows, c'est un petit exécutable de 50kB qu'on peut appeller depuis un batch avec les arguments qui vont bien: https://en.wikipedia.org/wiki/Sed#Substitution_command
edit: En supposant qu'il existe une commande system() ou autre en VBA on peut automatiser encore plus. Bien sûr c'est pas propre, mais si ça fait l'affaire...
Marsh Posté le 21-02-2017 à 00:34:14
Ce caractère existe-t-il bien côté SAP ou pas ? Dans le sens y-a-t-il bien un caractère après 90 ?
Aucun souci en VBA pour supprimer un caractère via la fonction Replace par exemple.
Si le fichier était accessible, je pourrais facilement me faire une idée …
ADODB.Stream étant bien plus rapide, facile en prendre en main, suffit de lire sa doc sur MSDN.
Marsh Posté le 21-02-2017 à 09:04:37
attention
je ne suis pas un administrateur sous SAP, juste un simple utilisateur
le caractère y est, je pense, je confirme ce soir
l'extract je le fais manuellement (en maintenant en vbscript) puis j'enregistre la liste obtenu
ce soir je vous posterai un apercu du fichier
Marsh Posté le 21-02-2017 à 20:55:15
j'ai mis un apercu du fichier dans le ZIP
Fichier : http://www.partage-fichiers.com/upload/wy7hwgnq
Utilisateur : p75cgpj3
Mot de passe : kvp1c1c6
Marsh Posté le 22-02-2017 à 00:09:47
Comme d'hab' encore une exportation de SAP un peu pourrie, au prix du logiciel et du gars chargé de son exploitation !
Un problème de paramétrage certainement à revoir car si c'est bien le caractère du degré ° présent dans la base
c'est franchement anormal de générer à la place le caractère standard de fin de fichier ‼
Voici une démonstration réalisant une lecture ligne à ligne en utilisant l'objet Stream plus rapide,
le caractère étant corrigé au passage, l'affichage est effectué dans la fenêtre Exécution du VBE :
Code :
|
Comme documenté sur MSDN cet objet peut aussi effectuer une lecture complète du fichier en mémoire en une passe
permettant d'extraire le nécessaire via la fonction VBA Split …
Marsh Posté le 22-02-2017 à 23:57:56
ok,
merci pour ce morceau de code
je vais essayer de l'adapter à mes besoins
pour ce qui est de l'extract avec des caractère farfelus, il faut savoir que ces données ont été mainte en mainte fois copiées, déplacées
certaines datent de 30ans, d'autre de 30j
les avoir toutes sur le même extract avec seulement ce soucis, je m'en accommoderai
Marsh Posté le 23-02-2017 à 11:35:18
Peu importe, le paramétrage d'extraction doit être corrigé si ce n'est la base elle-même …
Marsh Posté le 01-03-2017 à 10:30:53
Hello,
Ce n'est pas forcément que ta flèche (ou n'importe quel autre caractère étendu) est interprété comme un EOF.
Renvoyer EOF est aussi la façon que certaines API de lecture de fichiers mal branlées ont de te dire "erreur de lecture".
Je vais peut être dire une grosse bêtise parce que je ne fais pas de macro, mais plutôt qu'utiliser "Open" tu ne pourrais pas utiliser un Scripting.FileSystemObject et lui spécifier l'encoding ?
Ca permettrait de mieux gérer les caractères spéciaux. Avec un peu de chance il sera lu "tel quel" plutôt que fermer le flux, à défaut d'être lu comme un °.
edit : un truc comme ça si tu y as accès : http://stackoverflow.com/a/10997824/461444
Marsh Posté le 01-03-2017 à 11:19:25
Stream étant plus rapide que FSO et vu le nombre de lignes …
Marsh Posté le 01-03-2017 à 11:32:23
A tester. Un truc un peu plus lent c'est mieux qu'un autre plus rapide qui plante...
Marsh Posté le 01-03-2017 à 14:48:31
L'utilisant depuis des années il ne plante pas - sinon je n'aurais pas proposé le code plus haut ! - et il a plus de possibilités que FSO …
Marsh Posté le 01-03-2017 à 14:55:19
Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF
Marsh Posté le 01-03-2017 à 14:57:50
Pour info : https://en.wikipedia.org/wiki/Substitute_character
Ca parle même du VB...
Marsh Posté le 01-03-2017 à 21:28:39
Ne vous inquietez pas cela m'ira
cela semble fonctionner, il me faut juste l'adapter pour mon programme
Pour le moment, je fait à la méthode ....débutant
j'ouvre avec notepad, je cherche la satanée flêche, puis la remplace dans le document complet
Mais je suis au courant du problème et je connais une solution rapide
mais si je dois laisser quelqu'un d'autre utiliser le programme, il me faudra le fiabiliser, et je sais maintenant comment
Marsh Posté le 01-03-2017 à 21:32:01
Total recall, je l'avais vu cette page wiki
et j'avais bien identifié le problème et traduit comme cela sur mon premier post
"le problème que j'ai, c'est que la macro considère ce caractère comme ...fin de l'histoire"
mon soucis était de le contourner
et oui, sur wiki ils disent:
Some programming languages (e.g. Visual Basic) will not read past a "soft" EOF when using the built-in text file reading primitives (INPUT, LINE INPUT etc.), and alternate methods must be adopted, e.g. opening the file in binary mode or using the File System Object to progress beyond it.
le soucis c'est que je suis un débutant en tout !
et FSO je n'avais jamais utilisé
Merci en tout cas pour votre aide
Marsh Posté le 02-03-2017 à 01:32:05
FSO donne exactement le même résultat qu'avec Stream vu le fichier texte source
comme aurait dû le constater TotalRecall avec un éditeur hexadécimal ‼
Mon idée initiale était de rester en pur VBA avec une lecture en mode binaire
mais comme tu as indiqué un million de lignes j'ai préféré t'orienter vers Stream au lieu de FSO
sans compter la finalité non précisée …
Mais si tu préfères rester dans la banalité / généralité en utilisant FSO, aucun souci
et comme pour Stream sa documentation est consultable sur MSDN et à la portée d'un débutant.
Marsh Posté le 02-03-2017 à 01:41:46
TotalRecall a écrit : Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF |
T'as vu jouer cela où ? Et sans tester, bravo ! Il n'y a plus qu'à s'incliner devant une telle science infuse ‼
Stream et FSO renvoient exactement le même résultat et
ce n'est pourtant pas compliqué à vérifier, premier point à effectuer avant de poster une quelconque assertion …
Marsh Posté le 02-03-2017 à 09:26:55
Marc L a écrit :
Stream et FSO renvoient exactement le même résultat et |
Bonjour,
En plus d'avoir ta barre espace coincée dans chacun de tes posts, si tu as vu dans ce message une quelconque affirmation péremptoire il semble que tu aies aussi des problèmes de lecture.
daniel-12 arrive avec un souci de lecture où la fonction qu'il utilise ne sait pas interpréter un caractère et du coup interrompt complètement la lecture (c'est lui qui le dit) et du coup je lui suggère de tester une méthode alternative qui pourrait être exempte de ce problème. Ca ne me parait pas complètement déconnant comme approche, à défaut de pouvoir éviter la présence de ce caractère (ou d'autres qui produiraient la même anomalie) dans le flux à charger. Peut être effectivement que ça aurait produit la même anomalie, et je n'ai pas fait l'essai, j'ai juste dit que c'était à envisager vu que c'est rapide à faire.
Marsh Posté le 02-03-2017 à 11:13:13
Péremptoire ?‼ Balaie devant ta porte !
TotalRecall a écrit : mais plutôt qu'utiliser "Open" tu ne pourrais pas utiliser un Scripting.FileSystemObject et lui spécifier l'encoding ? |
Ici pas trop mais un peu quand même, la seconde assertion étant fausse, le fichier texte n'ayant même pas été ouvert !
Car une fois pour toute, le fichier ne contient pas le caractère ° mais bien → ! Et en cas de problème d'encodage
il y aurait des soucis sur d'autres caractères vu le fichier en exemple, il suffit juste de l'ouvrir !
Au passage si le fichier est encodé en utf-8 par exemple, comment « spécifier l'encoding » à FSO ?
Eclaire donc ma pauvre p'tite lanterne !
TotalRecall a écrit : A tester. Un truc un peu plus lent c'est mieux qu'un autre plus rapide qui plante... |
Là totalement péremptoire car toujours sans tester affirmant Stream plantant alors que cela fonctionne du côté du demandeur et du mien !
Et si tu tentes de te rattraper en affirmant que tu ne parlais pas de Stream, juste en relisant le fil pourtant,
il faudrait alors à l'avenir bien préciser ta pensée pour éviter de pouvoir mal interpréter tes dires !
TotalRecall a écrit : Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF |
Du péremptoire au plus haut degré ! Un léger mieux car il ne plante plus mais renvoyant un caractère pour un autre,
là encore on voit que le fichier texte n'a même pas été ouvert !
Pour moi c'est clos, j'attends juste un exemple FSO pour l'encoding, merci …
_______________________________________________________________________________________________________________
Deux choses sont infinies : l’Univers et la bêtise humaine.
Mais en ce qui concerne l’Univers, je n’en ai pas encore acquis la certitude absolue ! (Albert Einstein)
Marsh Posté le 02-03-2017 à 11:31:34
Tu le fais exprès ou quoi ? Si tu ouvres un fichier de 1 million de lignes et que ton API, quelle qu'elle soit, s'arrête de lire dès qu'elle rencontre un caractère qui ne lui plait pas, tu ne penses pas qu'on peut considérer ça comme une anomalie et suggérer des méthodes alternatives ?
Maintenant moi j'ai fini de te parler, tu peux remballer tes citations recyclées à toutes les sauces et attendre ce que tu veux aussi longtemps que tu voudras.
Marsh Posté le 02-03-2017 à 11:58:51
Mais de quelle API parles-tu enfin ?‼
C'est bien facile d'affirmer un truc et de se barrer en courant dès que l'on te demande une explication digne de ce nom ‼
Marsh Posté le 02-03-2017 à 20:27:00
Désolé Marc L, je ne mettrai pas en doutes tes compétences en VBA mais sur ce coup là je te trouve bien arrogant, surtout vu la citation d'Einstein que tu as posté. N'oublie pas que tu parles à un membre ayant 41363 messages sur ce forum et qui a dû aider pleins de gens, pas à un nouveau inscrit qui veut qu'on fasse son boulot et qui devient aggressif parce qu'on lui renvoye le reglèment ou quelque chose comme ça! Si TotalRecall se trompe (j'en sais rien) alors on peut en discuter tranquillement et avec des arguments (notamment un exemple de code).
Bon, je me mêle d'histoires qui ne me regardent pas mais sur ce coup là je n'ai pas pu m'en empêcher.
Marsh Posté le 02-03-2017 à 23:44:42
Ayant de mon côté déjà posté un exemple de code et pour le reste j'ai été clair, n'ayant rien vu de concret en retour …
Marsh Posté le 05-05-2017 à 22:17:24
Code :
|
Bonsoir
Marc, j'ai utilisé ton code pour enlever le caractère parasite, mais j'ai un soucis
c'est long
par exemple, si je traite un fichier de 1 500 000 lignes, je mettais 45s pour le traiter (sous reserve d'avoir edité le caractère avant)
avec le code posté, qui édite le caractère, et traite ensuite le fichier, je mets 290s
ou est ce que je peux améliorer le code
les lignes sont faite comme cela
|PLA|F00010021 |00|000|SAPGEC |OF|ENS GEOMETRIES ST2 |18.06.2003| |
|PLA|F00010021-H00 |00|000|SAPEXPL |OF|ENS GEOMETRIES ST2 |09.06.2003| |
|PLA|F00010021_001 |00|000|SAPGEC |OF|ENS GEOMETRIES ST2 |18.06.2003| |
|PLA|F00010021_001_H00 |00|000|SAPEXPL |OF|ENS GEOMETRIES ST2 |09.06.2003| |
ce que je veux extraire c'est=> F00010021%ENS GEOMETRIES ST2
Marsh Posté le 06-05-2017 à 09:31:00
Bonjour,
voir déjà en utilisant l'objet Stream aussi pour l'écriture du fichier comme dans ton autre discussion …
Marsh Posté le 06-05-2017 à 09:51:43
Sans pouvoir tester avec un fichier réel, je me demande si
ce serait plus rapide d'effectuer directement un rechercher / remplacer dans Notepad++ …
Marsh Posté le 06-05-2017 à 09:57:12
c'est ce que je fait actuellement !
le soucis c'est qu'il me faut penser à le faire
Marsh Posté le 06-05-2017 à 09:59:10
Et on aimerait bien voir aussi le code original ne mettant que 45 secondes …
Marsh Posté le 06-05-2017 à 10:38:42
Au cas où, sait-on jamais … (VBA Excel)
Code :
|
Marsh Posté le 06-05-2017 à 11:33:10
sur un petit fichier cela marche, pas sur un gros
erreur exécution 9, l'indice n'appartient pas a la sélection
et cela garde les 4 lignes, j'ai donc des doublons
Marsh Posté le 06-05-2017 à 11:44:29
Oui les doublons sont conservés comme dans ton code et
c'est tellement plus facile quand le besoin est clairement expliqué !
L'erreur provient du fichier ne correspondant pas à ce que tu as posté et,
sans indication précise de la ligne du fichier source et de la ligne de code déclenchant cette erreur,
je ne pourrais deviner, tout au plus ajouter un test dans le code mais allongeant donc l'exécution …
Donc il faut extraire les codes de la deuxième colonne sur neuf caractères,
écrire dans le fichier résultat si ce n'est pas un doublon tout en remplaçant le caractère parasite,
what else ?!
Marsh Posté le 18-02-2017 à 16:53:56
bonjour
j'ai fais un macro qui permet de lire le contenu d'un fichier texte et qui en extrait certaines infos
cela fonctionne bien, la macro me convient parfaitement
en moins de 15s je lit des fichiers de 1 000 000 lignes et le résultat est 10 fois moins lourd
bref parfait, enfin presque !
certains fichiers textes contiennent un caractère parasite
il ressemble a cela →
il correspond à degré, ou °
il provient d'extracts que j'ai fait via SAP=>TXT
le problème que j'ai, c'est que la macro considère ce caractère comme ...fin de l'histoire
jugez par vous même
logiquement avec ce code les 7 ligne devraient être lu
dans la réalité, avec ce caractère, la dernière et les suivante seront ignorées
car après 90→ la macro sort
Message édité par daniel-12 le 18-02-2017 à 17:17:03