Les meilleures pratiques en informatique changent parfois, et la gestion de certains caractères invisibles dans les fichiers texte en est un exemple. Les caractères de fin de ligne (EOL) ont évolué, notamment à des fins d’intégration des systèmes de contrôle de version. De même, le Byte Order Mark (BOM) sur les fichiers texte Unicode est de moins en moins utilisé.
Avec 4D v19 R2, 4D a évolué en douceur pour suivre ces meilleures pratiques, vous donnant ainsi plus de flexibilité en cours de route.
RAPPEL
Fin de ligne (EOL)
Vous savez que les lignes des fichiers texte sont séparées par un ou plusieurs caractères de fin de ligne. Sous Windows, il s’agit d’une combinaison de deux caractères :
- Carriage Return (#13, nommé CR) et,
- Line Feed (#10, appelé LF).
Sous macOS, c’est l’ancien caractère CR.
Les systèmes de contrôle de version comme Git ne gèrent pas CR comme caractère EOL, il est donc nécessaire d’utiliser LF à la place.
Marque d’ordre des octets (BOM)
Vous savez également qu’un fichier texte Unicode peut contenir des octets d’en-tête invisibles, appelés Byte Order Mark, qui définissent le jeu de caractères utilisé.
4D a suivi les meilleures pratiques actuelles lors de l’introduction d’Unicode, en écrivant des fichiers texte avec un BOM par défaut. Mais comme UTF-8 est presque devenu le format de fichier texte standard, la BOM est de moins en moins utilisée.
NOUVELLE convention 4D SUR LES FICHIERS TEXTES
Désormais, en suivant la tendance, 4D écrit les fichiers texte sans BOM. Et sur macOS, 4D utilise LF comme caractère EOL. Ceci est complètement automatique pour tous les fichiers écrits par 4D, tels que 4DSettings, 4dm, 4DForm, et ainsi de suite.
Lorsque vous ouvrez des fichiers dans une version précédente de 4D, vous ne rencontrerez aucun problème, même s’ils ont été écrits dans 4D v19 R2, car ces versions précédentes étaient capables d’ouvrir des fichiers sans BOM et en utilisant LF comme caractère EOL.
Paramètres de compatibilité
Vous voulez suivre le comportement de 4D ? De nouveaux paramètres de compatibilité sont disponibles et permettent TEXT TO DOCUMENT et File.setText() de générer des fichiers sans BOM et d’utiliser LF comme caractère EOL sur macOS lorsque les paramètres optionnels « charSet » et « breakMode » sont absents. Ceci est entièrement automatique ; vous n’avez pas besoin de réécrire votre code source pour bénéficier de ce nouveau comportement.
NOUVEAUX JEUX DE CARACTÈRES
Les nouveaux paramètres de compatibilité s’appliquent aux commandes TEXT TO DOCUMENT et File.setText() lorsqu’elles sont utilisées sans les paramètres optionnels « charSet » ou « breakMode ».
Aucun changement n’a été apporté pour le caractère EOL. Il peut toujours être forcé en utilisant le paramètre « breakMode ».
De la même manière, vous pouvez vouloir définir précisément si les fichiers générés par TEXT TO DOCUMENT et File.setText() contiennent une BOM ou non. Pour ce faire, définissez un jeu de caractères Unicode se terminant par « -no-bom », tel que « UTF-8-no-bom » ou « UTF-16-no-bom », pour écrire un fichier sans BOM. Pour écrire un fichier avec une BOM, vous pouvez toujours utiliser les jeux de caractères existants sans le suffixe « -no-bom », tels que « UTF-8 » ou « UTF-16 ».