Hi everyone,

In a project I am working on, the goal is to read an iCal file from another server using an URL. Previously I was using file_get_contents() to do this, but that was back when the file was just on the same computer I'm working on.

Now I am trying to read the iCal file from another server and I'm using stream_get_contents() to do that. It reads the file and everything is okay, but when I parse the file, there are a lot of Warnings/Notices and it has to do with line breaks. Previously the linebreaks that I was using to help break down and parse this file was \r\n. That worked when the file was coming from my own UNIX-based computer. But when I use stream_get_contents(), what happens to the linebreaks? What type of linebreaks are there in a stream_get_contents()-returned string?

Does anyone know? I've tried a few different linebreaks to see if it would fix the problem, but I can't figure out what linebreaks are returned in the string. Thanks,

Andy

PS: Here is an example of what the iCal file looks like:

BEGIN:VEVENT
LOCATION:No School K-12
DTSTAMP:20060307T212128Z
UID:BC03D9B5-86D7-48CD-8B83-C54C64A13479-4DDA79F2-DE1A-40FD-86A7-BA879BF
 EE990
SEQUENCE:6
DTSTART;VALUE=DATE:20070115
SUMMARY:Non-Contract Day
DTEND;VALUE=DATE:20070116
DESCRIPTION:Martin Luther King Day
END:VEVENT

    I don't think the *_get_contents() functions are changing any of the line endings. It's likely a difference in how the files were created, saved, and/or transfered. MS-DOS/Windows likes to use "\r\n" as the line breaks, whereas UNIX type systems just use "\n". Also, some FTP programs will convert line breaks to the appropriate type for the target system, if the applicable option for that FTP tool is active.

      The thing is though, while the iCal file is on two different computers, the systems are using the same UNIX-based OS. So I wouldn't think that it's a an OS difference for this. I still think these functions use different line breaks or at least affect line breaks in a file. I am just trying to find out what linebreaks are in it.

        Here is an example of the output I am getting:

        This is how it should look when I parse the iCal file and put it into an array:

        [277] => BEGIN:VEVENT
[278] => LOCATION:No School K-12
[279] => DTSTAMP:20060307T212128Z
[280] => UID:BC03D9B5-86D7-48CD-8B83-C54C64A13479-0C47C4D9-B8F0-412D-BDA0-554E708E1648
[281] => SEQUENCE:6
[282] => DTSTART;VALUE=DATE:20070115
[283] => SUMMARY:Non-Contract Day
[284] => DTEND;VALUE=DATE:20070116
[285] => DESCRIPTION:Martin Luther King Day
[286] => END:VEVENT

        And this is how it looks when I'm getting the file remotely via the URL: (See, the UID line needs to not be broken up at the bottom, it all needs to be on one line.)

            [277] => BEGIN:VEVENT
    [278] => LOCATION:No School K-12
    [279] => DTSTAMP:20060307T212128Z
    [280] => UID:BC03D9B5-86D7-48CD-8B83-C54C64A13479-4DDA79F2-DE1A-40FD-86A7-BA879BF
EE990
    [281] => SEQUENCE:6
    [282] => DTSTART;VALUE=DATE:20070115
    [283] => SUMMARY:Non-Contract Day
    [284] => DTEND;VALUE=DATE:20070116
    [285] => DESCRIPTION:Martin Luther King Day
    [286] => END:VEVENT

          Ah... okay.

          Here is what I think was happening:

          I was using the same preg_replace regex as before but it wasn't working for some reason. The problem was that there was a tiny whitespace character being added at the end of each line when the iCal file was being parsed (I parse it key/value.) So all I had to do was add trim() before using each value before using it.

          oops.

            Write a Reply...