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

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

Salut, voir http://silkyroad.developpez.com/VB [...] aracteres/ avec Clean qui supprime les caractères non imprimables ?

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

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 = "°"
 
 

 
            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 !
 

 
            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 !
 

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
 
 
 
 

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...

 
            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.
 

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

j'ai mis un apercu du fichier dans le ZIP
Fichier : http://www.partage-fichiers.com/upload/wy7hwgnq
 
Utilisateur : p75cgpj3
Mot de passe : kvp1c1c6

 
            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 :
 

Sub Demo()
               TXT$ = ActiveDocument.Path & "\bug.txt"
        If Dir(TXT) = "" Then Beep: Exit Sub
                 C$ = Chr$(26)
    With CreateObject("ADODB.Stream" )
                 .Charset = "windows-1252"
                 .Open
                 .LoadFromFile TXT
        Do Until .EOS
            Debug.Print Replace$(.ReadText(-2), C, "°" )
        Loop
                 .Close
    End With
End Sub

            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  …
 

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

 
            Peu importe, le paramétrage d'extraction doit être corrigé si ce n'est la base elle-même …
 

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

 
            Stream étant plus rapide que FSO et vu le nombre de lignes …
 

A tester. Un truc un peu plus lent c'est mieux qu'un autre plus rapide qui plante...

 
            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 …
 

Il ne plante pas mais il renvoie un EOF pour un caractère qui n'est pas un EOF

Pour info : https://en.wikipedia.org/wiki/Substitute_character
Ca parle même du VB...

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  
 

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  

 
            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.
 

             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 …  
 

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.

 
             Péremptoire ?‼     Balaie devant ta porte !

             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 !
 
 

             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 !
 
 

             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)
 

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.  

 
             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 ‼
 

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.

 
            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 …
 

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

 
           Bonjour,
 
           voir déjà en utilisant l'objet Stream aussi pour l'écriture du fichier comme dans ton autre discussion …

 
           Sans pouvoir tester avec un fichier réel, je me demande si
           ce serait plus rapide d'effectuer directement un rechercher / remplacer dans Notepad++ …
 

c'est ce que je fait actuellement !
le soucis c'est qu'il me faut penser à le faire

 
           Et on aimerait bien voir aussi le code original ne mettant que 45 secondes …

 
           Au cas où, sait-on jamais …   (VBA Excel)
 

Sub Demo2()
        Dim oStr(1) As Object, C$, F, T!, N%, SP$(), S9 As String * 9
        C = ThisWorkbook.Path & "\"
        F = Array(C & "bug.txt", C & "result.txt" )
        If Dir(F(0)) = "" Then Beep: Exit Sub
        T = Timer
        C = Chr$(26)
    For N = 0 To 1
        Set oStr(N) = CreateObject("ADODB.Stream" )
            oStr(N).Charset = "x-ansi"
            oStr(N).Open
    Next
            oStr(0).LoadFromFile F(0)
   Do Until oStr(0).EOS
            SP = Split(oStr(0).ReadText(-2), "|" )
            S9 = SP(2)
            oStr(1).WriteText S9 & "%" & Replace$(SP(7), C, "°" ), 1
   Loop
            oStr(1).SaveToFile F(1), 2
    For N = 0 To 1
            oStr(N).Close
        Set oStr(N) = Nothing
    Next
        Debug.Print "Demo2 : "; Format(Timer - T, "0.000s" )
End Sub

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

 
            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 ?!