The FSO is ill-advised for a number of reasons.

First, it is very slow. Dog slow.

Second, it is a fat library to load and map into your process' address space.

But most importantly it is rarely safe to assume that a text file where lines are delimited by naked LF characters is ASCII-encoded. LF-delimited ANSI is plain crazy and basically doesn't exist unless a real newb created it. Instead LF-delimited files should always be assumed to be UTF-8. The FSO doesn't handle UTF-8 properly, it assumes the text is ASCII (not even ANSI, only 7-bit ASCII).

If the files are relatively small just use an ADO.Stream instance to read them. At least it can handle Charset = "utf-8" and LineSeparator = adLF properly.

For larger files it might be worth rolling your own code from API calls. Just be sure you handle buffer management carefully. In particular you will need to use the MB_ERR_INVALID_CHARS flag with MultiByteToWideChar() in order to detect when a multibyte UTF-8 sequence has broken across buffer boundaries.