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


Groups > microsoft.public.scripting.vbscript > #12116

Re: Textstream Write

From "Mayayana" <mayayana@invalid.nospam>
Newsgroups microsoft.public.scripting.vbscript
Subject Re: Textstream Write
Date 2019-05-01 08:37 -0400
Organization A noiseless patient Spider
Message-ID <qac42q$ppk$1@dont-email.me> (permalink)
References (2 earlier) <qa9snk$1rhs$1@gioia.aioe.org> <qa9v5s$vuj$1@dont-email.me> <qaa856$1hhs$1@gioia.aioe.org> <qaadfo$t2d$1@dont-email.me> <qabjo3$1clv$1@gioia.aioe.org>

Show all headers | View raw


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

| Suggestion: Check what the output of that CStr is in every loop-step 
there.
| Provide it the problem char plus a few before and after and see what the
| "s2" strings becomes.
|
| You might well see that the "s2" builds normally upto the problem char, 
and
| than disappears altogether

  I suspect you're right. But I've got a solution now. I
just remove any HTML entities over 255.

| But in that case, why don't you try to WriteFile that converted string
| /before/ you give it to IE ?

   I can't do that because the whole thing is based on
giving it to IE. I load the body of a webpage file into a
DIV in my HTA. The rest of the HTA is a WYSIWYG editor.
When editing is done I take the innerHTML of the DIV
and recreate the input file with edits. For instance, I
might add a line return or remove a word, using the mouse
and keyboard directly in the IE browser window. The only
way to be able to do that is through IE's DOM. Of course I
could edit the HTML directly, but this is much more functional.

  This all started when I found pdftohtml.exe in the
"poppler" package and tried it for converting PDF to
HTML. It does a very good job, compared to other
options, but it makes a mess of the result, filling it
with &nbsp; unnecessarily, running headers together
with text, corrupting links, and making occasional
mistakes typical of PDF conversion, like converting
"ol" to "d". I coupled pdftohtml with my own script
to clean up the result, but that can't fix every detail.
So I wanted a tool that would allow me to do touch-ups
on the finished product.

| > That one 9660 seems to infect the whole thing.
|
| Or any of the gazillion other multi-byte characters.    Like forward and
| backward single and double quotes, dashes of different lengths, a triplet 
of
| dots, etc.
|
  No. You seem to be missing what I've been saying. IE
is turning &#9660; into something else. Unicode? I'm not
sure. Multi-byte UTF-8 is not a problem, because the unit
is still a byte. That's what I started out saying. If it were
actually coming through as bytes 25 BC that would be no
problem. They'd be written to disk and render as % and
1/4 sign. The file has other multi-byte characters and
has no trouble with them. UTF-8 is functional as ANSI.
In fact, part of my converter script involves a filter to
convert common UTF-8, like curly quotes, to ASCII, since
almost all UTF-8 webpages in English are unnecessary.

  It might be that I could convert to unicode, then convert
that back to ANSI. But none of that is necessary. I'm just
removing any &#[255+]; altogether. No big loss. But it's
a weird bug. I probably never would have found it by myself.

  You can try what I'm talking about. Give any HTML file to
IE with an HTML entity over 255. Like &#9660; You'll get
the corruption when it comes back. What IE returns is not
25 BC. Nor is it the entity byte. (38 for &. 35 for #. Etc.)
It's something else.
   But you can use any number of bytes over 127 and
there will be no problem. You can send it dozens of &#149;
and it won't choke. The problem is not high bytes but
rather what IE is doing, converting one HTML entity to unicode,
or perhaps even something more creative. The Microsofties
could have designed it for adaptable complexity internally.

  Interestingly, though, if you send in "&#149;" IE gives you
back byte 149, which won't render at all if it's being read as
UTF-8, but will show as a bullet in ANSI English. In other words,
IE is actually converting the HTML entity rather than just
rendering it.


Back to microsoft.public.scripting.vbscript | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-04-29 08:55 -0400
  Re: Textstream Write JJ <jj4public@vfemail.net> - 2019-04-30 17:45 +0700
    Re: Textstream Write "R.Wieser" <address@not.available> - 2019-04-30 13:21 +0200
  Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-04-30 08:51 -0400
    Re: Textstream Write "R.Wieser" <address@not.available> - 2019-04-30 18:22 +0200
      Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-04-30 13:01 -0400
        Re: Textstream Write "R.Wieser" <address@not.available> - 2019-04-30 21:37 +0200
          Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-04-30 17:06 -0400
            Re: Textstream Write "R.Wieser" <address@not.available> - 2019-05-01 10:01 +0200
              Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-05-01 08:37 -0400
                Re: Textstream Write "R.Wieser" <address@not.available> - 2019-05-01 16:00 +0200
                Re: Textstream Write "R.Wieser" <address@not.available> - 2019-05-01 16:12 +0200
                Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-05-01 10:47 -0400
                Re: Textstream Write "R.Wieser" <address@not.available> - 2019-05-01 19:09 +0200
  Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-05-04 15:26 -0400
    Re: Textstream Write JJ <jj4public@vfemail.net> - 2019-05-05 20:15 +0700
      Re: Textstream Write "Mayayana" <mayayana@invalid.nospam> - 2019-05-05 10:19 -0400

csiph-web