Volgens de StUF 03.01 standaard worden bestaan alle berichten uit unicode tekens gecodeerd volgens UTF-8. Een bericht begint dan met een XML prolog: <?xml version="1.0" encoding="UTF-8"?>
UTF-8 is een variabele teken codering, waarbij elk teken bestaat uit 1, 2, 3 of 4 bytes. Voor het vastleggen van elk van de 128 ASCII-tekens is slechts één byte nodig.
Naast UTF-8 bestaan er ook nog UTF-16, waarbij elk teken bestaat uit 1 of 2 woorden van 16 bit, en UTF-32 waarbij elk teken bestaat uit 1 langwoord van 32 bit. In deze coderingssystemen wordt er voor de XML prolog een BOM (Byte Order Mark) geplaatst om aan te geven of de volgorde van de bytes van een woord (of de volgorde van de woorden van een langwoord) little endian of big endian is.
Omdat bij UTF-8 gebaseerd is op bytes, heeft een BOM geen toegevoegde waarde. Sterker nog, UTF-8 is bedoeld om backwards compatibel te zijn met ASCII en ANSI, zodat het gebruik van een BOM (wat een 16 bits teken is) in tekenspraak is met deze backwards compatibiliteit.
Echter, onder ander software van Microsoft voegt bij de UTF-8-codering de drie bytes 0xEF, 0xBB, 0xBF, de UTF-8-code voor U+FEFF, aan het begin van het bestand of bericht toe. Deze "Byte Order Mark" wordt niet altijd door andere programma's goed herkend, wat kan leiden tot fatale fouten.
Dit probleem heeft een klant van ons geconstateerd tussen onze BAG applicatie (GT-BAG van geoTax) en het distributiesysteem DDS van Centric. De bevestiging van DDS op een kennisgeving van GT-BAG begint met een BOM gevolgd door de XML prolog en daarna de rest van de soap message.
Mijn vraag is hoe om te gaan met de BOM in StUF. Verbieden we dat een applicatie een BOM toevoegd aan het verzonden bericht (request dan wel response)? Of stellen we verplicht dat een applicatie een eventuele BOM in een ontvangenbericht (request of response) moet negeren?
wo, 15-06-2011 - 16.22u
#1
Hoe om te gaan met een BOM (Byte Order Mark) in StUF berichten.
Ik ben bang dat we hier in Nederland de software van Microsoft die door een groot aantal leveranciers wordt gebruikt niet kunnen veranderen. Het filteren op de BOM is relatief eenvoudig en lost het probleem op. Het door mij gebruikte Axis2 lijkt de BOM aan te bieden als eerste tekens van de SOAP-body. De StUFKletser filtert op die plek op de BOM.
Als het dan toch niet veel werk is, lijkt het me het handigst dat software leveranciers die gebruik maken van Microsoft software de BOM uit het XML bericht halen voordat ze het bericht (in UTF-8) versturen.
De UTF-8 standaard staat BOM toe. Zie Tabel 2-4 op pagina 30 van de laatste unicode-specificatie
http://www.unicode.org/versions/Unicode6.0.0/ch02.pdf
Dus StUF sluit (helaas) het gebruik van BOM niet uit. Als we het gebruik van BOM willen uitsluiten betekent dat een aanpassing op StUF.