CRs in exported tab-separated text

[DBasine]

De carriage returns dienen als record-separator bij export van records als tab-separated text.

Maar wat gebeurt er met de CR's binnen een veld?

Want soms zie ik binnen een veld, blokjes staan ipv CR's. En bij andere gevallen zie je de blokjes niet maar zijn toch de CR's weg.

Hoe vermijd ik dit?

[rmw]

CR is ascii code 13.

Binnen een veld gebruikt FM ascii 11.

Als er dus geen vertaalslag plaatsvindt krijg je ook ascii 11 mee naar buiten

 

rmw

[DBasine]

bedankt! dus kan ik alleen vertalen buiten Filemaker? of zoniet, hoe vertaal ik dit binnen FM?

[rmw]

De troi file plug-in heeft een conversie instructie aan boord.

Ik weet niet van een conversie binnen FM.

 

rmw

[AvD]

Door een puur toeval krijg ik hier dezefde vraag binnen. Het antwoord komt in de eerstvolgende vrije tip van de week, en dat zal dus nog wel even duren. Daarom hier de tekst "in première":

Tip 335 - Een weerbarstige pilcrow of wat is dat nu allemaal?

 

Vorige week hebben we gezien dat een Carriage Return (terug naar de kantlijn op de volgende regel) in FileMaker beschikbaar is als een aanklikbaar symbool: ¶.

En we hebben gezien dat zo'n ding ook een naam heeft, namelijk "paragraafteken", in het Engels "pilcrow".

 

Het wil lukken dat we precies deze week een vraag kregen van een gebruiker die daar problemen mee heeft.

Hij gebruikt in de winkelcatalogus op zijn website een artikelbeschrijving die uit FileMaker komt via een doodgewone export.

In FileMaker is deze artikelbeschrijving een calculatieveld waarin ook een aantal pilcrows voorkomen, onder andere om de titel te scheiden van de eigenlijke artikelbeschrijving. In FileMaker zelf ziet het er mooi uit, maar zodra het veld geëxporteerd is, verschijnen er "blokjes" en zijn de alinea-indelingen verdwenen.

 

Wat is er gebeurd en hoe lossen we het op?

 

Eerst en vooral is er het exportformaat. Dat moet wegens het importerende programma dat de vraagsteller gebruikt een Tab-separated bestand zijn.

Dat betekent dat elke record van de volgende gescheiden wordt door - ja, u vreesde het al - een Carriage Return, onze pilcrow dus, terwijl binnen een record de velden van elkaar gescheiden zijn door een TAB-teken. De rest van het probleem laat zich raden: FileMaker "beseft" heel goed dat hij geen Carriage Returns kan toelaten binnen een veld, omdat die anders geïnterpreteerd zou worden als een record separator (namelijk de inleider van de volgende record). FileMaker lost dit op door binnen een veld de pilcrow (ASCII 13) te vervangen door een teken met gelijkaardig effect, namelijk de Vertical Tab (ASCII 11). En daar zit nu precies het probleem: heel wat "ontvangende" programma's kunnen met dit teken niet overweg. Dit is ook het geval met Notepad. Notepad geeft dit aan door het Vertical Tab teken te vervangen door een blokje, wat betekent "Ik weet echt niet wat hiermee aan te vangen", waardoor meteen de "terug naar de kantlijn" niet uitgevoerd wordt. Da's perfect logisch.

 

Andere programma's herkennen de Vertical Tab wel en voeren die dan ook perfect uit. Dat is het geval met MS Word, maar ook bijvoorbeeld met Wordpad en het goeie ouwe Write (dat nog perfect draait onder de nieuwere Windows-versies). Daar verschijnt de tekst precies zoals we die bedoeld hadden, netjes met de alinea-indelingen. Op de Mac kunnen we hier ... en ... gebruiken.

 

Onze gebruiker moet dus gaan importeren via een tussenstap in bijvoorbeeld Wordpad. Wil hij dat niet, dan is er nog een betalende oplossing: de Troi File plugin.

 

Ik hou me aanbevolen voor het invullen van de puntjes door de juiste programma-namen. Dank!

[PJ007]

Kan iemand misschien zeggen hoe je bovenstaande in de Troi plugin voor elkaar kunt krijgen.

 

Heb het voorbeeldbestand van Troi gebruikt, maar het lukt mij alleen om de Carriage Return aan het einde van een regel te vervangen.

 

Of te wel, wat moet er precies in de zoekstring komen te staan.

 

Alvast bedankt

[carl_vdm]

Goed nieuws!

 

Pages leest deze files PREFECT !