Lines not delimited by CRLF sequence near line # 1

Question

I'm having an issue getting the line folding to work the way it's specified. I'm obviously misunderstanding something about the documentation, so I was hoping I could get some help. The validator at https://icalendar.org/validator.html is saying

Lines not delimited by CRLF sequence near line # 1
Reference: RFC 5545 3.1. Content Lines

This is my function to generate the .ics files for download:

public function getCalendarFile($event) {
    header("Content-Type: text/Calendar; charset=utf-8");
    header("Content-Disposition: attachment; filename="ExampleFile.ics");
    $icsFile = "BEGIN:VCALENDAR\r\n";
    $icsFile .= "VERSION:2.0\r\n";
    $icsFile .= "PRODID:Example Event" . $event->name . "\r\n";
    $icsFile .= "METHOD:PUBLISH\r\n";
    $icsFile .= "BEGIN:VEVENT\r\n";
    $icsFile .= "UID:". $event->name . gmdate("Ymd\THis\Z", strtotime(Carbon::now())) . "\r\n";
    $icsFile .= "DTSTAMP:" . gmdate("Ymd\THis\Z", strtotime(Carbon::now())) . "\r\n";
    $icsFile .= "DTSTART:" . gmdate("Ymd\THis\Z", strtotime($event->begin)) . "\r\n";
    $icsFile .= "DTEND:" . gmdate("Ymd\THis\Z", strtotime($event->end)) . "\r\n";
    $icsFile .= "LOCATION:" . strip_tags($event->location) . "\r\n";
    $icsFile .= "SUMMARY:" . $event->name . "\r\n";
    $icsFile .= "DESCRIPTION:" . $this->foldCalendarDescription(strip_tags($event->description)) . "\r\n";
    $icsFile .= "END:VEVENT\r\n";
    $icsFile .= "END:VCALENDAR\r\n";
    echo $icsFile;
}

public function foldCalendarDescription($description) {
    return wordwrap($description, 75, "\r\n\t", TRUE);
}

I'm not sure if it has something to do with strip_tags possibly? The event description is stored as a wysiwyg html input. But the issue says with line # 1 and line # 1 looks fine to me.

Does this answer your question? [Encoding newlines in iCal files](https://stackoverflow.com/questions/666929/encoding-newlines-in-ical-files) — kmoser, Nov 20 '20 at 06:32
See https://tools.ietf.org/html/rfc5545#section-3.1 It is not just the CRLF, it is the 75 octets AND the singe linear space. "a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white-space character (i.e., SPACE or HTAB)" — anmari, Nov 22 '20 at 05:35

score 2 · Answer 1 · answered Nov 20 '20 at 06:48

2

Here's a wrapper for ICAL strings that works for me:

function format_ical_string( $s ) {
    $r = wordwrap(
        preg_replace(
            array( '/,/', '/;/', '/[\r\n]/' ),
            array( '\,', '\;', '\n' ),
            $s
        ), 73, "\n", TRUE
    );

    // Indent all lines but first:
    $r = preg_replace( '/\n/', "\n  ", $r );

    return $r;
}

answered Nov 20 '20 at 06:48

kmoser

8,780
3
24
40

Would this be used just for the Description or for the whole string after it's made? – Nov 20 '20 at 16:53
Ok, so I'm still getting the same error when I pass it into a validator using this. But the full description shows correctly now. So I guess it's fixed..? Thanks for the help! – Nov 20 '20 at 17:25
I use it to format both the summary and description text, since I believe no ICAL line may exceed 75 chars. I'm not sure if that includes the "DESCRIPTION: " and "SUMMARY: " prefixes, though. – kmoser Nov 20 '20 at 21:15
If you can provide an example of your generated .ics file, we may be able to help. In any case, if my answer helped you, please consider either upvoting it or marking it as the accepted answer. – kmoser Nov 20 '20 at 21:15
People on the internets say otherwise, but `wordwrap` is really sufficient here IMHO. For multi-byte characters, you just get less *characters* on a line, but the number of *bytes* is what is limited by the spec. It is not a problem to have *less* than 75 bytes on a line, and wordwrap enforces that. I would set cut_long_words to false though. Chances are that you won't have words longer than 75 bytes, but because `wordwrap` isn't multi-byte safe, this option might break on multi-byte character boundaries, something you don't want to happen. – zmippie Feb 19 '22 at 12:04

zmippie · Answer 2 · 2022-02-19T13:52:46.473

As I wrote in the comment beneath kmoser's answer, people seem to be really hard pressed to get exactly 75 bytes on a line and create very convoluted code to do that. But why not just sometimes less than 75 bytes? A simple wordwrap will give you that because it just looks for whitespace to break and is not multi-byte aware. You'll possibly have a few more linebreaks in the iCal object code than strictly neccessary, but does that matter? This is why I upvoted kmoser's answer. It's a nice and simple solution.

I've tried to create an even simpler and faster version of kmoser's answer:

function format_ical_string( $str ) {

    $str = str_replace(
        [ "\r\n", '\\', ',', ';', "\n" ], // replacement order is important
        [ "\n", '\\\\', '\,', '\;', '\n' ], $str );

    return wordwrap( $str, 73, "\n ", false );
}

The replacements (just a str_replace, because nothing fancy is needed here) are:

replace CRLF's with just LF's
replace literal backslashes with escaped backslashes
escape comma's
escape semicolons
replace newlines with a literal \n (per rfc5545)

Then wordwrap with a LF + space (per rfc5545).

After this, strictly you should replace all LF's with CRLF's (rfc5545 line ending). I tend to format the entire iCal object with just LF's, and only at the very end replace all LF's with CRLF's to make the result compliant. This saves me the hassle of repeatedly inserting these Windows line endings (who uses those these days?) during the composition of my iCal objects.

It is unclear from rfc5545 if the property name itself is counted in the 75 bytes line limit, as in https://www.rfc-editor.org/rfc/rfc5545#section-3.1:

Lines of text SHOULD NOT be longer than 75 octets, excluding the line break.

But just to be sure, I feed the property name to the function, as in:

$line = format_ical_string( 'SUMMARY:Really long text here' );

IMPORTANT: my function above will fail on single words (!) that are longer than 75 bytes. I'm not sure how common that is. If you have an 18-character word completely made of 4-byte characters, you'd be at the limit. This seems very unlikely to me.

Lines not delimited by CRLF sequence near line # 1

2 Answers2