"Kristian Koehntopp" <[EMAIL PROTECTED]> schrieb:
> Das Problem sind nie die korrekten Daten, sondern die defekten.
Das Problem ist eine falsche Interpretation von Daten. Wenn Du hier
Redundanz zum Problem erkl�rst, ist das unsinnig. Die Frage ist nur,
wie ich mit durch Redundanz erkannten Fehlern umgehe.
> Das geht nur, weil ASN.1 an alles und jedes L�ngen dranschreibt,
> anstatt L�ngen wie nicht-bin�res XML implizit klar zu machen.
ASN.1 schreibt nirgendwo L�ngen dran (_abstract_ syntax notation).
Es gibt jedoch zwei etwas geschw�tzige Transportcodierungen.
> Array
> 12 Byte <- hier 10 oder 14 Byte angeben
> Integer
> 4 Byte
> 3
>
> Integer
> 4 Byte
> 0
>
> Integer
> 4 Byte
> 2
>
>
> Stimmt die L�ngenangabe im Array nicht, k�nnte ein Reader, der
> den Array-Typ nicht erkennt ("unwissender Reader", der ohne DTD
> auf wohlgeformten ASN.1 arbeitet), auf der L�ngenangabe oder dem
> Inhalt des letzten Integer wiederaufsetzen, w�hrend ein Reader,
> der den Array-Typ kennt, die Integer einzeln parsed.
Aber auch nur, bis er die zu kurze L�nge bemerkt und abbricht. Die
Angabe 14 mu� gar kein Fehler sein. Ein Fehler w�re jedoch in diesem
Fall, anzunehmen da� das �u�ere "Array" nach dem dritten Integer zu
Ende ist.
Diese Klasse von Fehlern l��t sich in XML genauso haben:
<a><b/><c></a>
MfG
