InputB vs. Get; pages de codes; lecture lente sur le serveur unix

Question

Nous avons utilisé le code habituel pour lire un fichier complet dans une chaîne pour ensuite analyser en VB6. Les fichiers sont des textes ANSI mais encodés en utilisant n'importe quelle page de code dans laquelle se trouvait l'utilisateur à la fois (nous avons des utilisateurs chinois et anglais par exemple). Voici le code

Open FileName For Binary As nFileUnit 
sContents = StrConv(InputB(LOF(nFileUnit), nFileUnit), vbUnicode) 

Cependant, nous avons découvert c'est la lecture très lent d'un fichier à partir d'un serveur exécutant unix/linux, en particulier lorsque la propriété du fichier est pas le même que le processus de faire la lecture.

J'ai réécrit ce qui précède en utilisant Get et découvert qu'il est beaucoup plus rapide et ne souffre pas de problèmes avec la propriété du fichier. J'apprécie que cela puisse être résolu en reconfigurant le serveur d'une manière ou d'une autre, mais je pense que depuis la désouverture même sans ce problème, la méthode Get est toujours beaucoup plus rapide que InputB que je voudrais remplacer mon code existant en utilisant Get.

Je me demande si quelqu'un pourrait me dire si cela va vraiment faire la même chose. En particulier, fait-il correctement la conversion ANSI à Unicode et sera-t-il toujours vrai. Mon test indique le code de remplacement suivant fait la même chose mais plus rapide:

Open FileName For Binary As nFileUnit 
    sContents = String(LOF(nFileUnit), " ") 
    Get #nFileUnit, , sContents 

Je me rends compte aussi que je pourrais utiliser un tableau d'octets, mais encore une fois mes tests suggèrent ce qui précède est plus simple et fonctionne. Donc, comment fonctionne le tampon (si vous croyez que l'aide en ligne de Get it parle de caractères - cela causerait des problèmes lors de la lecture dans un fichier ANSI écrit sur la page de code chinoise avec des caractères chinois de 2 octets).

Ce qui suit pourrait intéresser becuase l'approche InputB est généralement donnée comme méthode pour lire un dossier complet, mais il est beaucoup plus lent, des exemples

lecture du fichier 380KB à travers le réseau à partir du serveur unix

InputB (fichier appartenant) = 0,875 sec

InputB (non propriété) = 72,8 sec

Get (soit) = 0,0156 sec

Lecture d'un fichier 9Mb à travers le réseau à partir du serveur unix

InputB (fichier appartenant) = 19,65 sec

Get (soit) = 0,42 sec

Merci Jonathan

Answer 1

InputB() est CVar (InputB $()), et est connu pour être horriblement lent. Mon soupçon est que InputB $() lit les octets et les convertit en Unicode en utilisant la page de code actuelle via une logique stock pour lire le texte à partir du disque, puis effectue une autre conversion en ANSI en utilisant la page de codes actuelle.

Vous pouvez être très loin pour utiliser ADODB.Stream.LoadFromFile() pour charger des fichiers texte ANSI complets. Vous pouvez définir .Type = adTypeText et .Charset = le codage ANSI approprié comme requis pour lire Unicode en arrière via .ReadText (x) où x peut être un nombre d'octets, ou adReadAll ou adReadLine. Pour la lecture de ligne, vous pouvez définir .LineSeparator sur adCR, adCRLF ou adLF selon les besoins.

De nombreuses valeurs de charset sont supportées: KOI8 pour cyrillique, Big5 pour chinois, etc.