The iCalendar Spec Says 75 Octets, Not 75 Characters

The iCalendar specification specifies that lines of text SHOULD NOT exceed 75 octets, not 75 characters. This distinction is important because, in ASCII, the two metrics are equivalent. However, in Japanese, which uses UTF-8 encoding, a single character can take up to three bytes.

For instance, the localized summary "code-davinci-001 終了 (OpenAI)" is 30 characters but takes up 49 octets. When a line exceeds 75 octets, the parser rejects it, even though it is well within the 75 character limit. This discrepancy is the source of the issue.

The common fix of counting bytes instead of characters introduces another problem. Slicing a UTF-8 buffer at a fixed offset can cut through the middle of a character, resulting in half a codepoint on one line and the other half on the next. This can cause the parser to replace the cut character with U+FFFD (the replacement character) or abort the file altogether.

The correct approach is to count bytes but take character boundaries into account. The function "foldLine" implements this approach. It iterates over each character in the line, encoding it using TextEncoder and checking if adding the character would exceed the 75-octet limit. If it would, the current string is pushed to the output and a new string is started, with the limit reduced to 74 for the first line due to the leading space used as a continuation marker.

The final piece of this solution is ensuring that the line feed character (\r\n) is used, as specified by RFC 5545. The function also avoids treating the UID as a display string, a requirement that arises when dealing with an .ics feed in multiple languages. The UID should be keyed on the entity, not the presentation, to prevent multiple entries for the same event in a subscribed calendar.