eclipse-aascw / aas-core-codegen / 35355683695

90%

push

github

Refuse a malformed base64 uniformly in the XML (#727)

The six targets did not agree on what `xs:base64Binary` admits, and no
two of them were lenient in the same way. `SGk` was read by Java, C# and
C++ and refused by Go, Python and TypeScript, although it is three
characters long. Python quietly discarded a character outside
the alphabet, so `SG!k=` came in as "Hi". The `Buffer` of Node took
every one of these, and an equals sign in the middle besides.

None of the decoders enforces the lexical space, so each target now
checks it before decoding:

    (B64 B64 B64 B64)* ((B64 B64 B64 B64) | (B64 B64 B16 '=')
                        | (B64 B04 '=='))?

See: https://www.w3.org/TR/xmlschema-2/#base64Binary

This especially pins down the constrained character *before*
the padding. The bits which the padding drops have to be zero,
so only sixteen characters may precede a single `=` and only four may
precede `==`. `SA==` is a lexical form; `SG==` is not.

Mind that this is about the *lexical space* and not about whitespace,
which was settled separately: `xs:base64Binary` allows whitespace
between the characters as well as around them, so it is dropped before
any of this is looked at.

An empty element was the second disagreement. Java and C# answered with
zero bytes, which is right -- the whole production is optional -- while
Python refused it with "Expected an element with text". The Python
reader of a byte array now tolerates an empty element, the way its
reader of a string already did.

C# stops streaming the content through `XmlReader.ReadContentAsBase64`
and reads it as a text instead. That decoder is lenient in ways XSD is
not, and it leaves nothing to check before it has already decoded.

8 of 8 new or added lines in 2 files covered. (100.0%)

34786 of 40533 relevant lines covered (85.82%)

2.57 hits per line