Re: The Bug of ReadLine?
- From: "Michael Harris \(MVP\)" <mikhar at mvps dot org>
- Date: Fri, 26 Aug 2005 15:15:35 -0700
DiGiTAL SKReAM wrote:
> Michael,
> Do you have a different link for that thread? The technet newgroups
> on MS' site only go back to sometime in 2004, and some of us *cough*
> are proxied out of google groups. heh heh
Copy/pasted below...
1. HJK Nov 4 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "HJK" <h...@xxxxxxxxxx> - Find messages by this author
Date: 2000/11/04
Subject: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
Have a problem with reading and writing a textfile in WSH. If the file
contains hex'00' codes the output file gets corrupted, if not all works
beautifully. Even basic code something like:
Set fso = CreateObject("Scripting.FileSystemObject")
Set inFile = fso.OpenTextFile("c:\testfile.txt", 1,true, 0)
Set outFile = fso.CreateTextFile("c:\testOfile.txt", True)
'do until end of file on infile.. yadda yadda
r = infile.readline
outfile.write r
' end yadda yadda
infile.close
outfile.close
Just read and write, no manipulation of anything the output file gets
corrupted, just after the binary zeros, it appears that for every one x'00'
code, you get about 10 in the output file, overwriting portions of the input
record. The script is running on an NT server, using the latest WSH and
VBScript.
Apologies, but unfortunately I cannot access newsgroups from the office, and
I haven't got the exact code with me, but the example is very close.
Anyone else have this problem?
2. Michael Harris Nov 4 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Michael Harris" <Please.Re...@xxxxxxxxxxxx> - Find messages by this
author
Date: 2000/11/04
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
I just used *your* code and tried to duplicate the problem and can't (WSH
2.0 on a Win98SE box).
The input file looked like:
line 1$abc
line 2$abc
etc...
where the $ is actually a hex 0.
The output file looks just like the input except that all the CR+LF pairs
have been stripped since
you use Write instead of WriteLine.
--
Michael Harris
Microsoft.MVP.Scripting
--
- Hide quoted text -
- Show quoted text -
"HJK" <h...@xxxxxxxxxx> wrote in message
news:Ol2CszpRAHA.225@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Have a problem with reading and writing a textfile in WSH. If the file
> contains hex'00' codes the output file gets corrupted, if not all works
> beautifully. Even basic code something like:
> Set fso = CreateObject("Scripting.FileSystemObject")
> Set inFile = fso.OpenTextFile("c:\testfile.txt", 1,true, 0)
> Set outFile = fso.CreateTextFile("c:\testOfile.txt", True)
> 'do until end of file on infile.. yadda yadda
> r = infile.readline
> outfile.write r
> ' end yadda yadda
> infile.close
> outfile.close
> Just read and write, no manipulation of anything the output file gets
> corrupted, just after the binary zeros, it appears that for every one
> x'00'
> code, you get about 10 in the output file, overwriting portions of the
> input
> record. The script is running on an NT server, using the latest WSH and
> VBScript.
> Apologies, but unfortunately I cannot access newsgroups from the office,
> and
> I haven't got the exact code with me, but the example is very close.
> Anyone else have this problem?
3. HJK Nov 5 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "HJK" <h...@xxxxxxxxxx> - Find messages by this author
Date: 2000/11/05
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
Thanks Michael. Could you try it with writeline? It should have been... my
mistake!
"Michael Harris" <Please.Re...@xxxxxxxxxxxx> wrote in message
news:efVz9PrRAHA.258@xxxxxxxxxxxxxx
> I just used *your* code and tried to duplicate the problem and can't (WSH
2.0 on a Win98SE box).
> The input file looked like:
> line 1$abc
> line 2$abc
> etc...
> where the $ is actually a hex 0.
> The output file looks just like the input except that all the CR+LF pairs
have been stripped since
> you use Write instead of WriteLine.
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
> "HJK" <h...@xxxxxxxxxx> wrote in message
news:Ol2CszpRAHA.225@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
- Hide quoted text -
- Show quoted text -
> > Have a problem with reading and writing a textfile in WSH. If the file
> > contains hex'00' codes the output file gets corrupted, if not all works
> > beautifully. Even basic code something like:
> > Set fso = CreateObject("Scripting.FileSystemObject")
> > Set inFile = fso.OpenTextFile("c:\testfile.txt", 1,true, 0)
> > Set outFile = fso.CreateTextFile("c:\testOfile.txt", True)
> > 'do until end of file on infile.. yadda yadda
> > r = infile.readline
> > outfile.write r
> > ' end yadda yadda
> > infile.close
> > outfile.close
> > Just read and write, no manipulation of anything the output file gets
> > corrupted, just after the binary zeros, it appears that for every one
x'00'
> > code, you get about 10 in the output file, overwriting portions of the
input
> > record. The script is running on an NT server, using the latest WSH and
> > VBScript.
> > Apologies, but unfortunately I cannot access newsgroups from the office,
and
> > I haven't got the exact code with me, but the example is very close.
> > Anyone else have this problem?
4. Michael Harris Nov 5 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Michael Harris" <Please.Re...@xxxxxxxxxxxx> - Find messages by this
author
Date: 2000/11/05
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
Sure --- now the output file is identical to the input file...
Given an ordinary ASCII text file (even one with some null characters
sprinkled in), using FSO
TextStream methods to open them as ASCII files and read/write (or
readline/writeline) isn't going to
do anything strange.
I get the distinct impression that there's some important detail that you're
leaving out.
--
Michael Harris
Microsoft.MVP.Scripting
--
- Hide quoted text -
- Show quoted text -
"HJK" <h...@xxxxxxxxxx> wrote in message
news:O4hAMkzRAHA.232@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thanks Michael. Could you try it with writeline? It should have been... my
> mistake!
> "Michael Harris" <Please.Re...@xxxxxxxxxxxx> wrote in message
> news:efVz9PrRAHA.258@xxxxxxxxxxxxxx
> > I just used *your* code and tried to duplicate the problem and can't
> > (WSH
> 2.0 on a Win98SE box).
> > The input file looked like:
> > line 1$abc
> > line 2$abc
> > etc...
> > where the $ is actually a hex 0.
> > The output file looks just like the input except that all the CR+LF
> > pairs
> have been stripped since
> > you use Write instead of WriteLine.
> > --
> > Michael Harris
> > Microsoft.MVP.Scripting
> > --
> > "HJK" <h...@xxxxxxxxxx> wrote in message
> news:Ol2CszpRAHA.225@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > Have a problem with reading and writing a textfile in WSH. If the file
> > > contains hex'00' codes the output file gets corrupted, if not all
> > > works
> > > beautifully. Even basic code something like:
> > > Set fso = CreateObject("Scripting.FileSystemObject")
> > > Set inFile = fso.OpenTextFile("c:\testfile.txt", 1,true, 0)
> > > Set outFile = fso.CreateTextFile("c:\testOfile.txt", True)
> > > 'do until end of file on infile.. yadda yadda
> > > r = infile.readline
> > > outfile.write r
> > > ' end yadda yadda
> > > infile.close
> > > outfile.close
> > > Just read and write, no manipulation of anything the output file gets
> > > corrupted, just after the binary zeros, it appears that for every one
> x'00'
> > > code, you get about 10 in the output file, overwriting portions of the
> input
> > > record. The script is running on an NT server, using the latest WSH
> > > and
> > > VBScript.
> > > Apologies, but unfortunately I cannot access newsgroups from the
> > > office,
> and
> > > I haven't got the exact code with me, but the example is very close.
> > > Anyone else have this problem?
5. HJK Nov 5 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "HJK" <h...@xxxxxxxxxx> - Find messages by this author
Date: 2000/11/05
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
Thanks again,
I guess I wasn't clear on this, it seems to be corrupting the file on an NT
server box I run the script on. One difference on the files I'm working on
is that there are several x'00' in a row.. perhaps 7-8 something like that,
when the file is copied, it's corrupted. Not sure yet if it happens on the
read or write.
The script I'm using is doing more than just copying the file, but the
simple sample I gave originally was still corrupting the file. I suspected I
found a bug. The records are also quite long (>2-300 bytes). I haven't had a
chance to do further testing to see if a specific combination of data is
required to cause the corruption.
I was kinda hoping someone else would have the same problem! Hopefully I'll
get a chance to do more testing tomorrow at the office.
"Michael Harris" <Please.Re...@xxxxxxxxxxxx> wrote in message
news:uUz9fx3RAHA.245@xxxxxxxxxxxxxx
> Sure --- now the output file is identical to the input file...
> Given an ordinary ASCII text file (even one with some null characters
sprinkled in), using FSO
> TextStream methods to open them as ASCII files and read/write (or
readline/writeline) isn't going to
> do anything strange.
> I get the distinct impression that there's some important detail that
you're leaving out.
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
> "HJK" <h...@xxxxxxxxxx> wrote in message
news:O4hAMkzRAHA.232@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
- Hide quoted text -
- Show quoted text -
> > Thanks Michael. Could you try it with writeline? It should have been...
my
> > mistake!
> > "Michael Harris" <Please.Re...@xxxxxxxxxxxx> wrote in message
> > news:efVz9PrRAHA.258@xxxxxxxxxxxxxx
> > > I just used *your* code and tried to duplicate the problem and can't
(WSH
> > 2.0 on a Win98SE box).
> > > The input file looked like:
> > > line 1$abc
> > > line 2$abc
> > > etc...
> > > where the $ is actually a hex 0.
> > > The output file looks just like the input except that all the CR+LF
pairs
> > have been stripped since
> > > you use Write instead of WriteLine.
> > > --
> > > Michael Harris
> > > Microsoft.MVP.Scripting
> > > --
> > > "HJK" <h...@xxxxxxxxxx> wrote in message
> > news:Ol2CszpRAHA.225@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > > Have a problem with reading and writing a textfile in WSH. If the
file
> > > > contains hex'00' codes the output file gets corrupted, if not all
works
> > > > beautifully. Even basic code something like:
> > > > Set fso = CreateObject("Scripting.FileSystemObject")
> > > > Set inFile = fso.OpenTextFile("c:\testfile.txt", 1,true, 0)
> > > > Set outFile = fso.CreateTextFile("c:\testOfile.txt", True)
> > > > 'do until end of file on infile.. yadda yadda
> > > > r = infile.readline
> > > > outfile.write r
> > > > ' end yadda yadda
> > > > infile.close
> > > > outfile.close
> > > > Just read and write, no manipulation of anything the output file
gets
> > > > corrupted, just after the binary zeros, it appears that for every
one
> > x'00'
> > > > code, you get about 10 in the output file, overwriting portions of
the
> > input
> > > > record. The script is running on an NT server, using the latest WSH
and
> > > > VBScript.
> > > > Apologies, but unfortunately I cannot access newsgroups from the
office,
> > and
> > > > I haven't got the exact code with me, but the example is very close.
> > > > Anyone else have this problem?
6. Michael Harris Nov 5 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Michael Harris" <Please.Re...@xxxxxxxxxxxx> - Find messages by this
author
Date: 2000/11/05
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
"HJK" <h...@xxxxxxxxxx> wrote in message
news:u6ZmS#5RAHA.227@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thanks again,
> I guess I wasn't clear on this, it seems to be corrupting the file on an
> NT
> server box I run the script on. One difference on the files I'm working on
> is that there are several x'00' in a row.. perhaps 7-8 something like
> that,
> when the file is copied, it's corrupted. Not sure yet if it happens on the
> read or write.
OK, more details makes a lot of difference - now I can duplicate the
problem.
In the (very contrived) test script below, a one line file is written, read,
and rewritten multiple
times.
- It starts with a "record layout" of a string of 10 "a" characters followed
by 10 chr(0) null
characters for a total of 20 characters.
- It makes several passes, growing the length of the "record" each time by
another 20 characters in
the same pattern.
- On each pass, it compares what was written (s) with what was read back (r)
and pops up the msgbox
when there is a discrepancy.
- Everything is fine until the pass for n = 14 (and greater), at which point
the data read back does
not match what was written.
- Checking the versions of the infile that were written shows that they are
all fine, so that means
the data is being corrupted when it is read by readline.
- I tried another variation using read (commented out in the test script)
instead of readline since
I could calculate the length to read based on the value of n for that pass
and it worked fine every
time, so the bug appears to be only in the ReadLine method.
=== test script ==============================
set fso = createobject("scripting.filesystemobject")
for n = 2 to 32
x = right("0" & n, 2)
set infile = fso.opentextfile("d:\infile" & x & ".txt", 2,true, 0)
t = string(10,"a") & string(10,chr(0))
redim w(n)
s = join(w,t)
infile.writeline s
infile.close
set infile = fso.opentextfile("d:\infile" & x & ".txt", 1,true, 0)
set outfile = fso.createtextfile("d:\outfile" & x & ".txt", true)
r = infile.readline
'========================
' using read works OK...
'r = infile.read(n * 20)
'infile.skip 2
'========================
outfile.writeline r
infile.close
outfile.close
if s <> r then msgbox(n)
next
--
Michael Harris
Microsoft.MVP.Scripting
--
7. Michael Harris Nov 5 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Michael Harris" <Please.Re...@xxxxxxxxxxxx> - Find messages by this
author
Date: 2000/11/05
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
A thought to get you around the ReadLine bug...
I assume your "data records" never contain any binary data that matches a
CR+LF pair except at the
end of each line in the file. If the file isn't too big (more than a few
meg) you could try a
single shot ReadAll inside a split...
arLines = split(infile.readall,vbcrlf))
and walk the arLines array one row at a time...
--
Michael Harris
Microsoft.MVP.Scripting
--
- Hide quoted text -
- Show quoted text -
"Michael Harris" <Please.Re...@xxxxxxxxxxxx> wrote in message
news:eMTSfo6RAHA.88@xxxxxxxxxxxxxx
> "HJK" <h...@xxxxxxxxxx> wrote in message
> news:u6ZmS#5RAHA.227@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Thanks again,
> > I guess I wasn't clear on this, it seems to be corrupting the file on an
> > NT
> > server box I run the script on. One difference on the files I'm working
> > on
> > is that there are several x'00' in a row.. perhaps 7-8 something like
> > that,
> > when the file is copied, it's corrupted. Not sure yet if it happens on
> > the
> > read or write.
> OK, more details makes a lot of difference - now I can duplicate the
> problem.
> In the (very contrived) test script below, a one line file is written,
> read, and rewritten
multiple
> times.
> - It starts with a "record layout" of a string of 10 "a" characters
> followed by 10 chr(0) null
> characters for a total of 20 characters.
> - It makes several passes, growing the length of the "record" each time by
> another 20 characters
in
> the same pattern.
> - On each pass, it compares what was written (s) with what was read back
> (r) and pops up the
msgbox
> when there is a discrepancy.
> - Everything is fine until the pass for n = 14 (and greater), at which
> point the data read back
does
> not match what was written.
> - Checking the versions of the infile that were written shows that they
> are all fine, so that
means
> the data is being corrupted when it is read by readline.
> - I tried another variation using read (commented out in the test script)
> instead of readline
since
> I could calculate the length to read based on the value of n for that pass
> and it worked fine
every
> time, so the bug appears to be only in the ReadLine method.
> === test script ==============================
> set fso = createobject("scripting.filesystemobject")
> for n = 2 to 32
> x = right("0" & n, 2)
> set infile = fso.opentextfile("d:\infile" & x & ".txt", 2,true, 0)
> t = string(10,"a") & string(10,chr(0))
> redim w(n)
> s = join(w,t)
> infile.writeline s
> infile.close
> set infile = fso.opentextfile("d:\infile" & x & ".txt", 1,true, 0)
> set outfile = fso.createtextfile("d:\outfile" & x & ".txt", true)
> r = infile.readline
> '========================
> ' using read works OK...
> 'r = infile.read(n * 20)
> 'infile.skip 2
> '========================
> outfile.writeline r
> infile.close
> outfile.close
> if s <> r then msgbox(n)
> next
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
8. Al Dunbar Nov 6 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Al Dunbar" <Al_Dun...@xxxxxxxxxxx> - Find messages by this author
Date: 2000/11/06
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
"so the bug appears to be only in the ReadLine method". I take it, then,
that you consider this problem to be introduced by a certain behaviour of
the ReadLine method. Is this a "bug" or is the problem that the term
"TextFile" is somehow not appropriately or completely defined?
The set of characters normally considered appropriate in a "text file"
include all of the printable characters, plus certain non-printing control
characters such as CR, LF, TAB. Since elsewhere in this NG it has been
mentioned that WSH does not allow for generalized binary I/O, perhaps this
is simply an undocumented result of applying a text-file oriented method to
what is ultimately a binary file. The fact that readline can apparently deal
with the existence of *some* binary characters (i.e. a single x'00', or
perhaps the BEL character) would therefore be only an interesting side
effect.
Perhaps a list of all characters that are considered as appropriate in a
"text file" should be developed and published in an article on the msdn
website.
/Al
"Michael Harris" <Please.Re...@xxxxxxxxxxxx> wrote in message
news:eMTSfo6RAHA.88@xxxxxxxxxxxxxx
> "HJK" <h...@xxxxxxxxxx> wrote in message
news:u6ZmS#5RAHA.227@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
- Hide quoted text -
- Show quoted text -
> > Thanks again,
> > I guess I wasn't clear on this, it seems to be corrupting the file on an
NT
> > server box I run the script on. One difference on the files I'm working
on
> > is that there are several x'00' in a row.. perhaps 7-8 something like
that,
> > when the file is copied, it's corrupted. Not sure yet if it happens on
the
> > read or write.
> OK, more details makes a lot of difference - now I can duplicate the
problem.
> In the (very contrived) test script below, a one line file is written,
read, and rewritten multiple
> times.
> - It starts with a "record layout" of a string of 10 "a" characters
followed by 10 chr(0) null
> characters for a total of 20 characters.
> - It makes several passes, growing the length of the "record" each time by
another 20 characters in
> the same pattern.
> - On each pass, it compares what was written (s) with what was read back
(r) and pops up the msgbox
> when there is a discrepancy.
> - Everything is fine until the pass for n = 14 (and greater), at which
point the data read back does
> not match what was written.
> - Checking the versions of the infile that were written shows that they
are all fine, so that means
> the data is being corrupted when it is read by readline.
> - I tried another variation using read (commented out in the test script)
instead of readline since
> I could calculate the length to read based on the value of n for that pass
and it worked fine every
- Hide quoted text -
- Show quoted text -
> time, so the bug appears to be only in the ReadLine method.
> === test script ==============================
> set fso = createobject("scripting.filesystemobject")
> for n = 2 to 32
> x = right("0" & n, 2)
> set infile = fso.opentextfile("d:\infile" & x & ".txt", 2,true, 0)
> t = string(10,"a") & string(10,chr(0))
> redim w(n)
> s = join(w,t)
> infile.writeline s
> infile.close
> set infile = fso.opentextfile("d:\infile" & x & ".txt", 1,true, 0)
> set outfile = fso.createtextfile("d:\outfile" & x & ".txt", true)
> r = infile.readline
> '========================
> ' using read works OK...
> 'r = infile.read(n * 20)
> 'infile.skip 2
> '========================
> outfile.writeline r
> infile.close
> outfile.close
> if s <> r then msgbox(n)
> next
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
9. Michael Harris Nov 6 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Michael Harris" <Please.Resp...@xxxxxxxxxxxx> - Find messages by this
author
Date: 2000/11/06
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
(inline)
"Al Dunbar" <Al_Dun...@xxxxxxxxxxx> wrote in message
news:t0dtujr4n1ov54@xxxxxxxxxxxxxxxxxxxxx
> "so the bug appears to be only in the ReadLine method". I take it, then,
> that you consider this problem to be introduced by a certain behaviour of
> the ReadLine method. Is this a "bug" or is the problem that the term
> "TextFile" is somehow not appropriately or completely defined?
Anything in the 7-bit ASCII character set should be considered valid,
regardless of whether or not
all possible 7-bit values produce "printable" characters.
> The set of characters normally considered appropriate in a "text file"
> include all of the printable characters, plus certain non-printing control
> characters such as CR, LF, TAB. Since elsewhere in this NG it has been
> mentioned that WSH does not allow for generalized binary I/O, perhaps this
> is simply an undocumented result of applying a text-file oriented method
> to
> what is ultimately a binary file. The fact that readline can apparently
> deal
> with the existence of *some* binary characters (i.e. a single x'00', or
> perhaps the BEL character) would therefore be only an interesting side
> effect.
I'll agree that "unprintable" characters are generally not used in ordinary
text files. However,
neither the VBScript and/or FSO documentation says nothing that implies that
only a subset of 7-bit
ASCII is supported except as noted below...
> Perhaps a list of all characters that are considered as appropriate in a
> "text file" should be developed and published in an article on the msdn
> website.
> /Al
In the HTMLHelp (offline) version of the VBScript documentation, under
Language Reference /
Miscellaneous are 2 charts of the supported 8-bit ASCII characters.
Of the 256 possible characters , only 17 are marked as "unsupported on the
current platform" (most
in the upper 128). Even then, exactly what "unsupported on the current
platform" actually means
isn't defined.
In any case, Chr(0) is *not* one of them. Even though ASCII is only the
7-bit portion of the ANSI
character set, VBScript/FSO actually supports ANSI (when is says ASCII) for
file i/o (everything is
UNICODE internally anyway).
If these charts are in the online docs, I certainly don't know how to find
them...
--
Michael Harris
Microsoft.MVP.Scripting
--
10. Al Dunbar Nov 6 2000, 1:00 am show options
Newsgroups: microsoft.public.scripting.vbscript
From: "Al Dunbar" <Al_Dun...@xxxxxxxxxxx> - Find messages by this author
Date: 2000/11/06
Subject: Re: TextFile problem
Reply to Author | Forward | Print | Individual Message | Show original |
Report Abuse
"Michael Harris" <Please.Resp...@xxxxxxxxxxxx> wrote in message
news:#OAAoCDSAHA.250@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> (inline)
> "Al Dunbar" <Al_Dun...@xxxxxxxxxxx> wrote in message
news:t0dtujr4n1ov54@xxxxxxxxxxxxxxxxxxxxx
<snip>
> In the HTMLHelp (offline) version of the VBScript documentation, under
Language Reference /
> Miscellaneous are 2 charts of the supported 8-bit ASCII characters.
> Of the 256 possible characters , only 17 are marked as "unsupported on the
current platform" (most
> in the upper 128). Even then, exactly what "unsupported on the current
platform" actually means
> isn't defined.
> In any case, Chr(0) is *not* one of them. Even though ASCII is only the
7-bit portion of the ANSI
> character set, VBScript/FSO actually supports ANSI (when is says ASCII)
for file i/o (everything is
> UNICODE internally anyway).
> If these charts are in the online docs, I certainly don't know how to find
them...
I would infer from the problem presented here, however, that, in order to
write "safe" code, one should at least appreciate that there is some
ambiguity here when it comes to the treatment of the chr(0) character, and
possibly others. As you suggest, Readall is a good solution for files of
"reasonable" size; is there a good solution for the general case? I suppose
buck-passing may be the method of choice, by putting a disclaimer into the
documentation of one's own code: "Please note that the program may produce
invalid results in the event that the input file contains non-printing
characters".
/Al
- Hide quoted text -
- Show quoted text -
--
Michael Harris
Microsoft MVP Scripting
.
- References:
- Re: The Bug of ReadLine?
- From: Michael Harris \(MVP\)
- Re: The Bug of ReadLine?
- From: DiGiTAL SKReAM
- Re: The Bug of ReadLine?
- Prev by Date: Re: Script to show active directory user objects
- Next by Date: move old files to different folder
- Previous by thread: Re: The Bug of ReadLine?
- Next by thread: cut & paste
- Index(es):
Relevant Pages
|
