Groups > comp.lang.php > #12731 > unrolled thread

Writing double-prime to file?

Started by	adrian@poppyrecords.invalid.invalid (Adrian Tuddenham)
First post	2014-02-01 11:37 +0000
Last post	2014-02-01 17:03 +0100
Articles	15 — 6 participants

Back to article view | Back to comp.lang.php

  Writing double-prime to file? adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-01 11:37 +0000
    Re: Writing double-prime to file? Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-01 07:40 -0500
      Re: Writing double-prime to file? adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-01 14:23 +0000
        Re: Writing double-prime to file? Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-01 10:11 -0500
          Re: Writing double-prime to file? adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-01 16:38 +0000
            Re: Writing double-prime to file? Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-02-01 16:46 +0000
            Re: Writing double-prime to file? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 18:07 +0100
              Re: Writing double-prime to file? adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-01 18:00 +0000
                Re: Writing double-prime to file? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 20:07 +0100
                Re: Writing double-prime to file? Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-01 19:26 +0000
                  Re: Writing double-prime to file? Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-01 19:29 +0000
                    Re: Writing double-prime to file? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-02 21:55 +0100
                  Re: Writing double-prime to file? adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-02 18:33 +0000
            Re: Writing double-prime to file? Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-01 19:18 +0000
    Re: Writing double-prime to file? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-01 17:03 +0100

#12731 — Writing double-prime to file?

From	adrian@poppyrecords.invalid.invalid (Adrian Tuddenham)
Date	2014-02-01 11:37 +0000
Subject	Writing double-prime to file?
Message-ID	<1lgdznh.qokhorr0y73aN%adrian@poppyrecords.invalid.invalid>

I am trying to write a series of programs which create a file from a
string which has been Copied from a spreadsheet.  It is Pasted into an
HTML Form and passed through various checking routines.  Finally it is
written to a file.

If the string contains a double-prime character (double quotes) the
character and the rest of the string after that point do not appear to
be written to file.

The program displays the string just after the "write to file"  lines
and it is still unchanged.  Either a problem is occurring during the
writing phase or that character is making the rest of the file
unreadable.  (I view the file contents in Fetch v3.0.3)

The data string is held in the variiable '$txt' and the write command
is:

~~~~~~~~
$fh = fopen($fileURL, 'w') or die("<FONT
COLOR=\"#CCFFFF\"><B>PayFileGen2 can't open file $fileURL</B></FONT>");
        fwrite($fh, $txt);
fclose($fh);

~~~~~~~~

Is that character known to cause a problem and is there a
straightforward way around this?


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [next] | [standalone]

#12732

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2014-02-01 07:40 -0500
Message-ID	<lciq0a$p28$1@dont-email.me>
In reply to	#12731

On 2/1/2014 6:37 AM, Adrian Tuddenham wrote:
> I am trying to write a series of programs which create a file from a
> string which has been Copied from a spreadsheet.  It is Pasted into an
> HTML Form and passed through various checking routines.  Finally it is
> written to a file.
>
> If the string contains a double-prime character (double quotes) the
> character and the rest of the string after that point do not appear to
> be written to file.
>
> The program displays the string just after the "write to file"  lines
> and it is still unchanged.  Either a problem is occurring during the
> writing phase or that character is making the rest of the file
> unreadable.  (I view the file contents in Fetch v3.0.3)
>
> The data string is held in the variiable '$txt' and the write command
> is:
>
> ~~~~~~~~
> $fh = fopen($fileURL, 'w') or die("<FONT
> COLOR=\"#CCFFFF\"><B>PayFileGen2 can't open file $fileURL</B></FONT>");
>          fwrite($fh, $txt);
> fclose($fh);
>
> ~~~~~~~~
>
> Is that character known to cause a problem and is there a
> straightforward way around this?
>
>

I've never seen a problem writing double quotes to a file.  What does 
the file look like if you open it with an editor on the server (or, more 
simply, just list it to the terminal) instead of retrieving it with an 
ftp program?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#12733

From	adrian@poppyrecords.invalid.invalid (Adrian Tuddenham)
Date	2014-02-01 14:23 +0000
Message-ID	<1lge6zm.any5jv11w4szkN%adrian@poppyrecords.invalid.invalid>
In reply to	#12732

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/1/2014 6:37 AM, Adrian Tuddenham wrote:
> > I am trying to write a series of programs which create a file from a
> > string which has been Copied from a spreadsheet.  It is Pasted into an
> > HTML Form and passed through various checking routines.  Finally it is
> > written to a file.
> >
> > If the string contains a double-prime character (double quotes) the
> > character and the rest of the string after that point do not appear to
> > be written to file.
> >
> > The program displays the string just after the "write to file"  lines
> > and it is still unchanged.  Either a problem is occurring during the
> > writing phase or that character is making the rest of the file
> > unreadable.  (I view the file contents in Fetch v3.0.3)
> >
> > The data string is held in the variiable '$txt' and the write command
> > is:
> >
> > ~~~~~~~~
> > $fh = fopen($fileURL, 'w') or die("<FONT
> > COLOR=\"#CCFFFF\"><B>PayFileGen2 can't open file $fileURL</B></FONT>");
> >          fwrite($fh, $txt);
> > fclose($fh);
> >
> > ~~~~~~~~
> >
> > Is that character known to cause a problem and is there a
> > straightforward way around this?
> >
> >
> 
> I've never seen a problem writing double quotes to a file.  What does
> the file look like if you open it with an editor on the server (or, more
> simply, just list it to the terminal) instead of retrieving it with an
> ftp program?

I am just a beginner, so 'listing to the termiinal' is something I
haven't come across.  I didn't FTP the file to view it, but used the
"View file" facility in Fetch (I don't know if that would make any
difference to what I would see).  If you want to see it, the file is at:
http://www.poppyrecords.co.uk/Payment/phpfiles/IYC519N1391274673.txt

I have written a bit of code to read the file, print it and then and
list each character with its ASCII equivlent.   The original data was:

~~~~~~~~~ Original Data ~~~~~~
419     IYC519  140201                          169.75          XXX111
Bill    Smith   123, Any Street Some Town       Elsewhere       County
XX1 @AB 01234 567890    bill.smith@url.com
0       Copy tape (0.25" @ 1-7/8ips) to CDR                     0
Special treatment                       0       Hours work      4
15      60      P+P     1       3       3       Transfer 8 double-sided
discs to CDR                    0       Hours work      6.5     15
97.5    P+P CDR 1       1       1       P+P Special Delivery    1
8.25    8.25                            0

~~~~~~~ End of original data ~~~~~~ 


The results from the reading program are:

~~~~~~~~ Reading program results ~~~~~~
419     IYC519  140201                          169.75          XXX111
Bill    Smith   123, Any Street Some Town       Elsewhere       County
XX1 @AB 01234 567890    bill.smith@url.com
0       Copy tape (0.25 
 
0    4 = 52 
        1    1 = 49 
        2    9 = 57 
        3        = 9 
        4    I = 73 
        5    Y = 89 
        6    C = 67 
        7    5 = 53 
        8    1 = 49 
        9    9 = 57 
        10       = 9 
        11    1 = 49 
        12    4 = 52 
        13    0 = 48 
        14    2 = 50 
        15    0 = 48 
        16    1 = 49 
        17       = 9 
        18       = 9 
        19       = 9 
        20       = 9 
        21    1 = 49 
        22    6 = 54 
        23    9 = 57 
        24    . = 46 
        25    7 = 55 
        26    5 = 53 
        27       = 9 
        28       = 9 
        29    X = 88 
        30    X = 88 
        31    X = 88 
        32    1 = 49 
        33    1 = 49 
        34    1 = 49 
        35       = 9 
        36    B = 66 
        37    i = 105 
        38    l = 108 
        39    l = 108 
        40       = 9 
        41    S = 83 
        42    m = 109 
        43    i = 105 
        44    t = 116 
        45    h = 104 
        46       = 9 
        47    1 = 49 
        48    2 = 50 
        49    3 = 51 
        50    , = 44 
        51      = 32 
        52    A = 65 
        53    n = 110 
        54    y = 121 
        55      = 32 
        56    S = 83 
        57    t = 116 
        58    r = 114 
        59    e = 101 
        60    e = 101 
        61    t = 116 
        62       = 9 
        63    S = 83 
        64    o = 111 
        65    m = 109 
        66    e = 101 
        67      = 32 
        68    T = 84 
        69    o = 111 
        70    w = 119 
        71    n = 110 
        72       = 9 
        73    E = 69 
        74    l = 108 
        75    s = 115 
        76    e = 101 
        77    w = 119 
        78    h = 104 
        79    e = 101 
        80    r = 114 
        81    e = 101 
        82       = 9 
        83    C = 67 
        84    o = 111 
        85    u = 117 
        86    n = 110 
        87    t = 116 
        88    y = 121 
        89       = 9 
        90    X = 88 
        91    X = 88 
        92    1 = 49 
        93      = 32 
        94    @ = 64 
        95    A = 65 
        96    B = 66 
        97       = 9 
        98    0 = 48 
        99    1 = 49 
        100    2 = 50 
        101    3 = 51 
        102    4 = 52 
        103      = 32 
        104    5 = 53 
        105    6 = 54 
        106    7 = 55 
        107    8 = 56 
        108    9 = 57 
        109    0 = 48 
        110      = 9 
        111    b = 98 
        112    i = 105 
        113    l = 108 
        114    l = 108 
        115    . = 46 
        116    s = 115 
        117    m = 109 
        118    i = 105 
        119    t = 116 
        120    h = 104 
        121    @ = 64 
        122    u = 117 
        123    r = 114 
        124    l = 108 
        125    . = 46 
        126    c = 99 
        127    o = 111 
        128    m = 109 
        129      = 9 
        130      = 9 
        131      = 9 
        132      = 9 
        133    0 = 48 
        134      = 9 
        135    C = 67 
        136    o = 111 
        137    p = 112 
        138    y = 121 
        139      = 32 
        140    t = 116 
        141    a = 97 
        142    p = 112 
        143    e = 101 
        144      = 32 
        145    ( = 40 
        146    0 = 48 
        147    . = 46 
        148    2 = 50 
        149    5 = 53 
        150     = 0 
        151     = 0 
        152     = 0 
        153     = 0 
        154     = 0 
        155     = 0 
        156     = 0 
        157     = 0 
        158     = 0 
        159     = 0 
        160     = 0 
        161     = 0 
        162     = 0 
        163     = 0 
        164     = 0 
        165     = 0 
        166     = 0 
        167     = 0 
        168     = 0 
        169     = 0 
        170     = 0 
        171     = 0 
        172     = 0 
        173     = 0 
        174     = 0 
        175     = 0 
        176     = 0 
        177     = 0 
        178     = 0 
        179     = 0 
        180     = 0 
        181     = 0 
        182     = 0 
        183     = 0 
        184     = 0 
        185     = 0 
        186     = 0 
        187     = 0 
        188     = 0 
        189     = 0 
        190     = 0 
        191     = 0 
        192     = 0 
        193     = 0 
        194     = 0 
        195     = 0 
        196     = 0 
        197     = 0 
        198     = 0 
        199     = 0 

~~~~~~~ end of reading program results ~~~~~~~~


The reading program was:

~~~~~~~ Reading program ~~~~~~~~~
<?php
                                

## GET file URL from link and read data from file ###
                                
$fileURL =  $_GET['iyc'];

$fileURL = ($_SERVER['DOCUMENT_ROOT'] . "/Payment/phpfiles/") .
$fileURL;
$fh = fopen($fileURL, 'r') or die("<FONT COLOR=\"#CCFFFF\"><B>invoicer3
can't open file $fileURL</B></FONT>");
        $txt = fread($fh, filesize($fileURL));
fclose($fh);

print $txt;
print "

";

$i=0;

while ($i<200)
        {
        print $i . "    ";
        print ($txt{$i}) . " = ";
        print (ord($txt{$i}));
        print "
        ";
        $i++;
        }


?>

~~~~~ end of reading program ~~~~~
        


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12734

From	Jerry Stuckle <jstucklex@attglobal.net>
Date	2014-02-01 10:11 -0500
Message-ID	<lcj2ql$8mo$1@dont-email.me>
In reply to	#12733

On 2/1/2014 9:23 AM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/1/2014 6:37 AM, Adrian Tuddenham wrote:
>>> I am trying to write a series of programs which create a file from a
>>> string which has been Copied from a spreadsheet.  It is Pasted into an
>>> HTML Form and passed through various checking routines.  Finally it is
>>> written to a file.
>>>
>>> If the string contains a double-prime character (double quotes) the
>>> character and the rest of the string after that point do not appear to
>>> be written to file.
>>>
>>> The program displays the string just after the "write to file"  lines
>>> and it is still unchanged.  Either a problem is occurring during the
>>> writing phase or that character is making the rest of the file
>>> unreadable.  (I view the file contents in Fetch v3.0.3)
>>>
>>> The data string is held in the variiable '$txt' and the write command
>>> is:
>>>
>>> ~~~~~~~~
>>> $fh = fopen($fileURL, 'w') or die("<FONT
>>> COLOR=\"#CCFFFF\"><B>PayFileGen2 can't open file $fileURL</B></FONT>");
>>>           fwrite($fh, $txt);
>>> fclose($fh);
>>>
>>> ~~~~~~~~
>>>
>>> Is that character known to cause a problem and is there a
>>> straightforward way around this?
>>>
>>>
>>
>> I've never seen a problem writing double quotes to a file.  What does
>> the file look like if you open it with an editor on the server (or, more
>> simply, just list it to the terminal) instead of retrieving it with an
>> ftp program?
>
> I am just a beginner, so 'listing to the termiinal' is something I
> haven't come across.  I didn't FTP the file to view it, but used the
> "View file" facility in Fetch (I don't know if that would make any
> difference to what I would see).  If you want to see it, the file is at:
> http://www.poppyrecords.co.uk/Payment/phpfiles/IYC519N1391274673.txt
>
> I have written a bit of code to read the file, print it and then and
> list each character with its ASCII equivlent.   The original data was:
>
> ~~~~~~~~~ Original Data ~~~~~~
> 419     IYC519  140201                          169.75          XXX111
> Bill    Smith   123, Any Street Some Town       Elsewhere       County
> XX1 @AB 01234 567890    bill.smith@url.com
> 0       Copy tape (0.25" @ 1-7/8ips) to CDR                     0
> Special treatment                       0       Hours work      4
> 15      60      P+P     1       3       3       Transfer 8 double-sided
> discs to CDR                    0       Hours work      6.5     15
> 97.5    P+P CDR 1       1       1       P+P Special Delivery    1
> 8.25    8.25                            0
>
> ~~~~~~~ End of original data ~~~~~~
>
>
> The results from the reading program are:
>
> ~~~~~~~~ Reading program results ~~~~~~
> 419     IYC519  140201                          169.75          XXX111
> Bill    Smith   123, Any Street Some Town       Elsewhere       County
> XX1 @AB 01234 567890    bill.smith@url.com
> 0       Copy tape (0.25
>
> 0    4 = 52
>          1    1 = 49
>          2    9 = 57
>          3        = 9
>          4    I = 73
>          5    Y = 89
>          6    C = 67
>          7    5 = 53
>          8    1 = 49
>          9    9 = 57
>          10       = 9
>          11    1 = 49
>          12    4 = 52
>          13    0 = 48
>          14    2 = 50
>          15    0 = 48
>          16    1 = 49
>          17       = 9
>          18       = 9
>          19       = 9
>          20       = 9
>          21    1 = 49
>          22    6 = 54
>          23    9 = 57
>          24    . = 46
>          25    7 = 55
>          26    5 = 53
>          27       = 9
>          28       = 9
>          29    X = 88
>          30    X = 88
>          31    X = 88
>          32    1 = 49
>          33    1 = 49
>          34    1 = 49
>          35       = 9
>          36    B = 66
>          37    i = 105
>          38    l = 108
>          39    l = 108
>          40       = 9
>          41    S = 83
>          42    m = 109
>          43    i = 105
>          44    t = 116
>          45    h = 104
>          46       = 9
>          47    1 = 49
>          48    2 = 50
>          49    3 = 51
>          50    , = 44
>          51      = 32
>          52    A = 65
>          53    n = 110
>          54    y = 121
>          55      = 32
>          56    S = 83
>          57    t = 116
>          58    r = 114
>          59    e = 101
>          60    e = 101
>          61    t = 116
>          62       = 9
>          63    S = 83
>          64    o = 111
>          65    m = 109
>          66    e = 101
>          67      = 32
>          68    T = 84
>          69    o = 111
>          70    w = 119
>          71    n = 110
>          72       = 9
>          73    E = 69
>          74    l = 108
>          75    s = 115
>          76    e = 101
>          77    w = 119
>          78    h = 104
>          79    e = 101
>          80    r = 114
>          81    e = 101
>          82       = 9
>          83    C = 67
>          84    o = 111
>          85    u = 117
>          86    n = 110
>          87    t = 116
>          88    y = 121
>          89       = 9
>          90    X = 88
>          91    X = 88
>          92    1 = 49
>          93      = 32
>          94    @ = 64
>          95    A = 65
>          96    B = 66
>          97       = 9
>          98    0 = 48
>          99    1 = 49
>          100    2 = 50
>          101    3 = 51
>          102    4 = 52
>          103      = 32
>          104    5 = 53
>          105    6 = 54
>          106    7 = 55
>          107    8 = 56
>          108    9 = 57
>          109    0 = 48
>          110      = 9
>          111    b = 98
>          112    i = 105
>          113    l = 108
>          114    l = 108
>          115    . = 46
>          116    s = 115
>          117    m = 109
>          118    i = 105
>          119    t = 116
>          120    h = 104
>          121    @ = 64
>          122    u = 117
>          123    r = 114
>          124    l = 108
>          125    . = 46
>          126    c = 99
>          127    o = 111
>          128    m = 109
>          129      = 9
>          130      = 9
>          131      = 9
>          132      = 9
>          133    0 = 48
>          134      = 9
>          135    C = 67
>          136    o = 111
>          137    p = 112
>          138    y = 121
>          139      = 32
>          140    t = 116
>          141    a = 97
>          142    p = 112
>          143    e = 101
>          144      = 32
>          145    ( = 40
>          146    0 = 48
>          147    . = 46
>          148    2 = 50
>          149    5 = 53
>          150     = 0
>          151     = 0
>          152     = 0
>          153     = 0
>          154     = 0
>          155     = 0
>          156     = 0
>          157     = 0
>          158     = 0
>          159     = 0
>          160     = 0
>          161     = 0
>          162     = 0
>          163     = 0
>          164     = 0
>          165     = 0
>          166     = 0
>          167     = 0
>          168     = 0
>          169     = 0
>          170     = 0
>          171     = 0
>          172     = 0
>          173     = 0
>          174     = 0
>          175     = 0
>          176     = 0
>          177     = 0
>          178     = 0
>          179     = 0
>          180     = 0
>          181     = 0
>          182     = 0
>          183     = 0
>          184     = 0
>          185     = 0
>          186     = 0
>          187     = 0
>          188     = 0
>          189     = 0
>          190     = 0
>          191     = 0
>          192     = 0
>          193     = 0
>          194     = 0
>          195     = 0
>          196     = 0
>          197     = 0
>          198     = 0
>          199     = 0
>
> ~~~~~~~ end of reading program results ~~~~~~~~
>
>
> The reading program was:
>
> ~~~~~~~ Reading program ~~~~~~~~~
> <?php
>
>
> ## GET file URL from link and read data from file ###
>
> $fileURL =  $_GET['iyc'];
>
> $fileURL = ($_SERVER['DOCUMENT_ROOT'] . "/Payment/phpfiles/") .
> $fileURL;
> $fh = fopen($fileURL, 'r') or die("<FONT COLOR=\"#CCFFFF\"><B>invoicer3
> can't open file $fileURL</B></FONT>");
>          $txt = fread($fh, filesize($fileURL));
> fclose($fh);
>
> print $txt;
> print "
>
> ";
>
> $i=0;
>
> while ($i<200)
>          {
>          print $i . "    ";
>          print ($txt{$i}) . " = ";
>          print (ord($txt{$i}));
>          print "
>          ";
>          $i++;
>          }
>
>
> ?>
>
> ~~~~~ end of reading program ~~~~~
>
>
>

Well, first of all, if you're going to do any web work, you need a local 
development system to test on.  This means duplicating as close as you 
can the same software you have on your production system (NEVER do 
development on a production system!).

And right now you have a number of different programs involved, any of 
which can be causing a problem, even how you're handling the cut/paste 
in your code.

fwrite() doesn't have a problem with writing double quotes to a file; 
such a problem would render it pretty useless.

Listing the file to the terminal means display its contents on the local 
terminal.  Windows users would use the 'type' command; in *nix systems 
the command is 'cat'.  But you need to be at a command prompt on the 
system with the file to use it (something you also need to be able to do).

What is in $txt immediately after the fwrite()?

BTW - you should NEVER use die() in production code.  It terminates 
processing of EVERYTHING (including the HTML) immediately, resulting in 
invalid HTML being sent to the browser.  Rather, you should test for 
failure, and if it fails, just not execute the code dependent on the 
operation working (and put out a failure message instead, if you wish).

You also realize your code is not multiprocessing safe.  What happens, 
for instance, if two people try to write to the same file at the same 
time?  Or after one person writes, a second one overwrites the file with 
different data?  There is no guarantee a filename passed in a URL is unique.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#12736

From	adrian@poppyrecords.invalid.invalid (Adrian Tuddenham)
Date	2014-02-01 16:38 +0000
Message-ID	<1lgecvh.x0bk6rlzuxueN%adrian@poppyrecords.invalid.invalid>
In reply to	#12734

Jerry Stuckle <jstucklex@attglobal.net> wrote:

[...]
> Well, first of all, if you're going to do any web work, you need a local
> development system to test on.  This means duplicating as close as you
> can the same software you have on your production system (NEVER do 
> development on a production system!).

I don't think there is any suitable software for Mac OS8.6, which is my
current system.  I may be able to sort out something on an OSX machine
later, but for now I have to work with what I have got.

> 
> And right now you have a number of different programs involved, any of
> which can be causing a problem, even how you're handling the cut/paste
> in your code.

You are right, see below:

> 
> fwrite() doesn't have a problem with writing double quotes to a file;
> such a problem would render it pretty useless.
> 
> Listing the file to the terminal means display its contents on the local
> terminal.  Windows users would use the 'type' command; in *nix systems
> the command is 'cat'.  But you need to be at a command prompt on the 
> system with the file to use it (something you also need to be able to do).
> 
> What is in $txt immediately after the fwrite()?

I have now been through the system putting in lines to write the value
of $txt at each stage.  I thought I had done this before, but it looks
as though I became confused between two of the stages and mis-identified
where the problem was occurring.  

The problem does, in fact, appear to be occurring around the transfer
between the previous HTML program and the one I thought was causing the
problem  The value of $txt is transferred between the two by a POST form
with 'txt' as a hidden input.

~~~~~~~~ Sending code within an HTML page ~~~~~~~

<!--NOEDIT--><?php

Print "<P><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Sent = \"$Sent\"   
 </B></FONT><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Paid =
\"</B></FONT><FONT SIZE=\"+2\"
COLOR=\"#FF0000\"><B>$Paid</B></FONT><FONT SIZE=\"+1\"
COLOR=\"#CCFFFF\"><B>\"       Reminder = \"$Reminder\"</B></FONT>";

print"<P><FORM
ACTION=\"http://www.poppyrecords.co.uk/php/PayFileGen2.php\"
METHOD=POST><CENTER><INPUT TYPE=hidden NAME=txt VALUE=\"$txt\"><INPUT
TYPE=submit NAME=Submit VALUE=\"O.K.\"></B></FONT></CENTER></FORM>";
print $txt;
?><!--/NOEDIT-->
~~~~~ end of sending code ~~~~~~~

The "print $txt;" statement shows the data to be unchanged at this
point.  At the receiving end I have the following code:

~~~~~~ Receiving code within a PHP program (PayFileGen2.php) ~~~~~~~

$txt =  $_POST['txt'];
print $txt;

$txt = str_replace("<", ">", $txt);

$fileURL = ($_SERVER['DOCUMENT_ROOT'] . "/Payment/phpfiles");
$readerURL = "http://www.poppyrecords.co.uk/php/invoicer3.php";
###etc###

~~~~~~ end of receiving code ~~~~~~~~~

At this point, the "print $txt" statement shows the truncated code, so
it looks as though the problem could be in my POST-ing code.  It is
strange that the data had already undergone one POST transfer from when
it was Pasted into the Form of a previous program - and it seemed to
survive that unscathed.

> 
> BTW - you should NEVER use die() in production code.  It terminates 
> processing of EVERYTHING (including the HTML) immediately, resulting in
> invalid HTML being sent to the browser.  Rather, you should test for 
> failure, and if it fails, just not execute the code dependent on the 
> operation working (and put out a failure message instead, if you wish).

What is the code for the alternative to "die"?  "Die" was all I could
find when I looked up examples of PHP file handling.

> 
> You also realize your code is not multiprocessing safe.  What happens,
> for instance, if two people try to write to the same file at the same
> time?  Or after one person writes, a second one overwrites the file with
> different data?  There is no guarantee a filename passed in a URL is unique.

I did realise that, but I am the only one who uses this system and the
HTML file which initiates the process lives on my desktop and is not
available on the Web.

-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12737

From	Doug Miller <doug_at_milmac_dot_com@example.com>
Date	2014-02-01 16:46 +0000
Message-ID	<XnsA2C777A19542Fdougmilmaccom@78.46.70.116>
In reply to	#12736

adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) wrote in 
news:1lgecvh.x0bk6rlzuxueN%adrian@poppyrecords.invalid.invalid:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
 
>> BTW - you should NEVER use die() in production code.  It terminates 
>> processing of EVERYTHING (including the HTML) immediately, resulting in
>> invalid HTML being sent to the browser.  Rather, you should test for 
>> failure, and if it fails, just not execute the code dependent on the 
>> operation working (and put out a failure message instead, if you wish).
> 
> What is the code for the alternative to "die"? 
> 
The alternative is exactly as described: write whatever code you need to write to handle the 
error gracefully, instead of simply terminating processing (which is what die() does).

Of course since, as you go on to say, you are the only user of this code, it doesn't much matter.

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

#12738

From	Christoph Michael Becker <cmbecker69@arcor.de>
Date	2014-02-01 18:07 +0100
Message-ID	<52ed29c0$0$6654$9b4e6d93@newsspool2.arcor-online.net>
In reply to	#12736

Adrian Tuddenham wrote:

> ~~~~~~~~ Sending code within an HTML page ~~~~~~~
> 
> <!--NOEDIT--><?php
> 
> Print "<P><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Sent = \"$Sent\"   
>  </B></FONT><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Paid =
> \"</B></FONT><FONT SIZE=\"+2\"
> COLOR=\"#FF0000\"><B>$Paid</B></FONT><FONT SIZE=\"+1\"
> COLOR=\"#CCFFFF\"><B>\"       Reminder = \"$Reminder\"</B></FONT>";
>  
> print"<P><FORM
> ACTION=\"http://www.poppyrecords.co.uk/php/PayFileGen2.php\"
> METHOD=POST><CENTER><INPUT TYPE=hidden NAME=txt VALUE=\"$txt\"><INPUT
                                                  ^^^^^^^^^^^^^^
> TYPE=submit NAME=Submit VALUE=\"O.K.\"></B></FONT></CENTER></FORM>";
> print $txt;
> ?><!--/NOEDIT-->
> ~~~~~ end of sending code ~~~~~~~

Consider the code that will be generated for the part "highlighted"
above, when there are double-quotes contained in $txt.

You should never ever output variables which may contain special
characters to your HTML unescaped; use htmlspecialchars()[1].

[1] <http://www.php.net/manual/en/function.htmlspecialchars.php>

-- 
Christoph M. Becker

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

#12739

From	adrian@poppyrecords.invalid.invalid (Adrian Tuddenham)
Date	2014-02-01 18:00 +0000
Message-ID	<1lgehed.jwy09vrrsa5yN%adrian@poppyrecords.invalid.invalid>
In reply to	#12738

Christoph Michael Becker <cmbecker69@arcor.de> wrote:

> Adrian Tuddenham wrote:
> 
> > ~~~~~~~~ Sending code within an HTML page ~~~~~~~
> > 
> > <!--NOEDIT--><?php
> > 
> > Print "<P><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Sent = \"$Sent\"
> >  </B></FONT><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Paid =
> > \"</B></FONT><FONT SIZE=\"+2\"
> > COLOR=\"#FF0000\"><B>$Paid</B></FONT><FONT SIZE=\"+1\"
> > COLOR=\"#CCFFFF\"><B>\"       Reminder = \"$Reminder\"</B></FONT>";
> >  
> > print"<P><FORM
> > ACTION=\"http://www.poppyrecords.co.uk/php/PayFileGen2.php\"
> > METHOD=POST><CENTER><INPUT TYPE=hidden NAME=txt VALUE=\"$txt\"><INPUT
>                                                   ^^^^^^^^^^^^^^
> > TYPE=submit NAME=Submit VALUE=\"O.K.\"></B></FONT></CENTER></FORM>";
> > print $txt;
> > ?><!--/NOEDIT-->
> > ~~~~~ end of sending code ~~~~~~~
> 
> Consider the code that will be generated for the part "highlighted"
> above, when there are double-quotes contained in $txt.
> 
> You should never ever output variables which may contain special
> characters to your HTML unescaped; use htmlspecialchars()[1].
> 
> [1] <http://www.php.net/manual/en/function.htmlspecialchars.php>

I did not think I was outputting the variable to HTML, the handler for
that code is written in PHP (although it does generate some HTML, but
the problem occurs before that bit).  

Would it make more sense to re-write the program above so that it is a
PHP program and generates the necessary HTML, rather than being an HTML
page with PHP code embedded in it?



-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12740

From	Christoph Michael Becker <cmbecker69@arcor.de>
Date	2014-02-01 20:07 +0100
Message-ID	<52ed45e6$0$6667$9b4e6d93@newsspool2.arcor-online.net>
In reply to	#12739

Adrian Tuddenham wrote:

> Christoph Michael Becker <cmbecker69@arcor.de> wrote:
> 
>> Adrian Tuddenham wrote:
>>
>>> ~~~~~~~~ Sending code within an HTML page ~~~~~~~
>>>
>>> <!--NOEDIT--><?php
>>>
>>> Print "<P><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Sent = \"$Sent\"
>>>  </B></FONT><FONT SIZE=\"+1\" COLOR=\"#CCFFFF\"><B>Paid =
>>> \"</B></FONT><FONT SIZE=\"+2\"
>>> COLOR=\"#FF0000\"><B>$Paid</B></FONT><FONT SIZE=\"+1\"
>>> COLOR=\"#CCFFFF\"><B>\"       Reminder = \"$Reminder\"</B></FONT>";
>>>  
>>> print"<P><FORM
>>> ACTION=\"http://www.poppyrecords.co.uk/php/PayFileGen2.php\"
>>> METHOD=POST><CENTER><INPUT TYPE=hidden NAME=txt VALUE=\"$txt\"><INPUT
>>                                                   ^^^^^^^^^^^^^^
>>> TYPE=submit NAME=Submit VALUE=\"O.K.\"></B></FONT></CENTER></FORM>";
>>> print $txt;
>>> ?><!--/NOEDIT-->
>>> ~~~~~ end of sending code ~~~~~~~
>>
>> Consider the code that will be generated for the part "highlighted"
>> above, when there are double-quotes contained in $txt.
>>
>> You should never ever output variables which may contain special
>> characters to your HTML unescaped; use htmlspecialchars()[1].
>>
>> [1] <http://www.php.net/manual/en/function.htmlspecialchars.php>
> 
> I did not think I was outputting the variable to HTML, the handler for
> that code is written in PHP (although it does generate some HTML, but
> the problem occurs before that bit).

Consider the following simplified example:

  <?php
    $txt = "foo\"bar";
    print "<input type=hidden name=txt value=\"$txt\">";

Thil os wilutput the following HTML:

  <input type=hidden name=txt value="foo"bar>

Obviously, the value of the value attribute is terminated by the second
double-quote, so it is foo.  The browser is most likely going to ignore
the bar, because it is an unknown attribute name.

What you want is the following:

  <input type=hidden name=txt value="foo&quot;bar">

To have it, you can use the following PHP code:

  <?php
    $txt = "foo\"bar";
    print "<input type=hidden name=txt value=\"" .
      htmlspecialchars($txt) . "\">";

However, note that it is necessary to set the correct character encoding
as third parameter of htmlspecialchars() (otherwise it may not work
correctly).  The default value depends on the PHP version.  If you're
using a current version (i.e. PHP 5.4 or newer), it is UTF-8.  If you're
using UTF-8 encoding (what's usually recommendable), you can omit the
parameter.  Otherwise you have to use something like:

  htmlspecialchars($txt, ENT_COMPAT, 'ISO-8859-1');

Note, that there are caveats regarding the second parameter, too; see
the manual[1].

> Would it make more sense to re-write the program above so that it is a
> PHP program and generates the necessary HTML, rather than being an HTML
> page with PHP code embedded in it?

That doesn't make a difference wrt. to escaping the characters.

[1] <http://php.net/manual/en/function.htmlspecialchars.php>

-- 
Christoph M. Becker

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

#12742

From	Denis McMahon <denismfmcmahon@gmail.com>
Date	2014-02-01 19:26 +0000
Message-ID	<lcjhp8$k7c$2@dont-email.me>
In reply to	#12739

On Sat, 01 Feb 2014 18:00:30 +0000, Adrian Tuddenham wrote:

> I did not think I was outputting the variable to HTML, the handler for
> that code is written in PHP (although it does generate some HTML, but
> the problem occurs before that bit).

Regardless of how the data gets there, you're placing the string contents 
of the variable concerned in the value attribute of an input element in 
an html document.

The attributes of the html input element are probably defined as follows:

<input type="hidden" name="something" value="something">

The web browser only receives and processes html, so if you write the 
string

The quick brown "fox" jumps over the lazy dog

into the value field, then the html parser in the web browser sees:

<input type="hidden" name="something" value="The quick brown "fox" jumps 
over the lazy dog">

It parses this into the following:

An input element

	with type attribute of value "hidden"

	and name attribute of value "something"

	and value attribute of value "The quick brown "

	and fox attribute of value true (which it may treat as garbage 
and discard)

	and a string of " jumps over the lazy dog" (which it probably 
treats as garbage and discards)

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#12743

From	Denis McMahon <denismfmcmahon@gmail.com>
Date	2014-02-01 19:29 +0000
Message-ID	<lcjhue$k7c$3@dont-email.me>
In reply to	#12742

On Sat, 01 Feb 2014 19:26:32 +0000, Denis McMahon wrote:

> On Sat, 01 Feb 2014 18:00:30 +0000, Adrian Tuddenham wrote:
> 
>> I did not think I was outputting the variable to HTML, the handler for
>> that code is written in PHP (although it does generate some HTML, but
>> the problem occurs before that bit).
> 
> Regardless of how the data gets there, you're placing the string
> contents of the variable concerned in the value attribute of an input
> element in an html document.

Oh - check the view page source option in your web browser to see what 
the web browser actually receives, or even use the w3c validator which 
will highlight any errors and warnings for the html you are generating.

w3c validator is at http://validator.w3.org/unicorn/

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#12745

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2014-02-02 21:55 +0100
Message-ID	<2563784.ZnRLnDoXCd@PointedEars.de>
In reply to	#12743

Denis McMahon wrote:

> On Sat, 01 Feb 2014 19:26:32 +0000, Denis McMahon wrote:
>> On Sat, 01 Feb 2014 18:00:30 +0000, Adrian Tuddenham wrote:
>>> I did not think I was outputting the variable to HTML, the handler for
>>> that code is written in PHP (although it does generate some HTML, but
>>> the problem occurs before that bit).
>> 
>> Regardless of how the data gets there, you're placing the string
>> contents of the variable concerned in the value attribute of an input
>> element in an html document.
> 
> Oh - check the view page source option in your web browser to see what
> the web browser actually receives, or even use the w3c validator which
> will highlight any errors and warnings for the html you are generating.
> 
> w3c validator is at http://validator.w3.org/unicorn/

That is URI of the W3C *Unified* Validator which can be used if you want to 
check everything, HTML, CSS and so on at the same time (instead of using the 
W3C Markup Validator [1], and then the W3C CSS Validator at 
<http://jigsaw.w3.org/css-validator> as well as other validation services).
See <http://code.w3.org/unicorn> for details.

If one only wants to check the markup, one should use the W3C *Markup* 
Validator at

[1] <http://validator.w3.org/>

which is faster and more to the point than the Unified Validator because it 
only performs the markup checks that are relevant here.

Likewise, if one only wants to check a stylesheet, or all the stylesheets 
used by a document, one should use the CSS Validator instead.

PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

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

#12744

From	adrian@poppyrecords.invalid.invalid (Adrian Tuddenham)
Date	2014-02-02 18:33 +0000
Message-ID	<1lgge4f.125to2l1nhujrmN%adrian@poppyrecords.invalid.invalid>
In reply to	#12742

Denis McMahon <denismfmcmahon@gmail.com> wrote:

> On Sat, 01 Feb 2014 18:00:30 +0000, Adrian Tuddenham wrote:
> 
> > I did not think I was outputting the variable to HTML, the handler for
> > that code is written in PHP (although it does generate some HTML, but
> > the problem occurs before that bit).
> 
> Regardless of how the data gets there, you're placing the string contents
> of the variable concerned in the value attribute of an input element in
> an html document.
> 
> The attributes of the html input element are probably defined as follows:
> 
> <input type="hidden" name="something" value="something">
> 
> The web browser only receives and processes html, so if you write the
> string
> 
> The quick brown "fox" jumps over the lazy dog
> 
> into the value field, then the html parser in the web browser sees:
> 
> <input type="hidden" name="something" value="The quick brown "fox" jumps
> over the lazy dog">
> 
> It parses this into the following:
> 
> An input element
> 
>       with type attribute of value "hidden"
> 
>       and name attribute of value "something"
> 
>       and value attribute of value "The quick brown "
> 
>       and fox attribute of value true (which it may treat as garbage 
> and discard)
> 
>       and a string of " jumps over the lazy dog" (which it probably 
> treats as garbage and discards)

Thanks.  This solves the puzzle, although it does raise the question of
how the same string got through the previous POST without this
happening.  Now I know what I am looking for. I'll have a better chance
of sorting it out.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12741

From	Denis McMahon <denismfmcmahon@gmail.com>
Date	2014-02-01 19:18 +0000
Message-ID	<lcjhae$k7c$1@dont-email.me>
In reply to	#12736

On Sat, 01 Feb 2014 16:38:56 +0000, Adrian Tuddenham wrote:

> The problem does, in fact, appear to be occurring around the transfer
> between the previous HTML program and the one I thought was causing the
> problem  The value of $txt is transferred between the two by a POST form
> with 'txt' as a hidden input.

The problem will be in the html that is being sent out at that point. If 
you have an html element as follows:

<input type="hidden" name="fieldname" value="value_text_here">

What do you think happens if value_text_here contains the '"' character 
when the delimiter being used for the value attribute is also the '"' 
character?

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#12735

From	Christoph Michael Becker <cmbecker69@arcor.de>
Date	2014-02-01 17:03 +0100
Message-ID	<52ed1acd$0$6662$9b4e6d93@newsspool2.arcor-online.net>
In reply to	#12731

Adrian Tuddenham wrote:

> The data string is held in the variiable '$txt' and the write command
> is:
> 
> ~~~~~~~~
> $fh = fopen($fileURL, 'w') or die("<FONT
> COLOR=\"#CCFFFF\"><B>PayFileGen2 can't open file $fileURL</B></FONT>");
>         fwrite($fh, $txt);
> fclose($fh);
> 
> ~~~~~~~~

Have you confirmed that the variable $txt holds what you're expecting?
For instance, you can add

  var_dump($txt);

before or after the code that writes to the file.

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

csiph-web

Writing double-prime to file?

Contents

#12731 — Writing double-prime to file?

#12732

#12733

#12734

#12736

#12737

#12738

#12739

#12740

#12742

#12743

#12745

#12744

#12741

#12735