La sensibilité à la casse dans FileMaker

Voici peut-être un sujet un peu pointu, mais il ne fait jamais de mal d’interroger parfois les fondamentaux… essayons ici de faire le tour complet de la problématique de la casse en FileMaker.

D’abord, pour ne pas se perdre tout de suite, qu’est-ce que la « casse » ?

Ici, je parierais que beaucoup de ceux qui savent déjà ce qu’est la sensibilité à la casse ne savent pas d’où vient le mot.

Ce terme nous vient de l’imprimerie, et plus précisément de la typographie : pour composer une page, il fallait attraper très rapidement des caractères en plomb. On les rangeait alors dans une sorte de caissette en bois compartimentée et que l’on appelait casse. Chaque compartiment contenait les plombs pour un caractère de la fonte (ou police). Or on ne les rangeait pas par ordre alphabétique mais par fréquence d’utilisation. Les minuscules étant bien plus employées que les majuscules, leurs compartiments devaient être proches du typographe, et donc en « bas-de-casse », les majuscules en « haut-de-casse ».

Pour ceux que cela amuse, je vous invite à réfléchir aux termes encore employés à l’ère de l’informatique : casse, fonte, valise de police…

FileMaker comporte des fonctions de calcul qui nous permettent de manipuler la casse d’un texte :

• Minuscule ( Texte ) pour convertir un texte en minuscules
• Majuscule ( Texte ) pour convertir un texte en majuscules
• NomPropre ( Texte ) pour convertir la première lettre de chaque mot en majuscules et les autres lettres en minuscules

Ainsi que des fonctions qui permettent d’ajouter ou de retirer un style (dont la casse) :

• AjoutStyleTexte ( Texte ; Styles ) – avec les paramètres Uppercase, Lowercase, Titlecase et SmallCaps
• SupprimerStyleTexte ( Texte ; Styles ) – avec les mêmes paramètres

Mais… qu’est-ce donc que la sensibilité à la casse ? C’est très simple : selon les environnements et le contexte, on considérera qu’une majuscule a la même valeur qu’une minuscule (insensibilité à la casse) ou au contraire qu’elle a une valeur différente (sensibilité à la casse)

Par exemple dans un dictionnaire français comprenant des noms propres, comme par exemple le Larousse, on ne fera pas de différence de classement entre une majuscule et une minuscule, ainsi un nom propre avec une majuscule se retrouvera parmi des noms communs, adjectifs ou autre adverbes en minuscules.

Dans d’autres contextes, on fera nettement la différence.

Bien souvent dans les langages informatiques, la plupart des traitements sont effectués avec sensibilité à la casse. Cela vient notamment du fait que les premiers ordinateurs travaillaient sur des jeux réduits de caractères (ASCII), et ne pouvaient se permettre de s’encombrer de considérations telles que a = A à chaque fois qu’ils devaient analyser un a.

Mais FileMaker, qui comme vous le savez a été pensé pour des humains normaux (ou presque), fait l’effort depuis très longtemps de l’insensibilité à la casse. Ainsi, vous pouvez comparer des chaînes de caractères telles que « Milan » (la ville) et « milan » (le rapace), et constater une égalité :

"Milan" = "milan"

Ceci fonctionne aussi bien dans les calculs que dans les index (utilisés dans les liens, listes de valeurs ou recherches).

D’ailleurs, on peut noter qu’il en est de même avec les caractères accentués : « à » = « a », si toutefois la langue d’indexation est le français (en russe par exemple, le E (yé) et le Ë (yo) sont bien deux lettre différentes, avec chacune sa place dans l’alphabet et dans le dictionnaire. Mais il s’agit de caractères différents de l’alphabet latin, bien que visuellement similaires)

On pourrait donc penser que « FileMaker n’est pas sensible à la casse », un point c’est tout.

Or ce serait bien ennuyeux si on en restait là.

Il existe un nombre limité de cas où FileMaker est sensible à la casse (case sensitive en anglais), essayons d’en faire le tour.

Tout d’abord, certaines fonctions de calcul le sont. On en cite souvent trois en oubliant que FileMaker continue d’évoluer et que ça n’est pas parce qu’en 1914 il y en avait trois qu’il y en a forcément trois aujourd’hui.

Voici donc les trois « connues » :

• Filtre ( TexteAFiltrer ; TexteFiltre ) – Filtre ( « AaBbZ » ; « aZ » ) retournera « aZ » et non « AaZ » : le A majuscule est éliminé par le filtre
• EstEgal ( TexteOrigine ; TexteComparaison ) – EstEgal ( « monMotDePasseSuperSecret » ; « monmotdepassesupersecret » ) retournera 0 car les deux chaînes ne sont pas identiques, alors que, rappelons-le, « monMotDePasseSuperSecret » = « monmotdepassesupersecret » retournera 1 (l’opérateur de comparaison = n’est pas sensible à la casse). Soit dit en passant, si votre mot de passe est super secret, préférez une comparaison de hash MD5 plutôt que de stocker le mot de passe en clair dans la base de données !
• Substituer ( Texte ; ChaîneRecherchée ; ChaîneRemplacée ) – Substituer ( « Bébé » ; « b » ; « d » ) retournera « Bédé » et non « dédé »; car B et b sont deux caractères différents pour cette fonction sensible à la casse.

Et donc on aurait ainsi fait le tour de la question ? Que nenni…

Depuis FileMaker 12, la fonction ExecuterSQL ( RequêteSQL ; séparateurRubrique ; séparateurLigne{; arguments…} ) –  entrouvre la porte au langage de requête SQL au sein de FileMaker (d’un point de vue strict, cette porte était déjà entrouverte pour les connexions ODBC ou les plugins). Or SQL est en grande partie sensible à la casse, même si là encore, l’implémentation de FileMaker est assez tolérante.

Soit une table « maTable » contenant les colonnes « champ1 » avec les valeurs A1, A2, A3, et « Champ2 » et les valeurs  B1, B2, B3 :

La formule suivante :

ExecuteSQL ( "SELECT champ1 from matable where champ2 = 'B3'" ; "" ; "" )

retournera bien « A3 ». Autrement dit, le nom des tables et des colonnes n’est pas sensible à la casse, mais c’est maintenant le cas de la plupart des implémentations SQL. Les mots clef comme SELECT, FROM ou WHERE dans cette requête sont toujours insensibles à la casse. Par convention, on les écrit en majuscules, sauf ici où j’ai voulu illustrer l’insensibilité à la casse.

en revanche, la même formule dans laquelle on changera le critère ainsi :

ExecuteSQL ( "SELECT champ1 from matable where champ2 = 'b3'" ; "" ; "" )

retournera du vide, car « b3 » n’est pas égal à « B3 » dans une requête SQL.

Astuce : si ce comportement vous dérange, vous pouvez utiliser la fonction SQL lower :

ExecuteSQL ( "SELECT champ1 from matable where lower ( champ2 ) = 'b3'" ; "" ; "" )

Donc il y a bien quatre et non trois fonctions sensibles à la casse…

… est-ce tout ?

Non ! depuis FileMaker 16, de nouvelles fonctions sont apparues :

• SortValues ( valeurs {; typeDeDonnée ; locale } )
• UniqueValues ( valeurs{; typeDeDonnée ; locale} )

Au passage, on remarquera que FileMaker a apparemment décidé de ne plus traduire le nom des fonctions de calcul. Le traducteur a dû être sensible à la casse… sociale.

Donc essayons cette formule :

Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "" )

le résultat est :

a
b

donc aucune sensibilité à la casse.

en modifiant légèrement, pour explorer :

Uniquevalues ( list ( "A" ; "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "" )

le résultat est

A
b

donc on voit que le A majuscule est retourné à la place du a minuscule parce qu’il est trouvé en premier, mais comme on n’est pas ici sensible à la casse, le a minuscule n’est pas retourné en plus.

Mais… n’avais-je pas sous-entendu que ces fonctions étaient justement sensibles à la casse ?

Et bien… c’est qu’elles peuvent l’être !

Le dernier paramètre (facultatif) de ces fonction est locale, et il permet justement de préciser dans quelle « langue » on veut trier ou dédoublonner.

Or s’il est une langue que nous parlons vous et moi couramment, c’est bien… l’Unicode.

Dans l’aide, vous constatez que deux variantes peuvent être utilisées : Unicode_Raw et Unicode_Standard.

Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "Unicode_Raw" )

retourne

a
b
B
A
à
À

autrement dit chaque caractère est différent (accentué, non accentué, majuscule, minuscule…). Voici donc deux nouvelles fonctions (SortValues et UniqueValues) sensibles à la casse !

Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "Unicode_Standard" )

retourne

a
b
à

on voit qu’on perd la sensibilité à la casse mais pas celle aux accents.

Je crois que nous avons fait le tour de la question de la sensibilité à la casse dans FileMaker. J’espère que vous aurez appris quelque chose. N’hésitez pas à prolonger la discussion dans les commentaires ci-dessous.