Fix to support parsing of "quoted-printable" encoded property values

[mlandes]

Example of valid vcard property:

NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:foobar foobar foobar foobar fo=
obar foobar foobar foobar foobar=0Afoobar foobar foobar foobar foobar fooba=
r=0Afoobar foobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar=
 foobar foobar foobar foobar foobar

---

With "visible" EOL characters ...:

NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:foobar foobar foobar foobar fo=\n
obar foobar foobar foobar foobar=0Afoobar foobar foobar foobar foobar fooba=\n
r=0Afoobar foobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar=\n
 foobar foobar foobar foobar foobar\r\n

... or as string:

"NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:foobar foobar foobar foobar fo=\nobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar foobar fooba=\nr=0Afoobar foobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar=\n foobar foobar foobar foobar foobar\r\n"

[jhermsmeier]

The lines of the note in your example seem to be incorrectly folded, the subsequent lines are missing a leading whitespace character. The following, with folded lines, parses correctly:

NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:foobar foobar foobar foobar fo=\r\n
 obar foobar foobar foobar foobar=0Afoobar foobar foobar foobar foobar fooba=\r\n
 r=0Afoobar foobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar=\r\n
 foobar foobar foobar foobar foobar\r\n

[jhermsmeier]

@mlandes with what did you run into this issue? Is it a specific program / platform / whatever that outputs QP encoded notes like that?

[mlandes]

I use a webservice by ABBYY for OCR of business cards, which outputs vcards with a Quoted-Printable encoded note property in this form:

NOTE;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:foobar foobar foobar foobar fo=\nobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar foobar fooba=\nr=0Afoobar foobar foobar foobar foobar foobar=0Afoobar foobar foobar foobar=\n foobar foobar foobar foobar foobar\r\n

According to RFC this is correct syntax, because only a combination of \r\n (CRLF) is a correct property delimiter and folding is defined as:

a CRLF immediately followed by a single white space character (space (U+0020) or horizontal tab (U+0009)). The folded line MUST contain at least one character.

See: https://tools.ietf.org/html/rfc6350#section-3.2

In Quoted-Printable encoding a separate sequence of =\n is used as encoding-specific folding.
This is compatible with RFC folding of vcards.
For vcards in RFC, =\n is just a normal sequence of characters without any impact, neither folding nor delimiting the vcard property.

[jhermsmeier]

I see – the formatting of the examples in your initial comment tripped me up there. Would you mind adding a test to go along with this, so we don't break it again in the future?

[mlandes]

done

[jhermsmeier]

Neat, thanks!

[jhermsmeier]

Published in vcf@2.0.5

[mlandes]

Note: I meant Pullrequest #31, not Issue #31 ...

[jhermsmeier]

Yeah, no worries – issue and PR numbers don't overlap on GitHub, so it'll be found :)

[mlandes]

@jhermsmeier

Hi again,
after testing some vcards in real life, which I extracted from QR-Codes on business cards,
it seems that the world does not always stick to the RFC specifications as intended... meaning often vcards are generated wrongly using \n instead of the correct \r\n for delimiting.

Therefore I had to use a small workaround to support these "common-law" vcards:

import vCard from "vcf";

createFromVcfString(vcfString) {
    if (!vcfString.includes("\r\n")) {
        vcfString = vcfString.replace(/\n/g, "\r\n");
    }
    return new vCard().parse(vcfString);
}

Maybe this should be added in your module so that this pullrequest does not break these often used but wrongly generated vcards.

[jhermsmeier]

Well, that's why the line-splitting regex was /\r?\n/g before – but obviously I forgot about that, and didn't have a test for either.

Thinking about it though, it'll be best to stick to the specifications. Supporting LF only vcards would also break support for QP encoded newlines. And users can still work around this by replacing LF with CRLF in their input should they need to parse malformed vcf data.