FileMaker 14 : contrôle des fins de lignes LF et CRLF
Mise à jour : FileMaker 16 rend désormais la technique expliquée ci-dessous inutile. Voici une technique la remplaçant.
Pour qui ne connait pas FileMaker, c’est assez difficile à croire, et pour nous qui le connaissons bien, assez difficile à avouer, mais comme toutes les plateformes, FileMaker a ses faiblesses.
Il y en a une qui remonte aux premières versions de FileMaker (soit juste après l’invention du biface), et qui nous empêche de contrôler les fins de lignes dans un fichier texte exporté par FileMaker.
C’est peut-être un détail pour vous, mais pour ceux qui doivent travailler dans des environnements hétérogènes Mac/Windows ça veut dire beaucoup. Et plus encore si ces fichiers texte sont « avalés » par des systèmes d’exploitation plus rudimentaires tels que ceux embarqués dans, par exemple, des machines de laboratoire ou des robots (un cas classique : on peut commander ces machines en leur déposant un fichier texte quelque part, mais encore faut-il que ce fichier soit formaté exactement comme il faut).
Peut-être avez-vous déjà fait l’expérience d’exporter un fichier texte depuis FileMaker sur Mac, même en prenant soin de choisir l’option ANSI (Windows) comme format, et en l’ouvrant avec le Bloc-notes de Windows, vous avez constaté que les retours à la ligne étaient absents? (en fait ils n’étaient pas absents, mais Windows ne comprend pas qu’il s’agit d’un retour à la ligne). Ceci dit, bien des logiciels sous Windows sont suffisamment bien pensés pour interpréter le CR comme une fin de ligne.
Ceci est dû à une longue querelle entre Apple-Montaigu et Windows-Capulet (à moins que ce ne soit l’inverse)
UNIX utilise le « Line Feed », appelé LF Char (10)
Le Mac (qui a toujours raison, car il est le plus beau) utilise le retour chariot (CR pour carriage return), ou Char (13). C’est aussi ce que FileMaker utilise en interne et représente par le signe ¶.
Windows (qui est fait pour ceux qui s’y connaissent, et donc a encore plus raison) utilise une combinaison des deux : CRLF. Ceinture et bretelles.
Il n’y avait donc pas de moyen « natif » jusqu’ici de contrôler cette fin de ligne. On pouvait toutefois utiliser une commande externe (AppleScript, shell, batch…) ou un plugin, mais ça semblait être un marteau pour écraser une mouche… et ça n’était pas compatible FileMaker Go et WebDirect (oui, je sais, on trouve toujours le moyen, mais avec des bidouilles anormales).
On finissait par se dire que personne chez FileMaker ne se pencherait sur le problème… et on avait raison !
Mais, au détour d’une modification apportée par FileMaker 14, nous avons un moyen de parvenir à nos fins.
Attention toutefois, si grâce à cette technique on peut contrôler le LF ou le CRLF, il est paradoxalement impossible de contrôler le CR. Un export natif vous permet malgré tout toujours de créer un fichier CR (et puis honnêtement, le Mac étant le seul à l’utiliser, et étant par ailleurs suffisamment bien conçu pour s’accomoder très bien d’un LF ou d’un CRLF, il n’est pas crucial d’exporter en CR).
Si vous n’avez rien compris, c’est que j’ai mal expliqué. Laissez-moi une deuxième chance en regardant la vidéo et une troisième en téléchargeant le fichier 🙂
Si vous aimez, n’hésitez pas à mettre un petit commentaire ci-dessous.
Note : dans cette vidéo, nous utilisons un traitement de texte TextWrangler gratuit, que vous pouvez trouver ici
Téléchargez le fichier de démo ici : 
1MT_EndOfLine.fmp12
Ouf, merci !
Une épine de moins dans mon pied.
La solution tordue que j’utilisais sur mac était de d’ouvrir l’export sous Word puis de réenregistrer le fichier avec CRLF. Une tannée. Aucun problème avec les exports sur PC, grrrrr….
Ta solution reste encore un peu compliquée mais au moins ça fonctionnera. Il faut des fois faire des choses très savantes pour arriver à ce qui se fait par ailleurs très simplement.
Superbe vidéo, merci beacoup !
Excellent !
Et quelle humilité ! 😉
Merci,
Super, il fallait y penser.
Si j’avais eu ça un an plutôt !!!!
What a great solution, thank you very much!
We are currently still running on FM13 but already utilise the BaseElements plugin so with a few small changes your solution can work in FM13.
Je veux faire un export en forme de iCal/VCal. Afin d’obtenir un fichier .ics (qu’on pourrait importer dans un calendaire), il faut avoir UTF-8 avec CRLF comme fin de ligne. Export Field Contents ne vous donne pas ça, mais avec le détour par Base64 ça marche. Merci beaucoup pour cette idée!
Apparemment, Substitute( $text ; ¶ ; char(13) & char(10) ) était nécessaire dans votre situation, et ça fonctionne bien. Mais si je fais l’export du champ conteneur moi-même, le fichier .ics aura CRLFLF au lieu de CRLF. Ça veut dire que dans mon cas la substitution n’était pas nécessaire.
Est-ce que votre situation est différente? Si FMP chez moi met les CRLF dans le fichier automatiquement, comment peut-on en dépendre? Est-ce différent dans une autre machine? Est-ce que c’est un setting invisible, ou quelque chose qui ‘colle’ pas hasard si on utilise une fonction différente? Est-ce que ça fait partie d’un fichier FM, de l’installation FM, de la langue, d’une préférence obscure? Peut on l’utiliser sécurement dans une application?
Je l’ai essayé avec FMPA14 et FMPA15, avec le même résultat.
Peter Bouma, Lesterius Netherlands
PS: J’espère que mon français est compréhensible, en discutant il me manque souvent la terminologie FM 🙂
Dag Peter,
dank u voor uw bericht!
Votre français est plus que compréhensible… sans comparaison avec mon néerlandais…
En refaisant le test, je constate que vous avez raison ! et pourtant je n’ai strictement rien changé entre la publication du fichier, le « tournage » de la vidéo, et maintenant…
Entre temps, je suis passé à Mac OS X 10.11, et j’ai fait les mises à jour de FileMaker. Vous aussi ?
Il serait vraiment intéressant de tester sur une machine avec la 14v1… il y a peut-être eu un changement.
Merci d’avoir relevé ce point !
Fabrice N.