Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > microsoft.public.scripting.vbscript > #11623 > unrolled thread

WriteLine fails with error 5 (bad argument) on a string ?

Back to article view | Back to microsoft.public.scripting.vbscript

Contents

  WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-18 14:14 +0200
    Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-18 09:06 -0400
      Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-18 16:44 +0200
        Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-18 18:50 -0400
          Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-19 11:39 +0200
            Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-19 09:22 -0400
              Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-19 17:27 +0200
                Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-19 13:49 -0400
                  Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-20 17:56 +0200
                    Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-20 13:24 -0400
                      Re: WriteLine fails with error 5 (bad argument) on a string ? Ulrich Möller <knobbi38@arcor.de> - 2017-04-21 01:05 +0200
                        Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-20 21:42 -0400
                          Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-21 10:11 +0200
                      Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-21 09:23 +0200
    Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-18 09:57 -0400
      Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-18 17:20 +0200
        Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-18 14:27 -0400
          Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-18 22:15 +0200
            Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-18 18:30 -0400
              Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-19 11:09 +0200
                Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-19 09:23 -0400
                Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-19 09:59 -0400
                  Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-19 17:41 +0200
      Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-18 11:58 -0400
      Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-26 09:56 -0400
        Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-26 16:35 +0200
          Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-26 10:44 -0400
        Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-26 11:07 -0400
        Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-26 16:29 -0400
          Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-26 21:26 -0400
            Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-26 23:28 -0400
              Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 01:11 -0400
                Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-28 09:28 -0400
                  Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 15:22 -0400
                    Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-28 19:16 -0400
                      Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 22:08 -0400
                        Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 22:11 -0400
                          Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 22:17 -0400
                        Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 22:21 -0400
                          Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-28 22:37 -0400
                            Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-29 00:01 -0400
                              Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-29 01:19 -0400
                            Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-29 01:46 -0400
                              Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-29 12:36 -0400
                                Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-29 19:59 -0400
                                  Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-29 20:18 -0400
                          Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 23:50 -0400
                    Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-28 19:29 -0400
                      Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 22:04 -0400
                        Re: WriteLine fails with error 5 (bad argument) on a string ? "Mayayana" <mayayana@invalid.nospam> - 2017-04-28 22:25 -0400
                          Re: WriteLine fails with error 5 (bad argument) on a string ? GS <gs@v.invalid> - 2017-04-28 22:31 -0400
    Re: WriteLine fails with error 5 (bad argument) on a string ? Ulrich Möller <knobbi38@arcor.de> - 2017-04-18 19:20 +0200
      Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-18 19:58 +0200
        Re: WriteLine fails with error 5 (bad argument) on a string ? Ulrich Möller <knobbi38@arcor.de> - 2017-04-19 14:59 +0200
          Re: WriteLine fails with error 5 (bad argument) on a string ? "R.Wieser" <address@not.available> - 2017-04-19 16:46 +0200

Page 1 of 3  [1] 2 3  Next page →

#11623 — WriteLine fails with error 5 (bad argument) on a string ?

Hello all,

Partially a "gotcha" story, partially a question.  Here goes:

I've retrieved a webpages content using the XMLHTTP object, and than
attempted to write the "responseText" result into a file.  Easy enough, just
use "<fileobject>.write <httpobject>.responseText" you would say.  I would
too.

But for some unfathomable reason it (sometimes) fails with an err.number of
5 ....

After quite a bit of head-scratching and testing it turns out there are
characters in that response that Write(Line) cannot handle*, and it barfs.
Funny thing is that wscript.echo has absolutily no problem with putting the
string onto the screen though (so why the difference?).


*Which char can't it handle ?   Good question.   I copied all characters
between " " and "~" as well as bCR and vbLF to another string (which was
succesfully written to the file!), and displayed both the remaining symbols
as well as their ASCII values.   It apeared that its the the char "?" with
ASCII code 63 thats causing the problems.

Whoa, wait!    Isn't that char between " " (32) and "~" (126) ?   Yup, it
is. :-)

So, what is going on ?   I take it its VBScript and its conversion of
wide-string chars to ASCII thats playing peek-a-boo with us: the "?" is the
default replacement character for any wide-character it cannot convert into
an equivalent ASCII character.

So, how do I figure out which (wide-)char is actually the problem (I take it
all are, but just for the sake of argument) ?   Thats a problem: I can't get
its value, and I can't write it to file either (and than check it with some
other program).  A nice catch22, ain't it :-D

tl;dr:
How do I get a fileobject to write a string to file regardless of the
combination of bytes in it (write it as a multi-byte string) ?

Bonus question (for when the first is impossible): How do I convert a string
into one I can actually write to a file WITHOUT having to go thru it
byte-by-byte (copy the aceptable ones into a new string and write that one)
?   I've already tried CStr and Trim, but neither are helpfull. :-\

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#11624

Lots of gotchas with UTF-8. For what it's worth, you
can look here:

http://www.jsware.net/jsware/scrfiles.php5#u2a

It's 3 different methods of converting between UTF-8
and ANSI.

  In general a page that's UTF-8 should say so in a
META charset tag, which will at least help to reduce
the work. Unfortunately, it's become politically
correct to use UTF-8 even where it's not needed.
Microsoft pagesare a good example. They use UTF-8
characters for curly quotes and spaces, neither of
which is necessary. It makes a mess when trying to
save their pages. 

[toc] | [prev] | [next] | [standalone]

#11626

Mayayana,

> Lots of gotchas with UTF-8. For what it's worth,
> you can look here:

Thanks for that link.

There seems to be a problem though: my own tries to extract a single byte
from a string seem to show that that isn't possible.  Also, trying to get
the value of the retrieved (unicode) character (using "asc(...)" shows I get
an already-converted value, not the origional unicode one.

For a moment I was flabbergasted: how come that code works using the same
method as I was using in my script ("mid( )" followed by "asc( )") and mine
has problems and his doesn't.   But than I realized that that most likely
has to do with his script reading the file as if its ASCII, thereby breaking
up the multiple bytes of a multibyte char, storing them as seperate chars.

In other words: another catch 22 : I could parse the "responseText" string
contents if I would first write them to a file and than read it back as
ASCII, but than I would first need to be able to write it to a file* ... :-D

As for the conversion itself ?   I do not really want to have it converted
to ASCII, but just to a format which will be acceptable to Write /
WriteLine, allowing me to write an exact copy of what is retrieved from the
website to file.

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od52se$kfs$1@dont-email.me...
> Lots of gotchas with UTF-8. For what it's worth, you
> can look here:
>
> http://www.jsware.net/jsware/scrfiles.php5#u2a
>
> It's 3 different methods of converting between UTF-8
> and ANSI.
>
>   In general a page that's UTF-8 should say so in a
> META charset tag, which will at least help to reduce
> the work. Unfortunately, it's become politically
> correct to use UTF-8 even where it's not needed.
> Microsoft pagesare a good example. They use UTF-8
> characters for curly quotes and spaces, neither of
> which is necessary. It makes a mess when trying to
> save their pages.
>
>

[toc] | [prev] | [next] | [standalone]

#11634

"R.Wieser" <address@not.available> wrote

| As for the conversion itself ?   I do not really want to have it converted
| to ASCII, but just to a format which will be acceptable to Write /
| WriteLine, allowing me to write an exact copy of what is retrieved from 
the
| website to file.

   I don't understand why it's not working. As long as
there are no nulls it should be writable. WSH is not
really writing ASCII. It's writing ANSI. As far as I know
it doesn't recognize UTF-8, so I would think it should
write the string normally as ANSI in accord with your
codepage.

  Either way, if you write UTF-8 to disk you'll need
to read it as UTF-8. But I don't find any problem
writing high characters. If I write the UTF-8 marker,
239-187-191 in a string it works. If I write it at
the front of a string it disappears when opened in
notepad, as expected. In both cases it writes fine. 

[toc] | [prev] | [next] | [standalone]

#11636

Mayayana,

>    I don't understand why it's not working.

The problem is that it cannot write an unicode* character (anything with an
"ascii-code" larger than 255) to simple, ASCII-style file.

*wrong, not really specific, name, see below.

> As long as there are no nulls it should be writable.

Variant strings are length-counted, and cause no problem when you try to
write embedded NULs to a file (been there, done that).

>   Either way, if you write UTF-8 to disk you'll need
> to read it as UTF-8.

The problem is that I need to write it to file first (the "read it" part
might in my case well not been done by VBS). :-)

> If I write the UTF-8 marker, 239-187-191 in a string it works

That is because you're still writing (extended) ASCII, embedding
*multi-byte* characters.

And checking the 'Web just now (googeling "unicode vs wide-character"), I
see I made a mistake: I've been referring to the way VBScript stores its
strings as being "unicode", when infact its using "wide character" (aka: all
chars are of the same size, in this case 16 bits).

When you try to write a wide-character with a codepoint larger than 255 to
an ASCII-style file it simply barfs (even though it has no problems with
"wscript.echo"-ing the string!).

And alas, the webpage thats retrieved seems to contain a few multi-byte
characters *which get converted into wide-characters* and stored as such in
the string ...

And, as it turns out, applying "asc(  )" on a wide-character symbol does not
return its codepoint, but it gets converted to ASCII first, and as such
returns the default "cannot convert" replacement-characters value: 63 (the
questionmark).

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od6535$f2m$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | As for the conversion itself ?   I do not really want to have it
converted
> | to ASCII, but just to a format which will be acceptable to Write /
> | WriteLine, allowing me to write an exact copy of what is retrieved from
> the
> | website to file.
>
>    I don't understand why it's not working. As long as
> there are no nulls it should be writable. WSH is not
> really writing ASCII. It's writing ANSI. As far as I know
> it doesn't recognize UTF-8, so I would think it should
> write the string normally as ANSI in accord with your
> codepage.
>
>   Either way, if you write UTF-8 to disk you'll need
> to read it as UTF-8. But I don't find any problem
> writing high characters. If I write the UTF-8 marker,
> 239-187-191 in a string it works. If I write it at
> the front of a string it disappears when opened in
> notepad, as expected. In both cases it writes fine.

[toc] | [prev] | [next] | [standalone]

#11638

"R.Wieser" <address@not.available> wrote

| And checking the 'Web just now (googeling "unicode vs wide-character"), I
| see I made a mistake: I've been referring to the way VBScript stores its
| strings as being "unicode", when infact its using "wide character" (aka: 
all
| chars are of the same size, in this case 16 bits).
|
   I think it's getting confused. VBS deals with ASCII
or unicode-16, which is 2 bytes per character. What
VBS is really dealing with is ANSI. 1 byte per
character, with 128+ interpeted according to the
local codepage. UTF-8 is unicode, but it's written
as a kind of ANSI multi-byte encoding. 1-4 bytes
can identify a charcter, but those bytres are
interpreted one at a time. While U-16 is a series of
2-byte characters (usually with a null as the sceond
byte), U-8 is readable as ANSI. There might be 3
bytes to signify a curly quote when read as U-8,
but those same 3 bytes also translate to 3 characters
in ANSI. That's why I don't see how it could be a
problem to read the string unless there are embedded
nulls. (Yes, I know VBS can deal with nulls, but as
you probably know, it takes some care to make it
work.)


| When you try to write a wide-character with a codepoint larger than 255 to
| an ASCII-style file it simply barfs (even though it has no problems with
| "wscript.echo"-ing the string!).
|
  Yes, but that's U-16. How are you getting U-16
responses? Maybe there's a setting wrong? If it's
U-8  then there's no codepoint "larger than 255".
There are only multi-byte characters. (See above.)

| And alas, the webpage thats retrieved seems to contain a few multi-byte
| characters *which get converted into wide-characters* and stored as such 
in
| the string ...
|
  This isn't making sense. By multibyte you seem
to mean U-16. You can't have a few U-16
characters. Either it's unicode or it's ANSI, as far
as VBS is concerned. If it's ANSI that might be
UTF-8, but it's still digestible as ANSI. It's still
a series of non-null bytes.

| And, as it turns out, applying "asc(  )" on a wide-character symbol does 
not
| return its codepoint, but it gets converted to ASCII first, and as such
| returns the default "cannot convert" replacement-characters value: 63 (the
| questionmark).
|

    AscW. Asc returns the first byte. (Unicode is
big-endian.) You can't mix and match in VBS. Either
you're working in unicode or you're working in ANSI.

[toc] | [prev] | [next] | [standalone]

#11642

Mayayana,

> What VBS is really dealing with is ANSI.

Really ?    Than how is it that every fucking string variant needs to have
its contents back-converted from WideChar to MultiByte (the next-best thing
to ASCII) whenever I need to use it myself ?

In other words: My experiences with the VBS engine (and COM/OCX/ActiveX
objects) are rather different.

>   Yes, but that's U-16. How are you getting U-16
> responses? Maybe there's a setting wrong?

I already told you what exactly I'm trying to write to the file. I'm not
going to repeat that at-nauseum.    As for settings ?   You tell me.  I'm
not aware of *any* settings in that regard.

> U-8  then there's no codepoint "larger than 255".
> There are only multi-byte characters. (See above.)

Than explain to me why the string does not want to get written to a simple
ASCII file.

As you might tell, I'm getting a bit tired from our fruitless to-and-fro.

I've mentioned (a few times now) why I think VBS refuses to write the
string, but you do not want to have that true.  But neither do you come with
any other explanation to why it could happen.

Furthermore, although I've mentioned several times that I've displayed all
characters outside the ASCII range and *still* are getting a questionmark
(ASCII code 63) there you've not even responded to that odity -- an oddity
which I've mentioned I find rather telling.

If you have nothing more to add than I think we should stop here.

I realize that you're trying to help, but you're not actually doing that.
Sorry.

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od7o5j$irp$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | And checking the 'Web just now (googeling "unicode vs wide-character"),
I
> | see I made a mistake: I've been referring to the way VBScript stores its
> | strings as being "unicode", when infact its using "wide character" (aka:
> all
> | chars are of the same size, in this case 16 bits).
> |
>    I think it's getting confused. VBS deals with ASCII
> or unicode-16, which is 2 bytes per character. What
> VBS is really dealing with is ANSI. 1 byte per
> character, with 128+ interpeted according to the
> local codepage. UTF-8 is unicode, but it's written
> as a kind of ANSI multi-byte encoding. 1-4 bytes
> can identify a charcter, but those bytres are
> interpreted one at a time. While U-16 is a series of
> 2-byte characters (usually with a null as the sceond
> byte), U-8 is readable as ANSI. There might be 3
> bytes to signify a curly quote when read as U-8,
> but those same 3 bytes also translate to 3 characters
> in ANSI. That's why I don't see how it could be a
> problem to read the string unless there are embedded
> nulls. (Yes, I know VBS can deal with nulls, but as
> you probably know, it takes some care to make it
> work.)
>
>
> | When you try to write a wide-character with a codepoint larger than 255
to
> | an ASCII-style file it simply barfs (even though it has no problems with
> | "wscript.echo"-ing the string!).
> |
>   Yes, but that's U-16. How are you getting U-16
> responses? Maybe there's a setting wrong? If it's
> U-8  then there's no codepoint "larger than 255".
> There are only multi-byte characters. (See above.)
>
> | And alas, the webpage thats retrieved seems to contain a few multi-byte
> | characters *which get converted into wide-characters* and stored as such
> in
> | the string ...
> |
>   This isn't making sense. By multibyte you seem
> to mean U-16. You can't have a few U-16
> characters. Either it's unicode or it's ANSI, as far
> as VBS is concerned. If it's ANSI that might be
> UTF-8, but it's still digestible as ANSI. It's still
> a series of non-null bytes.
>
> | And, as it turns out, applying "asc(  )" on a wide-character symbol does
> not
> | return its codepoint, but it gets converted to ASCII first, and as such
> | returns the default "cannot convert" replacement-characters value: 63
(the
> | questionmark).
> |
>
>     AscW. Asc returns the first byte. (Unicode is
> big-endian.) You can't mix and match in VBS. Either
> you're working in unicode or you're working in ANSI.

[toc] | [prev] | [next] | [standalone]

#11644

  We don't seem to be communicating. Maybe I'm
making wrong assumptions. You haven't posted
any code, so it's hard to know. My assumption is
that you're using FSO and CreateTextFile.

 The docs say ResponseText "tries to make a
unicode string out of what it gets and assumes
utf-8." That's ambiguous because unicode (wideChar)
is 2-byte characters while UTF-8 is a hack to fit
unicode into ANSI text. All non-wideChar is "multibyte"
(An unfortunate misnomer. It should be single-byte)
and differs only in the way it's interpreted. For instance:

E2 99 A5

In UTF-8 that's a heart. In English ANSI it's
â ™ Ą (a with caret, trademark, Yen symbol)
With a Russian codepage it might be 3 standard
Russian characters. However it's interpreted, it
works as ANSI because there are no nulls. It's
interpreted in terms of bytes rather than 2-byte
integers.

  So either you have UTF-16, which you'll need to
write as unicode and/or convert, or you have single
byte text that will write to disk as ANSI. (WSH says
ASCII, but it's not actually ASCII. It's 8-bit ANSI.)

  UTF-8 and UTF-16 are both unicode, but in entirely
different ways. I was figuring you must have one
or the other. If it's really UTF-8 then it will write (albeit
with corruption) as ANSI. If it's really UTF-16 then it
should write if you create the file as unicode. (That's
the option I was referring to. The third parameter of
CreateTextFile.) I was further assuming that you would
have tested those possibilities.

  If you then want to switch unicode to ANSI
you can use the script I linked:

'-- write unicode version to disk.
Set TS = FSO.CreateTextFile(sFilU, True, True)
   TS.Write s2
   TS.Close
 Set TS = Nothing

Set TS = FSO.OpenTextFile(sFilU, 1, False, -2)
Set TS2 = FSO.CreateTextFile(sFil, True, False)

   Do
       s3 = TS.ReadLine
       TS2.WriteLine s3
   Loop Until TS.AtEndOfStream

  TS.Close
  TS2.close
Set TS = Nothing
Set TS2 = Nothing
'--------------------------

  Or you can load it into an array and drop out
each second byte. 

[toc] | [prev] | [next] | [standalone]

#11645

Mayayana,

>   We don't seem to be communicating.

I thought we (somewhat) where, but we're again-and-again returning to the
"but it should be able to be written to an ANSI file" stance, when that is
exactly the problem I began with. :-(

> You haven't posted any code, so it's hard to know.
> My assumption is that you're using FSO and CreateTextFile.

Yes.  (but does that matter ?)

From the top of my initial post:

[quote]
I've retrieved a webpages content using the XMLHTTP object, and than
attempted to write the "responseText" result into a file.  Easy enough, just
use "<fileobject>.write <httpobject>.responseText"
[/quote]

I assumed that that was all that was needed to know which objects where
involved.

Later on I also (several times) mentioned (in response to the suggestion of
using other objects) that I'm on an older system, which rather limits the
available objects.

Also, a few post back I mentioned:
[quote]
But if its so simple, whats than wrong with using the
Scripting.FileSystemObject objects CreateTextFile ?
[/quote]

But, as everything in that direction has failed, here are the (six!)
relevant lines:

[code]
set oHttp = CreateObject("Microsoft.XMLHTTP")
  oHttp.open "GET", sURL, FALSE
 oHttp.send ""
Set oFile = oFS.CreateTextFile(sTrgFile,true)
   oFile.WriteLine oHttp.responseText
Set oFile=nothing
[/code]

As for your suggestion to use this:

> '-- write unicode version to disk.
> Set TS = FSO.CreateTextFile(sFilU, True, True)
>    TS.Write s2
>    TS.Close
>  Set TS = Nothing

Why would I want to do that ?   Only to read it back in as an ANSI string
and than work my way thru each of the byte-pairs ?

I thought I had made clear that I already could do that by walking over the
initial "responseText" variable -- and that I was looking  for something
that did not need that approach.

The only thing I bumped into there was that, when filtered out the ASCII
range and used I used "asc( )" on remaining "mid(str,pos,1)" result, I got a
mangled value back (always 63) instead of the codepoint.

And why I did not try to solve that mangeled value problem ?  Well, that I
explained at the bottom of my initial post:

[quote]
Bonus question (for when the first is impossible): How do I convert a
string  into one I can actually write to a file WITHOUT having to go thru
it byte-by-byte (copy the aceptable ones into a new string and write that
one) ?
[/quote]
(please do notice the word written in all capitals!)

By the way, the "mangled codepoint" problem turned out easy to solve -- if
you know what to look for: the whole "trick" is to use "ascW( )" instead of
just "asc( )".

So, I can (now) go-and-check for all characters in that wide-character
string, and "replace" them with whatever I want to use instead.  As long as
the replacements are ASCII/ANSI(?) ofcourse, otherwise the string will throw
the same error. :-)

BUT THATS NOT WHAT I WAS OUT FOR.

I simply wanted to 3) know why VBScript was not able to write a text it has
just read itself 2) if there was an internal method to convert the
unacceptable string to an acceptable one JUST LIKE WSCRIPT.ECHO SEEMS TO BE
ABLE TO DO*, or 1) how to tell VBScript to write the string exactly as it
read it thru the HTTPXML object (and which was delivered as UTF8
(multibyte) ).

... which I thought was all mentioned in my initial post ....

*and I did put that in full caps as I have not seen you respond to that in
any way ....

Instead I've been having a few rounds of sparring with you, as no matter
what I said you simply did not seem to understand most of what I said, no
matter how hard I tried.   Why ?   How ?   No idea.    Frustrating ?
Youbetya!  :-((

Regards,
Rudy Wieser

P.s.
If you want to replicate the error I started with, just try to write a
"chrw(-257)" to a ASCII/ANSI-mode file (notice the "w" between the "chr",
and the "(" ).


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od87r3$d2i$1@dont-email.me...
>   We don't seem to be communicating. Maybe I'm
> making wrong assumptions. You haven't posted
> any code, so it's hard to know. My assumption is
> that you're using FSO and CreateTextFile.
>
>  The docs say ResponseText "tries to make a
> unicode string out of what it gets and assumes
> utf-8." That's ambiguous because unicode (wideChar)
> is 2-byte characters while UTF-8 is a hack to fit
> unicode into ANSI text. All non-wideChar is "multibyte"
> (An unfortunate misnomer. It should be single-byte)
> and differs only in the way it's interpreted. For instance:
>
> E2 99 A5
>
> In UTF-8 that's a heart. In English ANSI it's
> ā T „ (a with caret, trademark, Yen symbol)
> With a Russian codepage it might be 3 standard
> Russian characters. However it's interpreted, it
> works as ANSI because there are no nulls. It's
> interpreted in terms of bytes rather than 2-byte
> integers.
>
>   So either you have UTF-16, which you'll need to
> write as unicode and/or convert, or you have single
> byte text that will write to disk as ANSI. (WSH says
> ASCII, but it's not actually ASCII. It's 8-bit ANSI.)
>
>   UTF-8 and UTF-16 are both unicode, but in entirely
> different ways. I was figuring you must have one
> or the other. If it's really UTF-8 then it will write (albeit
> with corruption) as ANSI. If it's really UTF-16 then it
> should write if you create the file as unicode. (That's
> the option I was referring to. The third parameter of
> CreateTextFile.) I was further assuming that you would
> have tested those possibilities.
>
>   If you then want to switch unicode to ANSI
> you can use the script I linked:
>
> '-- write unicode version to disk.
> Set TS = FSO.CreateTextFile(sFilU, True, True)
>    TS.Write s2
>    TS.Close
>  Set TS = Nothing
>
> Set TS = FSO.OpenTextFile(sFilU, 1, False, -2)
> Set TS2 = FSO.CreateTextFile(sFil, True, False)
>
>    Do
>        s3 = TS.ReadLine
>        TS2.WriteLine s3
>    Loop Until TS.AtEndOfStream
>
>   TS.Close
>   TS2.close
> Set TS = Nothing
> Set TS2 = Nothing
> '--------------------------
>
>   Or you can load it into an array and drop out
> each second byte.
>
>

[toc] | [prev] | [next] | [standalone]

#11646

"R.Wieser" <address@not.available> wrote

| If you want to replicate the error I started with, just try to write a
| "chrw(-257)" to a ASCII/ANSI-mode file (notice the "w" between the "chr",
| and the "(" ).
|

  I assume you mean ChrW(257), since -257 is
meaningless. It writes to disk just fine if written
as unicode, with CreateTextFile(path, True, True)

| I thought I had made clear that I already could do that by walking over 
the
| initial "responseText" variable -- and that I was looking  for something
| that did not need that approach.

   So this whole tantrum has been about your simply
refusing to accept that you can't write unicode to
disk as ANSI? I know you like to suffer in order to
cultivate irritation, but you could, maybe, find a
more productive issue. Why not tear your hair out
about something worth doing? :)

 Good luck. Hopefully this discussion of character
encoding will be of at least some use to someone. 

[toc] | [prev] | [next] | [standalone]

#11647

Hi Mayayana,

Am 20.04.2017 um 19:24 schrieb Mayayana:
> "R.Wieser"<address@not.available>  wrote
>
> | If you want to replicate the error I started with, just try to write a
> | "chrw(-257)" to a ASCII/ANSI-mode file (notice the "w" between the "chr",
> | and the "(" ).
> |
>
>    I assume you mean ChrW(257), since -257 is
> meaningless. It writes to disk just fine if written
> as unicode, with CreateTextFile(path, True, True)

ChrW(-257) is not meaningless! It is unicode u+FEFF which may be used 
for detecting the current byte order.

see http://www.fileformat.info/info/unicode/char/FEFF/index.htm

Ulrich

[toc] | [prev] | [next] | [standalone]

#11648

"Ulrich Möller" <knobbi38@arcor.de> wrote


| ChrW(-257) is not meaningless! It is unicode u+FEFF which may be used
| for detecting the current byte order.
|
| see http://www.fileformat.info/info/unicode/char/FEFF/index.htm
|

  FEFF is decimal 65279. Unicode numbers are not
signed. -257 is FFFFFEFF, outside the unicode range.
But what does it matter? Even if it were FEFF, why
would one write that to disk in order to test a
unicode write?

   I'd assumed he was just trying to write something
above 255, to see if it works. And it works fine, as
long as one writes the file as unicode. He seemed to imply
that it causes some kind of error. Writing ChrW(257)
writes FF FE 01 01 as expected and gives me an "a"
with a line over it. Writing -257 gives me a file with
bytes FF FE FF FE. I'm guessing that may be the result
of trying to write an invalid character. The file just
ends up blank with two unicode markers. But I
don't know... And who cares? 

[toc] | [prev] | [next] | [standalone]

#11650

Mayayana,

>   FEFF is decimal 65279.

Now try to subtract 65536 from that last number.  What do you get ?
Coincidence ?  I think not. :-)

> Unicode numbers are not signed

Nope, they are not.   But how does that matter ?   Also, you obviously have
no problem with translating from a decimal representation to a hexadecimal
one, but are incapable of converting an unsigned numbers representation (of
a specific bitcount !) to its signed counterpart ?  Really ?

> -257 is FFFFFEFF

Why are you suddenly converting to a 32-bit representation ?

Try converting to a 16-bit representation -- after all, we where talking
about WideChars, which are just 16 bits -- and compare the result to the
very first hexadecimal value in your post.   Coincidence ?    Again, I think
not.

And by it you have proven for yourself that -256, FEFF and 65279 are just
*representations* of the same 16-bit value (that doesn't even exists/isn't
stored in either of those forms!)

God man, this is basic knowledge.  What have you been doing all this time ?

> Writing -257 gives me a file with bytes FF FE FF FE.

So a negative value *does* work.  Thanks for confirming that I guess. :-)

My file ends up containing FE FF 63 FF

(funny that 63.  I could swear that I've seen it before .. :-) )

> I'm guessing that may be the result of trying to write an
> invalid character.

And there it ends for you ?  No urge to see what you would get when you
write another char ?   I could not stop myself from placing a couple of
chrw(1)-s  around the chrw(-257), wrote the 3-char string and took a peek at
the result.    It was rather educational.

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
odbntf$r7o$1@dont-email.me...
> "Ulrich Möller" <knobbi38@arcor.de> wrote
>
>
> | ChrW(-257) is not meaningless! It is unicode u+FEFF which may be used
> | for detecting the current byte order.
> |
> | see http://www.fileformat.info/info/unicode/char/FEFF/index.htm
> |
>
>   FEFF is decimal 65279. Unicode numbers are not
> signed. -257 is FFFFFEFF, outside the unicode range.
> But what does it matter? Even if it were FEFF, why
> would one write that to disk in order to test a
> unicode write?
>
>    I'd assumed he was just trying to write something
> above 255, to see if it works. And it works fine, as
> long as one writes the file as unicode. He seemed to imply
> that it causes some kind of error. Writing ChrW(257)
> writes FF FE 01 01 as expected and gives me an "a"
> with a line over it. Writing -257 gives me a file with
> bytes FF FE FF FE. I'm guessing that may be the result
> of trying to write an invalid character. The file just
> ends up blank with two unicode markers. But I
> don't know... And who cares?

[toc] | [prev] | [next] | [standalone]

#11649

Mayayana,

>   I assume you mean ChrW(257), since -257 is
> meaningless.

And I guess you did not (bother) to try :-(((

Also, -257 is simpy a signed-value-only systems way of displaying of a very
high unsigned value.  Didn't you know that ?

>    So this whole tantrum has been about your simply
> refusing to accept that you can't write unicode to
> disk as ANSI?

No.   As I've tried to tell you several times now, its about a system which
can read UTF8 encoded strings, but than is incapable of writing the data to
disk in the same format as it read it (what the f*ck ?).

And again here we are: Me trying to explain either very basic stuff that
should be rather known (signed versus unsigned values, and how they in their
internal representation fully overlap) and repeating explanations which I
have not had _any_ feedback to that you even read them, let alone understood
them.

Did I already say that that is frustrating ?  Talking to an intelligent
being while not being able to reach him ?   It is.  *Very* frustrating.

> I know you like to suffer in order to cultivate irritation, but you
> could, maybe, find a more productive issue.

If your stance is _not_ to try to figure out if something that, logically
speaking, should be there*, but just go for a convoluted** work-around
instead than I would not want to see you writing commercial software. :-(

*and that is actually all I was out for: did I overlook / was I unaware of a
method or setting which would allow me to write the string as it was read.

**and pardon me, but you both ignored that I _didn't want_ to go the
convoluted way, _and_ you tried to make it even more, and rather
unnecessarily as it turns out, convoluted. :-(

So, here we are.   At the end of another fruitless bout of wasting our time
...  And I even had my hopes up that this time it would work.

>  Good luck.

Thanks, but I would rather speak with someone who knows something about
VBScripts objects (below the level of just stringing commands together). :-)


Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
odaqng$5kq$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | If you want to replicate the error I started with, just try to write a
> | "chrw(-257)" to a ASCII/ANSI-mode file (notice the "w" between the
"chr",
> | and the "(" ).
>
>   I assume you mean ChrW(257), since -257 is
> meaningless. It writes to disk just fine if written
> as unicode, with CreateTextFile(path, True, True)
>
> | I thought I had made clear that I already could do that by walking over
> the
> | initial "responseText" variable -- and that I was looking  for something
> | that did not need that approach.
>
>    So this whole tantrum has been about your simply
> refusing to accept that you can't write unicode to
> disk as ANSI? I know you like to suffer in order to
> cultivate irritation, but you could, maybe, find a
> more productive issue. Why not tear your hair out
> about something worth doing? :)
>
>  Good luck. Hopefully this discussion of character
> encoding will be of at least some use to someone.

[toc] | [prev] | [next] | [standalone]

#11625

"R.Wieser" <address@not.available> wrote

| I've retrieved a webpages content using the XMLHTTP object, and than
| attempted to write the "responseText" result into a file.

  Out of curiosity.... Have you used WinHttpRequest?
I've never used xmlhttp and don't know anything about it.
Since it seems to be part of IE I don't think I'd want
to use it.
 In the past I've avoided API functions like UrlDownloadToFile
that are really just IE calls. It seems very sloppy to me,
writing software that leaves records in IE history and cache,
and may be affected by IE settings.
  So some years ago I wrote winsock code for Interet functions.
But awhile back someone pointed me to WinHttpRequest.
It turns out to be a clean, simple way to make server requests,
without the sloppy IE tie-in. Some of the methods use strings
rather than variants, but it seems to work fine with VBScript.
(I've only used it in VB6, but I've seen VBS code.) 

[toc] | [prev] | [next] | [standalone]

#11627

Mayayana,

>   Out of curiosity.... Have you used WinHttpRequest?

Nope.   I have also tried to use it, but it doesn't exist on the machine I'm
scripting on (its rather old).

> I've never used xmlhttp and don't know anything about it.
> Since it seems to be part of IE I don't think I'd want
> to use it.

And you think WinHttpRequest *isn't* part of IE ?   I would not bet on that
if I where you. :-)   IE is just a rather thin shell over a lot of
components that are an integral part of Windows.

> In the past I've avoided API functions like UrlDownloadToFile
> that are really just IE calls

I think you would make a rather safe assumption in that both XMLHTTP as well
as WinHttpRequest use its direct sibbling (downloading the data to memory),
just with a bit different packaging.

>   So some years ago I wrote winsock code for Interet functions

Yup, same here.   But I wanted to see if I could get something to work by
using run-of-the-mill stuff, instead of trying to build/fix everything
myself.    Alas, VBScript still has the "everything *must* be Unicode"
blight of yesteryear, and that doesn't make it easier.

Heck, currently my whole problem is caused by VBScript converting MultiByte
data into its internal Unicode representation, and than not being able to
convert it back to MultiByte again ...  :-(

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od55s9$va7$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | I've retrieved a webpages content using the XMLHTTP object, and than
> | attempted to write the "responseText" result into a file.
>
>   Out of curiosity.... Have you used WinHttpRequest?
> I've never used xmlhttp and don't know anything about it.
> Since it seems to be part of IE I don't think I'd want
> to use it.
>  In the past I've avoided API functions like UrlDownloadToFile
> that are really just IE calls. It seems very sloppy to me,
> writing software that leaves records in IE history and cache,
> and may be affected by IE settings.
>   So some years ago I wrote winsock code for Interet functions.
> But awhile back someone pointed me to WinHttpRequest.
> It turns out to be a clean, simple way to make server requests,
> without the sloppy IE tie-in. Some of the methods use strings
> rather than variants, but it seems to work fine with VBScript.
> (I've only used it in VB6, but I've seen VBS code.)
>
>

[toc] | [prev] | [next] | [standalone]

#11631

"R.Wieser" <address@not.available> wrote

| Nope.   I have also tried to use it, but it doesn't exist on the machine 
I'm
| scripting on (its rather old).
|
Yes. XP+.

| And you think WinHttpRequest *isn't* part of IE ?

Yes. I checked it out.

[toc] | [prev] | [next] | [standalone]

#11632

Mayayana,

> | And you think WinHttpRequest *isn't* part of IE ?
>
> Yes. I checked it out.

If you mean that (you read that) it isn't a part of the wrapper that
combines all kinds of OS build-in stuff to be able to show you "IE, the
browser", than you're (probably) right.

If you mean that its isn't part of "the neccesary IE parts inside the OS
that *cannot* be removed, otherwise the OS will not be able to perfor all
its tasks" (the words of the thanwhile head-honcho of MS, not mine), than
you are mistaken.

Yes, MS was forced to remove the *browser* from certain versions of its OS
(can't exactly remember which ones).   That didn't mean that MS wanted, nor
could remove all the IE related crap outof the OS (the "can't do it" was in
that time the center of many a "are they pulling us a fast one?"
conversation).

For example, did you know that you can search the web by entering a series
of words into the *file*browser (windows explorer) addresbar that do not
resemble an existing path or file ?   Annoys me to not end (apart from being
a security leak issue) ...

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od5llp$o7p$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | Nope.   I have also tried to use it, but it doesn't exist on the machine
> I'm
> | scripting on (its rather old).
> |
> Yes. XP+.
>
> | And you think WinHttpRequest *isn't* part of IE ?
>
> Yes. I checked it out.
>
>

[toc] | [prev] | [next] | [standalone]

#11633

"R.Wieser" <address@not.available> wrote

| > | And you think WinHttpRequest *isn't* part of IE ?
| >
| > Yes. I checked it out.
|
| If you mean that (you read that) it isn't a part of the wrapper that
| combines all kinds of OS build-in stuff to be able to show you "IE, the
| browser", than you're (probably) right.
|
| If you mean that its isn't part of "the neccesary IE parts inside the OS
| that *cannot* be removed, otherwise the OS will not be able to perfor all
| its tasks" (the words of the thanwhile head-honcho of MS, not mine), than
| you are mistaken.

    I mean it's not connected to IE. The IE operations
are connected with wininet.dll and urlmon.dll. Winhttp
uses neither. If you check Depends you'll see it uses
a few string parsing functions from shlwapi.dll, but aside
from that it's all basic system stuff. And it doesn't add
to cache or history. You can check it out for yourself.

   It may be they released it to provide a basic file
download component that would be clean. I don't
know. But after checking it out I decided to start
using to instead of my winsock code.

  But it does require WinXP+. 

[toc] | [prev] | [next] | [standalone]

#11635

Mayayana,

>     I mean it's not connected to IE.

Look at it from the other direction:  IE is (heavily) dependant on a number
of OS-provided items.   Items that are also used by the OS itself.

> If you check Depends you'll see it uses a few string parsing
> functions from shlwapi.dll, but aside from that it's all basic
> system stuff

You're joking, right ?    If that is *all* it uses it *cannot* make a
network connection *ever*.    But as it does ...

> You can check it out for yourself.

Thanks.  I just did.  Alas, working thru the whole program figuring out what
it does and how it connects to the 'web would take me quite a bit more time
(if I ever can get thru all of it).

Granted, on first sight it doesn't look as if its directly handing off its
work to either of those two DLLs you mentioned.

>   But it does require WinXP+.

Yep, that would be a problem ...

Regards,
Rudy Wieser


-- Origional message:
Mayayana <mayayana@invalid.nospam> schreef in berichtnieuws
od63tj$bo8$1@dont-email.me...
> "R.Wieser" <address@not.available> wrote
>
> | > | And you think WinHttpRequest *isn't* part of IE ?
> | >
> | > Yes. I checked it out.
> |
> | If you mean that (you read that) it isn't a part of the wrapper that
> | combines all kinds of OS build-in stuff to be able to show you "IE, the
> | browser", than you're (probably) right.
> |
> | If you mean that its isn't part of "the neccesary IE parts inside the OS
> | that *cannot* be removed, otherwise the OS will not be able to perfor
all
> | its tasks" (the words of the thanwhile head-honcho of MS, not mine),
than
> | you are mistaken.
>
>     I mean it's not connected to IE. The IE operations
> are connected with wininet.dll and urlmon.dll. Winhttp
> uses neither. If you check Depends you'll see it uses
> a few string parsing functions from shlwapi.dll, but aside
> from that it's all basic system stuff. And it doesn't add
> to cache or history. You can check it out for yourself.
>
>    It may be they released it to provide a basic file
> download component that would be clean. I don't
> know. But after checking it out I decided to start
> using to instead of my winsock code.
>
>   But it does require WinXP+.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | microsoft.public.scripting.vbscript

csiph-web