Reprise du message précédent :
 
            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 ?!

non, mon code enlevait les doublons    
 
If Mid(SC, 15, 1) = " " Then
Print #1, Mid(SC, 6, 9) & "%" & Mid(SC, 55, 40)  
End If

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 UNIQUEMENT cela=>  
F00010021%ENS GEOMETRIES ST2
 
 
donc ce que j'ai fais, c'est un test après F00010021, et s'il y a un espace je traite cette ligne
cette méthode est suffisante, vu comment sont les données

ton code sous excel, fonctionne juste en mettant on error resume next, juste avant la boucle for
 
la raison est qu'il y a, parfois, pas de ligne avec |
c'est les entête des extracts
 
 
Documents sélectionn.:    31.025
-----------------------------------------------------------------------------------------------------------------
|Ty.|Document                 |Vs|DPt|Gestionnaire|St|Description                             |Du        |TéSupp|
-----------------------------------------------------------------------------------------------------------------
|PLA|F000.50103               |00|000|TO00508     |VL|wings complete                          |16.06.2010|      |
|PLA|F000.50103.001           |00|000|TO00508     |VL|wings complete                          |16.06.2010|      |

 
           Oui tu as raison, restons simple !
           Avec un fichier big.txt de 440 000 lignes reproduit à partir du bug.txt originel il faut moins de dix secondes :
 

Sub Demo3()
              Dim oTF As Object, P$, F$, T!, SP$(), S2 As String * 9, S$
                    P = ThisWorkbook.Path & "\"
                    F = P & "big.txt":  If Dir(F) = "" Then Beep: Exit Sub
                    T = Timer
    With CreateObject("Scripting.FileSystemObject" )
              Set oTF = .OpenTextFile(P & "result.txt", 2, True)
        With .OpenTextFile(F, 1)
            Do Until .AtEndOfStream
                   SP = Split(.ReadLine, "|" )
              If UBound(SP) > 6 Then
                   S2 = SP(2)
                If S2 <> S Then
                  oTF.WriteLine S2 & "%" & Replace$(SP(7), Chr$(26), "°" )
                  S = S2
                End If
              End If
            Loop
                .Close
        End With
    End With
                  oTF.Close
              Set oTF = Nothing
    Debug.Print "Demo3 : "; Format(Timer - T, "0.000s" )
End Sub

Oui restons simple,  
ce dernier code fonctionne bien, et super rapide en plus
 
la détection du dernier caractère en fin de n° (15eme) comme étant un espace est suffisante
 
forcément il y a quelques n° qui sont mal écris, mais pas grave
ou des n° qui n'en sont pas
 
par exemple sur un fichier j'avais  
-149 232 ligne (traitées correctement)
-149 726 ligne (traité a la truelle, mais 5 x plus vite)
3.3% d'écart sur le 2eme traitement, mais ces lignes en trop ne sons en fait pas gênante pour ce que j'en fais ensuite
 
 

 
           Là je compare juste le numéro de la ligne avec celui de la ligne précédente, c'est suffisant si le fichier est bien classé par numéro.
 
           Garde quand même dans un coin de l'esprit ADODB.Stream en cas de conversion d'encodage de caractères
           ou utile encore pour traiter des fichiers en binaire …
 

il devait ressembler à cela, mais sans le début qui maintenant corrige le pb de flèche=>°
J'étais donc obligé d' éditer le caractère avec notepad++ avant de lancer l'extraction
 cela prennait ensuite 45s sur un i7 47xx de mémoire

aujourd'hui 102s sur un i5 2540, mais avec la correction intégrée à la macro
pour 1 231 235 lignes / 138mo

Ta version sous Excel prend 16s     (sur le I5 avec le fichier de 1 231 235 lignes)

 
           Une variante de Demo3 car certes obligé à cause de la "flèche" d'en passer par FSO pour la lecture
           mais pas du tout pour l'écriture, j'ai oublié l'interne au VBA, grattant au passage presque une seconde :
 

Sub Demo4()
              Dim oTF As Object, P$, F$, T!, SP$(), S2 As String * 9, S$
                    P = ThisWorkbook.Path & "\"
                    F = P & "big.txt":  If Dir(F) = "" Then Beep: Exit Sub
                    T = Timer
               Open P & "result.txt" For Output As #9
    With CreateObject("Scripting.FileSystemObject" ).OpenTextFile(F, 1)
        Do Until .AtEndOfStream
                   SP = Split(.ReadLine, "|" )
            If UBound(SP) > 6 Then
                   S2 = SP(2)
                If S2 <> S Then
                  Print #9, S2 & "%" & Replace$(SP(7), Chr$(26), "°" )
                  S = S2
                End If
            End If
        Loop
                 .Close
    End With
               Close
               Debug.Print "Demo4 : "; Format(Timer - T, "0.000s" )
End Sub

Merci pour ton aide !
cela m'a permis de comprendre un peu ou progresser sur les fonctions patern, ADODB, split,  
cela m'évitera maintenant d'éditer le fichier source pour enlever le caractère, chose que j'oubliai 1 fois sur 2 !
 
retranscrire ton dernier code en VBS est compliqué ?
je dis cela car l'extrac, le deplacement des fichier, le renommage, le fais tout cela avec du VBS, mais le "comprimer", je le faisais en VBA (bien plus compréhensible pour moi)

 
           Comme il n'y a pas de gestion de fichier intégrée au VBScript, il faut partir non pas de Demo4 mais de Demo3 !
           Et pour tester l'existence du fichier source, la fonction Dir n'existant pas non plus en VBScript,
           utiliser la fonction FileExists de la librairie FileSystemObject …
           Rien d'autre, donc Demo3 est facile à transposer en VBScript !
 

le fichier existera forcement, car il aura juste été créé auparavant
le repertoire de sauvegarde est connu
 
je vais essayer de le faire
merci

 
            Et j'ai oublié les variables forcément sans type en VBScript, donc la variable S2 doit être alimentée via la fonction Left :
 

                    F = "big.txt"
With CreateObject("Scripting.FileSystemObject" )
    If Not .FileExists(F) Then
        MsgBox "Fichier source manquant !", 48, WScript.ScriptName
        WScript.Quit 1
    End If
              Set oTF = .OpenTextFile("result.txt", 2, True)
    With .OpenTextFile(F, 1)
        Do Until .AtEndOfStream
                   SP = Split(.ReadLine, "|" )
            If UBound(SP) > 6 Then
                   S2 = Left(SP(2), 9)
                If S2 <> S Then
                  oTF.WriteLine S2 & "%" & Replace(SP(7), Chr(26), "°" )
                  S = S2
                End If
            End If
        Loop
                 .Close
    End With
End With
                  oTF.Close
              Set oTF = Nothing
MsgBox "Extraction terminée !", 64, WScript.ScriptName

Bien !
simple et efficace
 
If UBound(SP) > 6 Then
c'est pour tester la "largeur du tableau ?
c'est a dire que si le tableau a moins de x colonnes alors c'était une ligne ne comprenant pas de séparateurs |
c'est ça ?

 
            Oui car sinon pour une ligne bidon  SP(7)  déclenche forcément une erreur #9 …
 
            Toujours éviter  On Error Resume Next  quand c'est possible pour ne pas masquer d'autres erreurs non prévues !
            Et si c'est vraiment nécessaire, parfois il suffit juste d'externaliser dans une mini procédure ou une fonction …
 

bien vu
 
pour quoi 6 ?
c'est arbitraire
 
1 a 9 marchait si j'ai bien compris le code

 
            Pourtant je l'ai écrit en gras et ce n'est pas arbitraire car le plus gros indice utilisé dans le code est 7 !
 
            Sinon effectivement pour être sûr de la ligne respectant bien le format attendu, vérifier alors
            le dernier indice est bien égal à 10 comme consultable dans la fenêtre Variables locales en VBA.
            (Ou en calculant visuellement une fois la fonction Split assimilée …)