tekens vervangen tbv xml export

[marspan]

Bij het exporteren in xml-format - niet via XSLT, maar met een eigen systeem met enkele custom functies - moet alle tekst er xml-veilig uitkomen. Behalve het encoderen naar 'echte' xml tekens - zoals > naar > - mogen er ook geen diakrieten in voorkomen, zoals ï of è of ñ. Daarvoor heb ik een cf gemaakt met een uitgebreide substitute, die het op Mac uitstekend doet en alle diakrieten omzet naar hun kale versie, in dit geval i, e of n. Maar op Windows werkt het niet of niet goed.

In eerste instantie had ik alle diakrieten gewoon ingetypt, in tweede instantie heb ik ze vervangen door hun Char( ) variant. Ook dat helpt niet.

Zou het kunnen komen omdat die cf wordt aangeroepen binnen de berekening van een variabele?

We werken momenteel nog onder FMP11, binnenkort gaan we over naar 14. Kan het met 11 te maken hebben?

[Felix]

.

6 oktober 2015 aangepast door Gast

[menno]

Hoi Martin,

 

ik begrijp uit jouw verhaal dat jouw probleem al IN FM11 optreedt. Of is dat niet juist, klopt het resultaat-bestand niet? Over welke versie van Windows heb je het eigenlijk?

 

Ik heb even een substitute samensgesteld met een paar exotische diakrieten en die werkt op W2008R2, W7, W8 en W8.1 probleemloos:

Substitute ( "ëúôçßþæøăñğ" ; [ "ë" ; "e" ] ; [ "ú" ; "u" ] ; [ "ô" ; "o" ] ; [ "ç" ; "c" ] ; [ "ß" ; "ss" ] ; [ "þ" ; "th" ] ; [ "æ" ; "ae" ] ; [ "ø" ; "oe" ] ; [ "ă" ; "a" ] ; [ "ñ" ; "n" ] ; [ "ğ" ; "g" ] )

geeft:

euocssthaeoeang

precies zoals ik verwacht.

 

Overigens neem ik aan dat het ontvangende programma de diakrieten niet accepteert? Zoals Felix namelijk al opmerkt zijn diakrieten in UTF-8 en ISO-8859-1 gewoon toegestaan. Geef je in de resultaat xml wél de karakterset op?

 

mvg, Menno

[marspan]

Dank voor de reacties. Zo'n substitute gebruikte ik ook, en die werkte op Mac vlekkeloos. Gisteravond begreep ik eindelijk wat de oorzaak van het probleem was. Je moet xml bestanden liefst wegschrijven als UTF-8. Ik gaf helemaal geen codereng op. Wij gebruiken de Troi File plug-in om de exportbestanden weg te schrijven en te vullen, en die heeft daarvoor gewoon een switch ( -encoding=UTF-8 ), het kan haast niet eenvoudiger. Voor de zekerheid ook in de xml expliciet aangegeven dat het de encoding UTF-8 is, en het gaat nu helemaal goed. Geen substitute nodig, op de tekens na die echt niet in xml mogen staan, zoals < > etc.

[menno]

de Troi File plug-in om de exportbestanden weg te schrijven en te vullen, en die heeft daarvoor gewoon een switch ( -encoding=UTF-8 ), het kan haast niet eenvoudiger. Voor de zekerheid ook in de xml expliciet aangegeven dat het de encoding UTF-8 is

Officieel encodeert de File plug-in standaard UTF-8 maar pas sinds een bepaalde versie (weet even niet welke) gebeurt dat ook werkelijk, oudere versies encoderen de tekst als UTF-16, het interne formaat van FileMaker. Ik heb een paar jaar geleden exact hetzelfde probleem gehad met de File plug-in. Ik gebruik zelf nog steeds bij voorkeur xslt, maar ieder heeft zo zijn eigen voorkeur hé? Verstandig dat je in het resultaat ook de encoding opgeeft, want veel programma's en webservices verwachten dat ook.