| session question [message #177665] |
Thu, 12 April 2012 16:43  |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
I have a site with an input form that recursively calls itself via
action="<?php echo $_SERVER['PHP_SELF']; ?>", and a couple links with
url encoded data that indicate simple selections w/o using a form. It
uses different include('file'); statements based on the progress and/or
choices previously made, and it works fine, but is a little complicated
to track "state" when troubleshooting, updating, or changing.
I am thinking of using a session approach which would be simpler to
follow, but have never used sessions on a page that is recursively called.
First since session_start() would be called every iteration, that will
cause an error unless I encapsulate it in an if loop to see if the
session already exists. Is this the preferred method?
Second, when the user is finished and receives an acknowledgement I plan
to call a session_unset() to clear things up so that if they want to do
it again, they are beginning with a clean slate. Again, is this the
preferred method?
|
|
|
|
| Re: session question [message #177666 is a reply to message #177665] |
Thu, 12 April 2012 16:56  |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 4/12/2012 9:43 AM, William Gill wrote:
> I have a site with an input form that recursively calls itself via
> action="<?php echo $_SERVER['PHP_SELF']; ?>", and a couple links with
> url encoded data that indicate simple selections w/o using a form. It
> uses different include('file'); statements based on the progress and/or
> choices previously made, and it works fine, but is a little complicated
> to track "state" when troubleshooting, updating, or changing.
>
> I am thinking of using a session approach which would be simpler to
> follow, but have never used sessions on a page that is recursively called.
>
> First since session_start() would be called every iteration, that will
> cause an error unless I encapsulate it in an if loop to see if the
> session already exists. Is this the preferred method?
>
> Second, when the user is finished and receives an acknowledgement I plan
> to call a session_unset() to clear things up so that if they want to do
> it again, they are beginning with a clean slate. Again, is this the
> preferred method?
>
>
You won't get an error for calling session_start on a page that calls
itself 'unless' you have it being called multiple times such as in one
of your include files.
Each call to that page whether it is from another page or itself is a
separate new call to that page and the session_start does not carry over.
Do not use session_unset unless you are on an old PHP install (4) i
think, in which case get it updated
use the unset() method.
But I would not use that solely.
I personally empty each $_SESSION variable
with $_SESSION = array();
I guess you could use session_destroy() but I have not used this and am
not sure how it behaves.
Sure someone will have some more info on this.
|
|
|
|
| Re: session question [message #177670 is a reply to message #177665] |
Thu, 12 April 2012 17:43 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 12.04.2012 18:43, schrieb William Gill:
> I have a site with an input form that recursively calls itself via action="<?php echo
> $_SERVER['PHP_SELF']; ?>", and a couple links with url encoded data that indicate
> simple selections w/o using a form. It uses different include('file'); statements
> based on the progress and/or choices previously made, and it works fine, but is a
> little complicated to track "state" when troubleshooting, updating, or changing.
>
> I am thinking of using a session approach which would be simpler to follow, but have
> never used sessions on a page that is recursively called.
>
> First since session_start() would be called every iteration, that will cause an error
> unless I encapsulate it in an if loop to see if the session already exists. Is this
> the preferred method?
>
> Second, when the user is finished and receives an acknowledgement I plan to call a
> session_unset() to clear things up so that if they want to do it again, they are
> beginning with a clean slate. Again, is this the preferred method?
>
call session_start() at the beginning of your script.
Do not use session_unset(), it is old as Scott said. Assign null to your session
variables, or unset() them, but do not unset($_SESSION)
See
http://groups.google.com/group/comp.lang.php/browse_thread/thread/8b3b25491 e095a49/76d6a3eeb680f503
there is an example of session usage.
|
|
|
|
| Re: session question [message #177671 is a reply to message #177665] |
Thu, 12 April 2012 17:59 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 12.04.2012 18:43, schrieb William Gill:
> I have a site with an input form that recursively calls itself via action="<?php echo
> $_SERVER['PHP_SELF']; ?>", and a couple links with url encoded data that indicate
> simple selections w/o using a form. It uses different include('file'); statements
> based on the progress and/or choices previously made, and it works fine, but is a
> little complicated to track "state" when troubleshooting, updating, or changing.
>
> I am thinking of using a session approach which would be simpler to follow, but have
> never used sessions on a page that is recursively called.
>
> First since session_start() would be called every iteration, that will cause an error
> unless I encapsulate it in an if loop to see if the session already exists. Is this
> the preferred method?
>
> Second, when the user is finished and receives an acknowledgement I plan to call a
> session_unset() to clear things up so that if they want to do it again, they are
> beginning with a clean slate. Again, is this the preferred method?
>
>
.... and look up all the functions you want to use in the manual, read down to "See
Also", and read them as well.
/Str.
|
|
|
|
| Re: session question [message #177680 is a reply to message #177665] |
Fri, 13 April 2012 09:18 |
Captain Paralytic
Messages: 204
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Apr 12, 5:43 pm, William Gill <nore...@domain.invalid> wrote:
> I have a site with an input form that recursively calls itself via
> action="<?php echo $_SERVER['PHP_SELF']; ?>", and a couple links with
> url encoded data that indicate simple selections w/o using a form. It
> uses different include('file'); statements based on the progress and/or
> choices previously made, and it works fine, but is a little complicated
> to track "state" when troubleshooting, updating, or changing.
>
> I am thinking of using a session approach which would be simpler to
> follow, but have never used sessions on a page that is recursively called..
>
> First since session_start() would be called every iteration, that will
> cause an error unless I encapsulate it in an if loop to see if the
> session already exists. Is this the preferred method?
>
> Second, when the user is finished and receives an acknowledgement I plan
> to call a session_unset() to clear things up so that if they want to do
> it again, they are beginning with a clean slate. Again, is this the
> preferred method?
Your form is not recursive. When it is displayed the php script is
completed. The next time it is submitted it is treated as a new
process.
|
|
|
|
| Re: session question [message #177686 is a reply to message #177665] |
Fri, 13 April 2012 13:27 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 12 Apr 2012 12:43:28 -0400, William Gill wrote:
> I have a site with an input form that recursively calls itself via
> action="<?php echo $_SERVER['PHP_SELF']; ?>"
Nope. Recursive is the wrong term to use here. It calls itself, yes, but
does not do so in a truly recursive manner.
> I am thinking of using a session approach which would be simpler to
> follow, but have never used sessions on a page that is recursively
> called.
This is not recursive calling. In recursive calling, a function calls
itself from within itself.
In a web page that includes a link back to itself, it has completed all
processing before it is called again.
Just include a single call to session_start() at the start of the main php
script file, and don't call it on the included php script files.
Rgds
Denis McMahon
|
|
|
|
| Re: session question [message #177691 is a reply to message #177686] |
Fri, 13 April 2012 17:51 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/13/2012 9:27 AM, Denis McMahon wrote:
> Nope. Recursive is the wrong term to use here. It calls itself, yes, but
> does not do so in a truly recursive manner.
>
>> I am thinking of using a session approach which would be simpler to
>> follow, but have never used sessions on a page that is recursively
>> called.
>
> This is not recursive calling. In recursive calling, a function calls
> itself from within itself.
>
> In a web page that includes a link back to itself, it has completed all
> processing before it is called again.
>
> Just include a single call to session_start() at the start of the main php
> script file, and don't call it on the included php script files.
Though I agree with your definition of recursive calling of a function,
I'm not sure the term recursive is limited to functions. However maybe
repetitively would have been a better choice.
To clear up some things for some of the other respondents, the page gets
called several ways.
1) The initial GET domain/page.php which includes() an intro and list of
links.
2) A second GET from one of the links:
<a href="<?php echo $_SERVER['PHP_SELF'] ?>?whoDoYouWantToContact=John">
which then includes() the HTML form.
3) A POST from the form:
<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post" >
which then includes() a process the form script and an acknowledgement
that the data was received.
Denis, my testing confirms that you are correct, placing the
session_start() on the core page does not produce errors on subsequent
GETS or POSTS. Which makes logical sense, but seemed to conflict with
the manual. Thanks, helping clear that up.
|
|
|
|
| Re: session question [message #177692 is a reply to message #177691] |
Fri, 13 April 2012 19:54 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/13/2012 1:51 PM, William Gill wrote:
> On 4/13/2012 9:27 AM, Denis McMahon wrote:
>> Nope. Recursive is the wrong term to use here. It calls itself, yes, but
>> does not do so in a truly recursive manner.
>>
>>> I am thinking of using a session approach which would be simpler to
>>> follow, but have never used sessions on a page that is recursively
>>> called.
>>
>> This is not recursive calling. In recursive calling, a function calls
>> itself from within itself.
>>
>> In a web page that includes a link back to itself, it has completed all
>> processing before it is called again.
>>
>> Just include a single call to session_start() at the start of the main
>> php
>> script file, and don't call it on the included php script files.
>
> Though I agree with your definition of recursive calling of a function,
> I'm not sure the term recursive is limited to functions. However maybe
> repetitively would have been a better choice.
>
> To clear up some things for some of the other respondents, the page gets
> called several ways.
>
> 1) The initial GET domain/page.php which includes() an intro and list of
> links.
>
> 2) A second GET from one of the links:
> <a href="<?php echo $_SERVER['PHP_SELF'] ?>?whoDoYouWantToContact=John">
> which then includes() the HTML form.
>
> 3) A POST from the form:
> <form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post" >
> which then includes() a process the form script and an acknowledgement
> that the data was received.
>
> Denis, my testing confirms that you are correct, placing the
> session_start() on the core page does not produce errors on subsequent
> GETS or POSTS. Which makes logical sense, but seemed to conflict with
> the manual. Thanks, helping clear that up.
>
>
William, Denis is correct. You are not calling the page recursively.
Recursive is when something calls itself without terminating. Web
scripts are transactional in nature - the first script finishes before
the page is ever presented to the user. So when the user clicks on a
link (or whatever) to request the next page, a brand new request starts
out. Nothing is left over from the previous request except what is sent
in the GET/POST parameters and cookies.
Note that saving data on the server in the $_SESSION still requires the
session ID to be sent in one of the above parameters so you can save
additional data on the server, but this is just to make things easier on
the programmer.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: session question [message #177745 is a reply to message #177691] |
Fri, 20 April 2012 06:40 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/13/2012 1:51 PM, William Gill wrote:
> ...my testing confirms that you are correct, placing the
> session_start() on the core page does not produce errors on subsequent
> GETS or POSTS. Which makes logical sense, but seemed to conflict with
> the manual. Thanks, helping clear that up.
>
After all this, I move the pages from a Windows development server to a
Linux production server and even though <?php session_start(); ?> is
before the DOCTYPE declaration I get "Cannot send session cache limiter
- headers already sent..."
Only way that got rid of the error was to use an .htaccess file to auto
start sessions for that folder.
|
|
|
|
| Re: session question [message #177754 is a reply to message #177745] |
Fri, 20 April 2012 08:55 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.04.2012 08:40, schrieb William Gill:
> On 4/13/2012 1:51 PM, William Gill wrote:
>
>> ...my testing confirms that you are correct, placing the
>> session_start() on the core page does not produce errors on subsequent
>> GETS or POSTS. Which makes logical sense, but seemed to conflict with
>> the manual. Thanks, helping clear that up.
>>
> After all this, I move the pages from a Windows development server to a Linux
> production server and even though <?php session_start(); ?> is before the DOCTYPE
> declaration I get "Cannot send session cache limiter - headers already sent..."
>
> Only way that got rid of the error was to use an .htaccess file to auto start
> sessions for that folder.
The error is in your PHP file.
There is definitely no need to use a .htaccess file to start a session. Not "even" on
a *nix system, which is the home of web servers, php and the complete internet.
/Str.
|
|
|
|
| Re: session question [message #177757 is a reply to message #177745] |
Fri, 20 April 2012 09:25 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 8:40 AM, William Gill wrote:
> On 4/13/2012 1:51 PM, William Gill wrote:
>
>> ...my testing confirms that you are correct, placing the
>> session_start() on the core page does not produce errors on subsequent
>> GETS or POSTS. Which makes logical sense, but seemed to conflict with
>> the manual. Thanks, helping clear that up.
>>
> After all this, I move the pages from a Windows development server to a
> Linux production server and even though <?php session_start(); ?> is
> before the DOCTYPE declaration I get "Cannot send session cache limiter
> - headers already sent..."
>
> Only way that got rid of the error was to use an .htaccess file to auto
> start sessions for that folder.
>
>
Hi,
That error means you DID send output before calling session_start().
Try to figure out if you are including anything before that line that
might produce the output, even a SPACE or NEWLINE is output.
I do sometimes use the .htaccess to autostart sessions for a folder: it
is convenient in some situations: nothing wrong with that.
But you better try to find out WHAT is producing output before your
session_start() call.
I would start with:
1) replace the session_start() call with
echo "**TESTING**";
2) Check the output to your browser and see what appears before
**TESTING**, and from there try to figure out what is responsible for
the output before **TESTING**.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: session question [message #177762 is a reply to message #177745] |
Fri, 20 April 2012 12:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 2:40 AM, William Gill wrote:
> On 4/13/2012 1:51 PM, William Gill wrote:
>
>> ...my testing confirms that you are correct, placing the
>> session_start() on the core page does not produce errors on subsequent
>> GETS or POSTS. Which makes logical sense, but seemed to conflict with
>> the manual. Thanks, helping clear that up.
>>
> After all this, I move the pages from a Windows development server to a
> Linux production server and even though <?php session_start(); ?> is
> before the DOCTYPE declaration I get "Cannot send session cache limiter
> - headers already sent..."
>
> Only way that got rid of the error was to use an .htaccess file to auto
> start sessions for that folder.
>
>
Horse hockey. Fix your code and the problem will go away.
The ONLY reason you get that message is because you've already sent SOME
output to the client. It could be a DOCTYPE, white space or any of a
number of things. But SOMETHING caused the output to be sent.
And if you look at the following message it should tell you exactly
where that output came from.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: session question [message #177765 is a reply to message #177762] |
Fri, 20 April 2012 14:59 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/20/2012 4:55 AM, M. Strobel wrote:
>
> The error is in your PHP file.
>
On 4/20/2012 8:11 AM, Jerry Stuckle wrote:
> Horse hockey. Fix your code and the problem will go away.
>
> The ONLY reason you get that message is because you've already sent SOME
> output to the client. It could be a DOCTYPE, white space or any of a
> number of things. But SOMETHING caused the output to be sent.
>
> And if you look at the following message it should tell you exactly
> where that output came from.
>
I know what the documentation says, and I know what's actually
happening. I have checked "my code"
from the test page:
<?php session_start(); ?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
the first 5 characters in the file are "<?php".
I will pursuing it with the semi-nitwits my hosting company calls
"support."
In the mean time I was hoping someone might look past the knee-jerk "You
f'ed up" response (my initial response too), and give me a clue how or
why something is being output before it's supposed to be. I'd be open to
suggestions how to test what and when the server sends.
I guess I can use telnet to see what the server is sending.
Erwin,
I can't echo anything before the DOCTYPE declaration, and anything
visible would be long after the headers were sent, but thanks.
|
|
|
|
| Re: session question [message #177767 is a reply to message #177765] |
Fri, 20 April 2012 15:32 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/20/2012 10:59 AM, William Gill wrote:
> I will pursuing ...
meant to change tense from am pursuing to will pursue. I sometimes type
faster than I think, and I type very slowly.
|
|
|
|
|
|
| Re: session question [message #177769 is a reply to message #177768] |
Fri, 20 April 2012 16:04 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/20/2012 11:50 AM, Michael Fesser wrote:
> .oO(William Gill)
>
>> I know what the documentation says, and I know what's actually
>> happening. I have checked "my code"
>>
>> from the test page:
>>
>>
>> <?php session_start(); ?>
>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>> "http://www.w3.org/TR/html4/strict.dtd">
>>
>> the first 5 characters in the file are "<?php".
>
> Are you using UTF-8? Then there might be a BOM at the very beginning of
> the file.
>
> Micha
>
And we have a winner ladies and gentlemen!
Thank you very much Micha, at my age pulling my hair out isn't recommended.
|
|
|
|
| Re: session question [message #177770 is a reply to message #177769] |
Fri, 20 April 2012 17:17 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <jms1ef$h74$1(at)dont-email(dot)me>,
William Gill <nospam(at)domain(dot)invalid> wrote:
> On 4/20/2012 11:50 AM, Michael Fesser wrote:
>> .oO(William Gill)
>>
>>> I know what the documentation says, and I know what's actually
>>> happening. I have checked "my code"
>>>
>>> from the test page:
>>>
>>>
>>> <?php session_start(); ?>
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>>> "http://www.w3.org/TR/html4/strict.dtd">
>>>
>>> the first 5 characters in the file are "<?php".
>>
>> Are you using UTF-8? Then there might be a BOM at the very beginning of
>> the file.
>>
>> Micha
>>
> And we have a winner ladies and gentlemen!
>
> Thank you very much Micha, at my age pulling my hair out isn't recommended.
Thus illustrating why it's *not* a good idea to save UTF-8 files with
BOM.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: session question [message #177771 is a reply to message #177770] |
Fri, 20 April 2012 18:08 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.04.2012 19:17, schrieb Tim Streater:
> In article <jms1ef$h74$1(at)dont-email(dot)me>,
> William Gill <nospam(at)domain(dot)invalid> wrote:
>
>> On 4/20/2012 11:50 AM, Michael Fesser wrote:
>>> .oO(William Gill)
>>>
>>>> I know what the documentation says, and I know what's actually
>>>> happening. I have checked "my code"
>>>>
>>>> from the test page:
>>>>
>>>>
>>>> <?php session_start(); ?>
>>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>>>> "http://www.w3.org/TR/html4/strict.dtd">
>>>>
>>>> the first 5 characters in the file are "<?php".
>>>
>>> Are you using UTF-8? Then there might be a BOM at the very beginning of
>>> the file.
>>>
>>> Micha
>>>
>> And we have a winner ladies and gentlemen!
>>
>> Thank you very much Micha, at my age pulling my hair out isn't recommended.
>
> Thus illustrating why it's *not* a good idea to save UTF-8 files with BOM.
Your editor does it for you, you won't see it. The same problem comes up in other
programming languages.
Programs - Webserver, PHP - must adapt to it, it is a legal sign.
/Str.
|
|
|
|
| Re: session question [message #177773 is a reply to message #177769] |
Fri, 20 April 2012 18:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 12:04 PM, William Gill wrote:
> On 4/20/2012 11:50 AM, Michael Fesser wrote:
>> .oO(William Gill)
>>
>>> I know what the documentation says, and I know what's actually
>>> happening. I have checked "my code"
>>>
>>> from the test page:
>>>
>>>
>>> <?php session_start(); ?>
>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>>> "http://www.w3.org/TR/html4/strict.dtd">
>>>
>>> the first 5 characters in the file are "<?php".
>>
>> Are you using UTF-8? Then there might be a BOM at the very beginning of
>> the file.
>>
>> Micha
>>
> And we have a winner ladies and gentlemen!
>
> Thank you very much Micha, at my age pulling my hair out isn't recommended.
IOW, you screwed up and the others here were right. <?php was NOT the
first thing in your file!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: session question [message #177774 is a reply to message #177773] |
Fri, 20 April 2012 19:04 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/20/2012 2:22 PM, Jerry Stuckle wrote:
> IOW, you screwed up and the others here were right. <?php was NOT the
> first thing in your file!
>
Right Jerry. I will remember how finely we should split hairs when
examining future posts.
Of course if I was as smart as you, I wouldn't have had to ask for any
help in the first place.
Note to self: Only the Pope and Jerry are infallible, but the Pope is
limited to "matters of faith", Jerry has no such restriction.
|
|
|
|
| Re: session question [message #177775 is a reply to message #177773] |
Fri, 20 April 2012 19:13 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> IOW, you screwed up and the others here were right. <?php was NOT the
> first thing in your file!
But this issue is not the most obvious, so you can't blame it on him.
Some editors store a BOM without giving notice, others hide such
settings somewhere deep in the preferences.
Hopefully this problem will completely vanish with native Unicode
support in PHP 6.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: session question [message #177777 is a reply to message #177771] |
Fri, 20 April 2012 19:36 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <9vdn1dFc36U1(at)mid(dot)uni-berlin(dot)de>,
"M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> wrote:
> Am 20.04.2012 19:17, schrieb Tim Streater:
>> In article <jms1ef$h74$1(at)dont-email(dot)me>,
>> William Gill <nospam(at)domain(dot)invalid> wrote:
>>> And we have a winner ladies and gentlemen!
>>>
>>> Thank you very much Micha, at my age pulling my hair out isn't
>>> recommended.
>>
>> Thus illustrating why it's *not* a good idea to save UTF-8 files with BOM.
>
> Your editor does it for you, you won't see it. The same problem comes up in
> other programming languages.
>
> Programs - Webserver, PHP - must adapt to it, it is a legal sign.
I Use TextWrangler on a Mac. It, and BBedit, give me the choice to set a
default of how to save files, in the Prefs. So I choose UTF-8. In fact,
the authors are so well aware that the BOM is a pain in the dong, that
you have to explicitly ask for UTF-8,BOM in order to have it. They
changed the defaults this way a few years back.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: session question [message #177778 is a reply to message #177775] |
Fri, 20 April 2012 19:45 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 3:13 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> IOW, you screwed up and the others here were right.<?php was NOT the
>> first thing in your file!
>
> But this issue is not the most obvious, so you can't blame it on him.
> Some editors store a BOM without giving notice, others hide such
> settings somewhere deep in the preferences.
>
> Hopefully this problem will completely vanish with native Unicode
> support in PHP 6.
>
> Micha
>
That's why you should never use a UTF-8 editor. Of, if you need to,
ensure that it's saving in ASCII mode.
And if you want to ensure that the <?php is the first thing in the file,
look at the file in a hex editor.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: session question [message #177780 is a reply to message #177774] |
Fri, 20 April 2012 21:09 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
William Gill wrote:
> On 4/20/2012 2:22 PM, Jerry Stuckle wrote:
>> IOW, you screwed up and the others here were right. <?php was NOT the
>> first thing in your file!
>>
> Right Jerry. I will remember how finely we should split hairs when
> examining future posts.
>
> Of course if I was as smart as you, I wouldn't have had to ask for any
> help in the first place.
>
> Note to self: Only the Pope and Jerry are infallible, but the Pope is
> limited to "matters of faith", Jerry has no such restriction.
+1
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: session question [message #177783 is a reply to message #177778] |
Fri, 20 April 2012 22:11 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <jmsedj$44p$1(at)dont-email(dot)me>,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
> On 4/20/2012 3:13 PM, Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> IOW, you screwed up and the others here were right.<?php was NOT the
>>> first thing in your file!
>>
>> But this issue is not the most obvious, so you can't blame it on him.
>> Some editors store a BOM without giving notice, others hide such
>> settings somewhere deep in the preferences.
>>
>> Hopefully this problem will completely vanish with native Unicode
>> support in PHP 6.
> That's why you should never use a UTF-8 editor. Of, if you need to,
> ensure that it's saving in ASCII mode.
Rubbish. All my files are saved in UTF-8, which is no BOM by default.
For the most part this means they are the same as ASCII files, but if I
want to add chars like ƒ (curlique-f or whatever it's called), I can do
that.
I got fed up when my email client (written in PHP and JavaScript) kept
displaying chinese as rubbish characters. A decision to use UTF-8
throughout, paying careful attention to the charsets that the received
data said it was using, converting to UTF-8 where appropriate in PHP,
sending the right headers, and doing the right thing on the JS side has
meant that displayed mails look correct.
Windows-generated mails have a habit of lying about the charset they are
using, but that's easy to fix up.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: session question [message #177784 is a reply to message #177783] |
Fri, 20 April 2012 22:23 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <jmsedj$44p$1(at)dont-email(dot)me>,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>> On 4/20/2012 3:13 PM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> IOW, you screwed up and the others here were right.<?php was NOT the
>>>> first thing in your file!
>>>
>>> But this issue is not the most obvious, so you can't blame it on him.
>>> Some editors store a BOM without giving notice, others hide such
>>> settings somewhere deep in the preferences.
>>>
>>> Hopefully this problem will completely vanish with native Unicode
>>> support in PHP 6.
>
>> That's why you should never use a UTF-8 editor. Of, if you need to,
>> ensure that it's saving in ASCII mode.
>
> Rubbish. All my files are saved in UTF-8, which is no BOM by default.
> For the most part this means they are the same as ASCII files, but if I
> want to add chars like ƒ (curlique-f or whatever it's called), I can do
> that.
wiki has this to say:
The Unicode Standard does permit the BOM in UTF-8,[2] but does not
require or recommend its use.[3] Byte order has no meaning in UTF-8[4]
so in UTF-8 the BOM serves only to identify a text stream or file as UTF-8.
>
> I got fed up when my email client (written in PHP and JavaScript) kept
> displaying chinese as rubbish characters. A decision to use UTF-8
> throughout, paying careful attention to the charsets that the received
> data said it was using, converting to UTF-8 where appropriate in PHP,
> sending the right headers, and doing the right thing on the JS side has
> meant that displayed mails look correct.
>
> Windows-generated mails have a habit of lying about the charset they are
> using, but that's easy to fix up.
>
Never found a reliable way to do that..
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: session question [message #177785 is a reply to message #177783] |
Fri, 20 April 2012 22:45 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2012 6:11 PM, Tim Streater wrote:
> In article <jmsedj$44p$1(at)dont-email(dot)me>,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>> On 4/20/2012 3:13 PM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> IOW, you screwed up and the others here were right.<?php was NOT the
>>>> first thing in your file!
>>>
>>> But this issue is not the most obvious, so you can't blame it on him.
>>> Some editors store a BOM without giving notice, others hide such
>>> settings somewhere deep in the preferences.
>>>
>>> Hopefully this problem will completely vanish with native Unicode
>>> support in PHP 6.
>
>> That's why you should never use a UTF-8 editor. Of, if you need to,
>> ensure that it's saving in ASCII mode.
>
> Rubbish. All my files are saved in UTF-8, which is no BOM by default.
> For the most part this means they are the same as ASCII files, but if I
> want to add chars like ƒ (curlique-f or whatever it's called), I can do
> that.
>
Correct. Without the BOM, UTF-8 is the same as ASCII. Just the
extended characters (> 127) can have different meanings - but then ASCII
doesn't define meanings for those, anyway.
> I got fed up when my email client (written in PHP and JavaScript) kept
> displaying chinese as rubbish characters. A decision to use UTF-8
> throughout, paying careful attention to the charsets that the received
> data said it was using, converting to UTF-8 where appropriate in PHP,
> sending the right headers, and doing the right thing on the JS side has
> meant that displayed mails look correct.
>
It's all in how you want to define the extended characters.
> Windows-generated mails have a habit of lying about the charset they are
> using, but that's easy to fix up.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: session question [message #177787 is a reply to message #177786] |
Sat, 21 April 2012 00:28 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser wrote:
> .oO(Tim Streater)
>
>> In article <jmsedj$44p$1(at)dont-email(dot)me>,
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>>
>>> That's why you should never use a UTF-8 editor. Of, if you need to,
>>> ensure that it's saving in ASCII mode.
>> Rubbish. All my files are saved in UTF-8, which is no BOM by default.
>
> But a BOM is still allowed to identify the file as UTF-8. And some
> editors do that, which causes problems in current PHP.
>
mainly microsnot editors of course
> Micha
>
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: session question [message #177795 is a reply to message #177784] |
Sat, 21 April 2012 12:14 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <jmsnke$ste$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> Tim Streater wrote:
>> Windows-generated mails have a habit of lying about the charset they are
>> using, but that's easy to fix up.
>>
> Never found a reliable way to do that..
I display the html-mail by shoving it in an iFrame, and letting the
browser worry about rendering it. But on the fly, and before actually
doing the shoving-in, if I see a <meta> containing ISO-8859-1, I change
that to UTF-8.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: session question [message #177808 is a reply to message #177777] |
Sat, 21 April 2012 22:13 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 4/20/2012 3:36 PM, Tim Streater wrote:
> I Use TextWrangler on a Mac. It, and BBedit, give me the choice to set a
> default of how to save files, in the Prefs. So I choose UTF-8. In fact,
> the authors are so well aware that the BOM is a pain in the dong, that
> you have to explicitly ask for UTF-8,BOM in order to have it. They
> changed the defaults this way a few years back.
>
I use a couple different text editors, and some add it quietly w/o
notice, and some give you the option. It's never been an issue until
this so I never gave it a second thought.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]