Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Matthew Carter <m@ahungry.com>
Newsgroups: comp.lang.php
Subject: Re: parsing print_r() output with preg_match_all()
Date: Wed, 06 Jan 2016 21:48:57 -0500
Organization: Ahungry (http://ahungry.com)
Lines: 48
Message-ID: <87y4c2umsm.fsf@ahungry.com>
References: <568d3dcf$0$23748$e4fe514c@news.xs4all.nl> <87r3huzevd.fsf@bsb.me.uk> <568d6f9c$0$23759$e4fe514c@news.xs4all.nl> <87fuyaza37.fsf@bsb.me.uk> <n6k0a5$od7$1@jstuckle.eternal-september.org> <874meqyvo5.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="7c986cd4736462de309a749b207746fe"; logging-data="23816"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CSY3MyyvRECng4QnQM2GN"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:SOIgeXauAOuGvWX+uEr4sHE2NdQ= sha1:2RhRFrtEqUMfjeRdBpJLAEInwXQ=
Xref: csiph.com comp.lang.php:16123

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 1/6/2016 4:12 PM, Ben Bacarisse wrote:
>>> "R.Wieser" <address@not.available> writes:
>>> 
>>>>> It would be a lot simpler if you could switch to using
>>>>> serialize and unserialize.  Do you need to use print_r
>>>>> for some other reason?
>>>>
>>>> I'm using it to store the array-of-arrays into a file in human-readable
>>>> format.  I intend to parse this file using another program, posibly alter
>>>> some info and write it back.
>>> 
>>> Well the output of serialise is human-readable (just about).  It's not
>>> ideal, but then parsing print_r output is not ideal either.  In fact,
>>> it's not even possible in all cases though you may be able to make
>>> enough assumptions about what's in the strings to get away with it.
>>> 
>>> But I would seriously consider some other plan.  If it's always going to
>>> be just an array of arrays of strings, you could design your own
>>> human-readable format whilst making it (much) easier to read back.
>>> 
>>> <snip>
>>> 
>>
>> I agree - I wouldn't try to parse the output of print_r().  It's not
>> made to be parsed, and there is no documentation on the output, AFAICR,
>> which means the format could change with a different release of PHP.
>>
>> XML comes to mind. Human readable and made to be easily parsed.
>
> Feels like overkill to me but it's hard to know what's really going on
> here.  There are much simpler formats for representing an array of
> arrays of strings which might pay off in this simple case.
>
> The OP might also look into JSON and var_export+eval (the latter needing
> care unless the file has the same status as code) but these are all
> rather "noisy", like XML.

JSON is pretty reasonable to read if line breaks/indentation is added
(it has the benefit of easily being encoded/decoded as well, even if
line breaks are present).

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com