php-general Digest 6 Jul 2006 16:54:47 -0000 Issue 4225
Topics (messages 239158 through 239179):
"page expired" - problem
239158 by: cajbecu
PROBLEM WITH MAIL FUNCTION
239159 by: Juanjo Pascual
239161 by: Martin Marques
Re: Recursing sessions?
239160 by: Jochem Maas
239170 by: markw.mohawksoft.com
Re: require_once and E_WARNING?
239162 by: Martin Marques
239163 by: chris smith
239164 by: Jochem Maas
239167 by: Martin Marques
239175 by: KermodeBear
Re: uploading and extracting zip files
239165 by: Jochem Maas
Running php5 with Zeus and fcgi
239166 by: James Nunnerley
239168 by: Owen Garrett
Re: Calculations
239169 by: Jochem Maas
239171 by: John Nichel
239172 by: tg-php.gryffyndevelopment.com
239173 by: tedd
239174 by: tedd
239176 by: Robert Cummings
239177 by: tedd
url obfuscation
239178 by: Dan McCullough
Problem using fgetcsv()
239179 by: Don
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Hello there,
I have an website, with a lot of buttons with onClick statement.
(onclick="document.location='page.php'") The problem is that this page
is result of a search criteria (for example filtering the products with
POST method) .. Then I chose a product, click on button, and when I
click back button on the browser (Internet Explorer) it displays me:
page expired. (There are some momments when i must click twice to go
back, and i don`t know why.... in firefox work perfect.)
Did you had similar problems in past?
Thanks in advance,
cajbecu
--- End Message ---
--- Begin Message ---
Hello,
I have a problem with the mail function when I send a mail with acents
or Ñ in the subject. When I receive the mail this caracters have been
replaced by X.
I'm using the mail function in this way:
mail([EMAIL PROTECTED], 'Consulta Señalítica desde la página web',
'<strong>Hola, esto es una prueba<strong>','From: [EMAIL PROTECTED]' . "\r\n"
. 'Content-type: text/html; charset=iso-8859-1' . "\r\n");
The mail subject when I receive the message is like this: Consulta
SeXalXtica desde la pXgina web
¿How can I solve this problem?
--- End Message ---
--- Begin Message ---
On Thu, 6 Jul 2006, Juanjo Pascual wrote:
Hello,
I have a problem with the mail function when I send a mail with acents or Ñ
in the subject. When I receive the mail this caracters have been replaced by
X.
I'm using the mail function in this way:
mail([EMAIL PROTECTED], 'Consulta Señalítica desde la página web', '<strong>Hola,
esto es una prueba<strong>','From: [EMAIL PROTECTED]' . "\r\n" . 'Content-type:
text/html; charset=iso-8859-1' . "\r\n");
Worked great for me. But I would try with something more like this:
mail("mimail.midom.com","Consulta Señalítica desde la página web",
"<strong>Hola, esto es una prueba<strong>",
"From: [EMAIL PROTECTED] \n Content-type: text/html; \n
charset=iso-8859-1 \n");
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
[email protected] wrote:
>> On Sat, July 1, 2006 5:30 pm, Mark wrote:
>>> If the frames do any sort of processing on the session information, as
>>> is
>>> the case with squirrelmail, the last session to exit will overwrite
>>> all the
>>> changes made by prior frames. This can corrupt session information or
>>> lose
>>> versions of information.
>>>
>>> It is a HUGE problem that I don't see ANYONE addressing.
>> Ah.
>>
>> Now I know which question you are asking...
>>
>> The built-in PHP session handler handles this by LOCKING the session
>> for writing until it is closed and done for each request.
>>
>> The simplistic example for user-defined handling sessions in the
>> manual does not, in fact, address this directly.
>>
>> The User Contributed Notes, last I checked, did have some rather sarky
>> comments about this issue, and some suggestions for how to fix it.
>>
>> If you are using a database, for example, locking via some mechanism
>> in the DB is probably a viable solution. Wrapping it all in a
>> Transaction is probably overkill, for example, but would work.
>>
>> Of course, the simplest solution remains: Don't use frames.
>
> In the world of <sarcasm>"Web 2.0"</sarcasm> This problem is only going to
> get worse.
>
> I think I have a solution, MCache, which is based on MSession, but I don't
> see the core PHP group liking it too much.
which every solution is used some kind of polling/locking mechanism will have
to be used. I can't comment on whether the 'locking' loop you showed on the
list is any good in practice because my C sucks and my understanding of networks
is in the same ballpark but from what I gather your solution is correct (and
required)
in principle.
with SquirrelMail you don't want to change the code but in your own
applications that
have the same issue you can mitigate the waiting caused by locking by setting
session
data as early as possible, likewise grabbing all 'read-only' data from the
sesssion
and then calling session_write_close() at the earliest opportunity (making sure
your
implementation frees the lock at the stage) so that concurrent requests don't
have
to actually waiting until the previous request is complete (but only wait just
until
a previous request is done with the session mechanism.
>
--- End Message ---
--- Begin Message ---
> [email protected] wrote:
>>> On Sat, July 1, 2006 5:30 pm, Mark wrote:
>>>> If the frames do any sort of processing on the session information, as
>>>> is
>>>> the case with squirrelmail, the last session to exit will overwrite
>>>> all the
>>>> changes made by prior frames. This can corrupt session information or
>>>> lose
>>>> versions of information.
>>>>
>>>> It is a HUGE problem that I don't see ANYONE addressing.
>>> Ah.
>>>
>>> Now I know which question you are asking...
>>>
>>> The built-in PHP session handler handles this by LOCKING the session
>>> for writing until it is closed and done for each request.
>>>
>>> The simplistic example for user-defined handling sessions in the
>>> manual does not, in fact, address this directly.
>>>
>>> The User Contributed Notes, last I checked, did have some rather sarky
>>> comments about this issue, and some suggestions for how to fix it.
>>>
>>> If you are using a database, for example, locking via some mechanism
>>> in the DB is probably a viable solution. Wrapping it all in a
>>> Transaction is probably overkill, for example, but would work.
>>>
>>> Of course, the simplest solution remains: Don't use frames.
>>
>> In the world of <sarcasm>"Web 2.0"</sarcasm> This problem is only going
>> to
>> get worse.
>>
>> I think I have a solution, MCache, which is based on MSession, but I
>> don't
>> see the core PHP group liking it too much.
>
> which every solution is used some kind of polling/locking mechanism will
> have
> to be used. I can't comment on whether the 'locking' loop you showed on
> the
> list is any good in practice because my C sucks and my understanding of
> networks
> is in the same ballpark but from what I gather your solution is correct
> (and required)
> in principle.
I am concerned about this problem for a few reasons. I suspected it was a
problem for a while, but never really gave it much thought. I mean, geez,
I've worked on a lot of parallel systems and just didn't think about it.
Maybe I give myself too much credit, but if I miss the clues, I'm sure
that a ton of other qualified people have as well. In fact, I see more
than a few session management system that take proper serialization for
granted.
In the old days you could, more or less, rely on a single
browser/connection. With frames (not that frames are new) and AJAX
methodologies, the nature of the problem is really a distributed locking
problem.
On top of that, with AJAX and more true "web applications" make this a
more and more serious issue.
>
> with SquirrelMail you don't want to change the code but in your own
> applications that
> have the same issue you can mitigate the waiting caused by locking by
> setting session
> data as early as possible, likewise grabbing all 'read-only' data from the
> sesssion
> and then calling session_write_close() at the earliest opportunity (making
> sure your
> implementation frees the lock at the stage) so that concurrent requests
> don't have
> to actually waiting until the previous request is complete (but only wait
> just until
> a previous request is done with the session mechanism.
Coding around the problem is not solving the problem. If you force
yourself to have to deal with concurrency every time you get data, you are
creating a lot of complexity solving the problem in the wrong place. The
data storage system should deal with it.
>
>
>>
>
--- End Message ---
--- Begin Message ---
On Wed, 5 Jul 2006, [EMAIL PROTECTED] wrote:
Hello all,
According to the PHP Manual, when require or require_once failes, an
E_ERROR is triggered: "require() and include() are identical in every way
except how they handle failure. include() produces a Warning while
require() results in a Fatal Error." (With 'Fatal Error' being a link to
E_ERROR).
Thing is, when using a custom error handler via set_error_handler(), it
appears to be triggering an E_WARNING, not an E_ERROR. Using PHP 5.1.4
under Linux.
There are one of three possibilities: I am suffering from a lapse in
lucidity (common), the manual is wrong (possible), or PHP is broken
somehow (unlikely). I'm guessing it's the first, but what am I doing
wrong? I'd like to get a second opinion before submitting a bug. I
searched bugs.php.net but was unable to find anything relevant for 5.1.4.
Code:
function default_error_handler($code, $error, $file, $line) {
switch ($code) {
case E_ERROR:
die ("Error: $error");
case E_WARNING:
die("Warning: $error");
default:
die("Something else entirely: $error");
}
}
What happens if you put breaks after the die()? This shouldn't be
necesary, but it wouldn't hurt to try. ;-)
As I see in the example of the PHP manual, a break is put even after an
exit(1) call.
set_error_handler('default_error_handler');
require('This file does not exist. At least not here!');
Have you tried this handler with something more fatal, like a missing
semi-colon or a } missmatch?
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
On 7/6/06, Martin Marques <[email protected]> wrote:
On Wed, 5 Jul 2006, [EMAIL PROTECTED] wrote:
> Hello all,
>
> According to the PHP Manual, when require or require_once failes, an
> E_ERROR is triggered: "require() and include() are identical in every way
> except how they handle failure. include() produces a Warning while
> require() results in a Fatal Error." (With 'Fatal Error' being a link to
> E_ERROR).
>
> Thing is, when using a custom error handler via set_error_handler(), it
> appears to be triggering an E_WARNING, not an E_ERROR. Using PHP 5.1.4
> under Linux.
>
> There are one of three possibilities: I am suffering from a lapse in
> lucidity (common), the manual is wrong (possible), or PHP is broken
> somehow (unlikely). I'm guessing it's the first, but what am I doing
> wrong? I'd like to get a second opinion before submitting a bug. I
> searched bugs.php.net but was unable to find anything relevant for 5.1.4.
>
> Code:
> function default_error_handler($code, $error, $file, $line) {
> switch ($code) {
> case E_ERROR:
> die ("Error: $error");
> case E_WARNING:
> die("Warning: $error");
> default:
> die("Something else entirely: $error");
> }
> }
What happens if you put breaks after the die()? This shouldn't be
necesary, but it wouldn't hurt to try. ;-)
As I see in the example of the PHP manual, a break is put even after an
exit(1) call.
> set_error_handler('default_error_handler');
> require('This file does not exist. At least not here!');
Have you tried this handler with something more fatal, like a missing
semi-colon or a } missmatch?
That will cause a parse error and the script won't even run.
--
Postgresql & php tutorials
http://www.designmagick.com/
--- End Message ---
--- Begin Message ---
chris smith wrote:
> On 7/6/06, Martin Marques <[email protected]> wrote:
>> On Wed, 5 Jul 2006, [EMAIL PROTECTED] wrote:
>>
>> > Hello all,
>> >
>> > According to the PHP Manual, when require or require_once failes, an
>> > E_ERROR is triggered: "require() and include() are identical in
>> every way
>> > except how they handle failure. include() produces a Warning while
>> > require() results in a Fatal Error." (With 'Fatal Error' being a
>> link to
>> > E_ERROR).
>> >
>> > Thing is, when using a custom error handler via set_error_handler(), it
>> > appears to be triggering an E_WARNING, not an E_ERROR. Using PHP 5.1.4
>> > under Linux.
>> >
>> > There are one of three possibilities: I am suffering from a lapse in
>> > lucidity (common), the manual is wrong (possible), or PHP is broken
>> > somehow (unlikely). I'm guessing it's the first, but what am I doing
>> > wrong? I'd like to get a second opinion before submitting a bug. I
>> > searched bugs.php.net but was unable to find anything relevant for
>> 5.1.4.
>> >
>> > Code:
>> > function default_error_handler($code, $error, $file, $line) {
>> > switch ($code) {
>> > case E_ERROR:
>> > die ("Error: $error");
>> > case E_WARNING:
>> > die("Warning: $error");
>> > default:
>> > die("Something else entirely: $error");
>> > }
>> > }
>>
>> What happens if you put breaks after the die()? This shouldn't be
>> necesary, but it wouldn't hurt to try. ;-)
>>
>> As I see in the example of the PHP manual, a break is put even after an
>> exit(1) call.
>>
>> > set_error_handler('default_error_handler');
>> > require('This file does not exist. At least not here!');
>>
>> Have you tried this handler with something more fatal, like a missing
>> semi-colon or a } missmatch?
>
> That will cause a parse error and the script won't even run.
try it with a call to an undefined function e.g.:
$foo = thisFunctionDoesNotExistAtLeastItHadBetterNot();
>
--- End Message ---
--- Begin Message ---
On Thu, 6 Jul 2006, chris smith wrote:
Have you tried this handler with something more fatal, like a missing
semi-colon or a } missmatch?
That will cause a parse error and the script won't even run.
You're right. My wrong. :-(
--
21:50:04 up 2 days, 9:07, 0 users, load average: 0.92, 0.37, 0.18
---------------------------------------------------------
Lic. Martín Marqués | SELECT 'mmarques' ||
Centro de Telemática | '@' || 'unl.edu.ar';
Universidad Nacional | DBA, Programador,
del Litoral | Administrador
---------------------------------------------------------
--- End Message ---
--- Begin Message ---
chris smith wrote:
> try it with a call to an undefined function e.g.:
> $foo = thisFunctionDoesNotExistAtLeastItHadBetterNot();
When this is done, the error handler doesn't get called at all, and the
script simply dies with an error message (which could be a bug as well, but
might also be considered a 'parse error' even if it happens at runtime; I
doubt they would fix it).
I read through the set_error_handler() documentation again though, and I
found that: " The following error types cannot be handled with a user
defined function: E_ERROR[...]"
So, I'm guessing that the require() functions raise an E_WARNING before the
E_ERROR. Seems odd. Perhaps what happens "under the hood" is that require()
calls include(), which would raise an E_WARNING when it fails, then the
require() code checks the result of include() and if it failed then it
raises the E_ERROR.
It pays to RTFM more closely, it seems. (o; My bad.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Chris wrote:
> nicolas figaro wrote:
>> Chris a écrit :
>>> Schalk wrote:
>>>> Greetings All,
>>>>
>>>> Can someone please point me to a tutorial or open source 'library'
>>>> that will explain how one can upload a .zip file and then extract
>>>> it's contents and store this on the server and/or database using PHP.
>>>
>>> This will unzip a file:
>>>
>>> http://pear.php.net/package/Archive_Zip
>>>
>>> As for uploading, you'll need something else for that (I don't think
>>> there's something to do it *all* for you but I could be wrong).
>>>
>> move_uploaded_file perhaps ?
>> http://www.php.net/manual/en/function.move-uploaded-file.php
>
> That will definitely do it, I think the OP wanted something already
> built to do everything for him with no work.
just google for 'magicwand.php' ;-)
>
--- End Message ---
--- Begin Message ---
Does anyone have any experiences of running php5 as a fcgi and Zeus server?
And in particular getting "Bad Gateway" errors.
We are tempted to report it as a fault/bug, but have looked around the net
(including bugs.php.net) it would seem that there's already a reported bug,
but it's a little unclear as to whether it's fixed?
Cheers
Nunners
--- End Message ---
--- Begin Message ---
Hi Nunners,
Take a look at your ZWS error log (/usr/local/zeus/web/log/errors). You'll
be getting the 'Bad Gateway' error because the php fastcgi has crashed,
cannot be started, or ZWS cannot talk to it. There should be some clues in
there.
For example, if you've copied the php binary from a different machine,
perhaps some of the shared libraries it depends upon are missing? This is
quite common if you've compiled in support for additional capabilities, such
as database support.
Try running the php binary manually, with the -v flag for example, to see if
it can run OK.
If this does not help, drop a line to Zeus' technical support team. Let
them know of any errors in the error log, and whether this happens on every
php request, or just intermittently.
cheers,
Owen
--
View this message in context:
http://www.nabble.com/Running-php5-with-Zeus-and-fcgi-tf1900215.html#a5198569
Sent from the PHP - General forum at Nabble.com.
--- End Message ---
--- Begin Message ---
tedd wrote:
> At 11:27 AM +0300 6/28/06, Robin Vickery wrote:
>> On 28/06/06, tedd <[EMAIL PROTECTED]> wrote:
>>> At 2:30 PM -0400 6/27/06, Kristen G. Thorson wrote:
>>>> http://www.php.net/manual/en/language.operators.bitwise.php
>>>>
>>> I wonder why that's true for php when it's common to use ^ in many other
>>> languages
>>> for powers?
>> Perl: ^ is the bitwise xor operator
>> Python: ^ is the bitwise xor operator
>> C: ^ is the bitwise xor operator
>> Java: ^ is the bitwise xor operator
>> ...
>>
>> -robin
>
> Oh well, that settles it then. :-)
I guess the chinese-straw-hat operator has had it's meaning
changed by general consensus since the days when you were
programming with rocks ;-)
>
> tedd
--- End Message ---
--- Begin Message ---
Jochem Maas wrote:
tedd wrote:
At 11:27 AM +0300 6/28/06, Robin Vickery wrote:
On 28/06/06, tedd <[EMAIL PROTECTED]> wrote:
At 2:30 PM -0400 6/27/06, Kristen G. Thorson wrote:
http://www.php.net/manual/en/language.operators.bitwise.php
I wonder why that's true for php when it's common to use ^ in many other
languages
for powers?
Perl: ^ is the bitwise xor operator
Python: ^ is the bitwise xor operator
C: ^ is the bitwise xor operator
Java: ^ is the bitwise xor operator
...
-robin
Oh well, that settles it then. :-)
I guess the chinese-straw-hat operator has had it's meaning
changed by general consensus since the days when you were
programming with rocks ;-)
Pffft, kids. Rocks weren't even invented in my day. We had to use dirt.
--
John C. Nichel IV
Programmer/System Admin (ÜberGeek)
Dot Com Holdings of Buffalo
716.856.9675
[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
Best "proving I'm old" line ever had to have been "I *named* dirt!".. forget
where I saw that. Had to share :)
-TG
"Top posting is for people who remember the conversation and don't care to see
it again" :)
= = = Original message = = =
Jochem Maas wrote:
> tedd wrote:
>> At 11:27 AM +0300 6/28/06, Robin Vickery wrote:
>>> On 28/06/06, tedd <[EMAIL PROTECTED]> wrote:
>>>> At 2:30 PM -0400 6/27/06, Kristen G. Thorson wrote:
>>>>> http://www.php.net/manual/en/language.operators.bitwise.php
>>>>>
>>>> I wonder why that's true for php when it's common to use ^ in many other
>>>> languages
>>>> for powers?
>>> Perl: ^ is the bitwise xor operator
>>> Python: ^ is the bitwise xor operator
>>> C: ^ is the bitwise xor operator
>>> Java: ^ is the bitwise xor operator
>>> ...
>>>
>>> -robin
>> Oh well, that settles it then. :-)
>
> I guess the chinese-straw-hat operator has had it's meaning
> changed by general consensus since the days when you were
> programming with rocks ;-)
>
Pffft, kids. Rocks weren't even invented in my day. We had to use dirt.
--
John C. Nichel IV
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
At 2:36 PM +0200 7/6/06, Jochem Maas wrote:
>tedd wrote:
>> At 11:27 AM +0300 6/28/06, Robin Vickery wrote:
>>> On 28/06/06, tedd <[EMAIL PROTECTED]> wrote:
>>>> At 2:30 PM -0400 6/27/06, Kristen G. Thorson wrote:
>>>>> http://www.php.net/manual/en/language.operators.bitwise.php
>>>>>
>>>> I wonder why that's true for php when it's common to use ^ in many other
>>>> languages
>>>> for powers?
> >> Perl: ^ is the bitwise xor operator
>>> Python: ^ is the bitwise xor operator
>>> C: ^ is the bitwise xor operator
>>> Java: ^ is the bitwise xor operator
>>> ...
>>>
>>> -robin
>>
>> Oh well, that settles it then. :-)
>
>I guess the chinese-straw-hat operator has had it's meaning
>changed by general consensus since the days when you were
>programming with rocks ;-)
That was an old thread -- are you finally getting to it?
You're falling behind in your reading. :-)
tedd
PS: ^ was used for other things other than a bitwise xor operator as portions
of this thread has shown. I just don't remember them -- of course, I don't
remember what I had for breakfast yesterday either.
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 8:45 AM -0400 7/6/06, John Nichel wrote:
>Jochem Maas wrote:
>>tedd wrote:
>>>At 11:27 AM +0300 6/28/06, Robin Vickery wrote:
>>>>On 28/06/06, tedd <[EMAIL PROTECTED]> wrote:
>>>>>At 2:30 PM -0400 6/27/06, Kristen G. Thorson wrote:
>>>>>>http://www.php.net/manual/en/language.operators.bitwise.php
>>>>>>
>>>>>I wonder why that's true for php when it's common to use ^ in many other
>>>>>languages
>>>>>for powers?
>>>>Perl: ^ is the bitwise xor operator
>>>>Python: ^ is the bitwise xor operator
>>>>C: ^ is the bitwise xor operator
>>>>Java: ^ is the bitwise xor operator
>>>>...
>>>>
>>>>-robin
>>>Oh well, that settles it then. :-)
>>
>>I guess the chinese-straw-hat operator has had it's meaning
>>changed by general consensus since the days when you were
>>programming with rocks ;-)
>>
>
>Pffft, kids. Rocks weren't even invented in my day. We had to use dirt.
One more plagiarized joke like that and you're going into my kill file. ;-)
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On Thu, 2006-07-06 at 08:45, John Nichel wrote:
> Jochem Maas wrote:
> > tedd wrote:
> >> At 11:27 AM +0300 6/28/06, Robin Vickery wrote:
> >>> On 28/06/06, tedd <[EMAIL PROTECTED]> wrote:
> >>>> At 2:30 PM -0400 6/27/06, Kristen G. Thorson wrote:
> >>>>> http://www.php.net/manual/en/language.operators.bitwise.php
> >>>>>
> >>>> I wonder why that's true for php when it's common to use ^ in many other
> >>>> languages
> >>>> for powers?
> >>> Perl: ^ is the bitwise xor operator
> >>> Python: ^ is the bitwise xor operator
> >>> C: ^ is the bitwise xor operator
> >>> Java: ^ is the bitwise xor operator
> >>> ...
> >>>
> >>> -robin
> >> Oh well, that settles it then. :-)
> >
> > I guess the chinese-straw-hat operator has had it's meaning
> > changed by general consensus since the days when you were
> > programming with rocks ;-)
> >
>
> Pffft, kids. Rocks weren't even invented in my day. We had to use dirt.
Rock predates dirt.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
At 12:32 PM -0400 7/6/06, Robert Cummings wrote:
>On Thu, 2006-07-06 at 08:45, John Nichel wrote:
> > Jochem Maas wrote:
> > >
>> > I guess the chinese-straw-hat operator has had it's meaning
>> > changed by general consensus since the days when you were
>> > programming with rocks ;-)
>> >
>>
>> Pffft, kids. Rocks weren't even invented in my day. We had to use dirt.
>
>Rock predates dirt.
>
>Cheers,
>Rob.
Rob:
You're absolutely right -- I should have caught that. I'm so used to him being
right all the time, that it didn't enter my mind that he wasn't.
Yeah, John -- dirt comes from rocks -- so there. :-p
:-) <-- note happy face -- no need to threaten me with your kill file. :-)
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Looking for a good way to obfuscation the name value pairs in a URL,
so it might be something like
http://www.domain.com/page=fjdsaflkjdsafkfjdsakfjdsalkfjsda983dsf or
something like that, I was looking at base64_encode, but was wondering
what others might do or use. It doesnt have to be super secure, but I
would still like the information to not be really visable.
--- End Message ---
--- Begin Message ---
|
Hi,
I have a CSV file, comma
delimited with the data enclosed by double quotes.
I am using the fgetcsv()
function to read and into an array and update a database. It works great
except for the odd record. After investigating, I have ascertained that it is
due to a backslash character in the data which fgetcsv() cannot parse
properly. I don;t see anyway around this using fgetcsv(). Has anyone
written a custom routine for this?
Code
Snippet
-------------------
$vvFile
= 'myfile.csv';
$fph = fopen($vvFile,"r")
if ($fph)
{
while
(($data = "" !== FALSE) {M
// Insert fields from array '$data' to my MySQL
database - will fail on bad data
}
fclose($fph);
}
Sample
Data
------------------
"123456","135679048754","7154904875","HD INDOOR INSECT KILR 33
OZ 6","EA"
"654321","246809052607","7154905260","59-2 CACTUS &
SUCCULENTS \","EA"
Note: The first line is
OK; the second will fail due to the backslash in the fourth
field
When I print the array
contents, here is what I see. For the second line, it is not parsing the
row properly and joining the fourth and fifth fields. When I edit and
remove the backslash, all is OK.
first line:
data[0] =
123456
data[1] = 135679048754
data[2] = 7154904875
data[3] = HD INDOOR
INSECT KILR 33 OZ 6
data[4] =
EA
second line:
data[0] =
654321
data[1] = 246809052607
data[2] = 7154905260
data[3] = 59-2 CACTUS
& SUCCULENTS ",EA
data[4]
=
|
--- End Message ---
