{
  "id": 3728872,
  "title": "The iCalendar Spec Says 75 Octets, Not 75 Characters",
  "url": "https://urgent.news/2026/08/27/the-icalendar-spec-says-75-octets-not-75-characters",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-27T12:00:00.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ai_changewatch/the-icalendar-spec-says-75-octets-not-75-characters-5cn8"
  },
  "original_language": "en",
  "account": "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.\n\nFor 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.",
  "summary": "I run AI Change Watch , a small independent project that crawls what 15 AI vendors publish about their own models — deprecation tables, lifecycle pages, pricing and SDK releases — and records every time one of them changes. One of the things it publishes is a subscribable calendar: every announced model shutdown, as .ics , so a date the vendor moves updates in your calendar instead of in a…",
  "key_points": [
    "iCalendar spec limits lines to 75 octets, not 75 characters",
    "Octets and characters differ, especially in UTF-8 encoding",
    "Correct method counts bytes while respecting character boundaries"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}