Welcome, Guest
Username: Password: Remember me

TOPIC: UTF-8 xml

UTF-8 xml 02 sept 2013 16:48 #1

Ik krijg van de ing waarschuwingen dat er ongeldige tekens in de xml staan. Zoals ë. Toen was het een warning omdat het veld adres waarschijnlijk niet gebruikt wordt uiteindelijk. Echter als test heb ik tekens in de unstrctured refence gezet en dan wordt het bestand zelfs afgekeurd. Nu lees ik dat de banken hun eigen utf-8 standaard hebben.

In beschrijving van de xml staat:
The UTF-8 character encoding standard must be used in the ISO 20022 messages.
The Latin character set, commonly used in international communication, must be used.
It contains the following characters:
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ‘ +
Space

Mijn vraag is nu hoe krijg ik hem er dan wel doorheen ? Hoe zijn andere mensen daarmee omgegaan. Je kunt ze natuurlijk vervangen door spaties of ë door e maar als je bijvoorbeeld spaties erin zet en je ziet dat terug op dagafschrift dat ziet er ook niet uit. Ik lees wel iets over conversietools als er toch vreemde tekens in staan bij banken of is dat weer iets van elke bank doet wat hij wil ?

Zijn er overigens ook banken waarbij dit wel goed gaat ? Deze melding kreeg ik bij de ING. Het is natuurlijk ook nog de vraag of er verschil zit tussen de testtool en de uiteindelijke implementatie.

Update:
Ik heb overigens nog een bestand gevonden waarin de best practices voor banken staan. Daarin wordt dus wel geadviseerd om adressen en zaken die hele proces gelijk moeten blijven met speciale tekens op te slaan.
Attachments:
Last Edit: 04 sept 2013 12:59 by Jos Kaijser.
The administrator has disabled public write access.

UTF-8 xml 04 sept 2013 12:35 #2

Ik vervang de meest voorkomende tekens, dus "é" naar "e" en "ü" naar "ue". We doen ook betalingen voor Duitsland en dan gaat de "Ringel s" naar "ss", zo ook het teken "\" naar "/".

Op dit moment controleer ik dan ook nog of elk teken wat gebruikt wordt in de UTF-8 tekenset voorkomt, zo niet dan krijg ik een waarschuwing en dan kan ik het bewuste teken handmatig omzetten.

Het zou inderdaad makkelijker zijn, als de banken dit bij het importeren zouden omzetten.
The administrator has disabled public write access.

UTF-8 xml 05 sept 2013 12:47 #3

Volgens mij kunnen de veel hoofdsystemen van banken die speciale karakters nog niet goed aan. Daarnaast is de standaard-set nog verder beperkt, om het lezen van XML door oudere systemen te faciliteren. Banken mogen onderling uitbreidingen toestaan, dat wordt in Finland bijvoorbeeld gedaan. Maar in Nederland wordt alleen de standaard-set toegestaan.

Natuurlijk zou het prettig zijn als alle systemen gewoon unicode ondersteunen, maar de praktijk is wat weerbarstiger: de kans bestaat dat een betaling domweg afgewezen wordt.

Ik neem geen risico, en zet ALLE niet-toegestane karakters om, de meest voorkomende op basis van een lijst om de schade te beperken. Ik heb dus een toegestane lijst, een conversielijst per land/taal (bijv. ä wordt a in NL, maar ae in bepaalde andere talen), en een algemene conversielijst (bijv " wordt '). Staat een karakter niet in een van deze lijsten, dan wordt het een '.'
The administrator has disabled public write access.

UTF-8 xml 05 sept 2013 14:53 #4

Wij vervangen ze door spaties. Overigens al meegemaakt dat klanten die een naam niet weten het veld vullen met ***** waardoor bestand werd afkeurd. :( Verder al een keer tegenaan gelopen dat een i getikt met toetsenbord op NL tot afkeur leidde en i op internationale indeling niet.
The administrator has disabled public write access.

UTF-8 xml 05 sept 2013 15:00 #5

het advies/de regel van de EPC en NVB is om onbekende tekens om te zetten in een '.' Ik persoonlijk vind een serie spaties ook mooier dan een serie punten, maar dan is het duidelijk(er) naar "de mens aan de andere kant" dat er "iets" stond.
The administrator has disabled public write access.

UTF-8 xml 05 sept 2013 15:06 #6

Tja.. 9 van de 10 keer zitten deze letters in een naam of een adres. mijn ervaring is dat de geincasseerden meestal hun eigen naam of adres wel weten. LOL.

Aangezien wij wel in de assurantiesfeer zitten, komt dit vaker voor in koppelingen bv. Pieters Assurantiën. Overigens kunnen onze klanten via een inregeling sturen welke gegevens een klant op zijn dagafschrift te zien krijgt, en meestal is dit een combinatie van factuurnummer, polisnummer, notadatum en teksten als PROL voor prolongatie of MUT voor mutatie. Alleen even denken aan afbreken op 140 posities anders > afkeur...
The administrator has disabled public write access.
Time to create page: 0.411 seconds
Powered by Kunena Forum

Enigma Consulting