La sensibilité à la casse dans FileMaker
La sensibilité à la casse dans FileMaker
9 septembre 2017 - Auteur : - Catégories : Blog, FileMaker, Technique

La sensibilité à la casse dans FileMaker

typographie - casse

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 :

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

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.

dictionnaire

 

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 :

ID champ1 Champ2
1 A1 B1
2 A2 B2
3 A3 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 :

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.

Article précédent/suivant
Comments (8)
  • Philippe ROTTIER - 9 septembre 2017 - Répondre

    Bonsoir Fabrice,

    Merci pour ces précisions techniques sur la casse dans Filemaker mais il y a une fonction où la casse à aussi son importance : c’est la fonction Substituer.. En effet, Filemaker ne fait la substitution que s’il trouve le mot à changer avec la bonne casse dans la rubrique concernée
    Plus finement, dans Rechercher Remplacer, Filemaker demande si l’on souhaite respecter la casse ou pas..
    A+

    • (Author) Fabrice Nordmann - 10 septembre 2017 - Répondre

      Bonjour Philippe,
      Concernant la fonction Substituer, elle est citée dans le billet.
      En revanche, très bonne remarque, je n’ai pas pensé à la fonction Rechercher/Remplacer.
      Merci !

  • Jérémie Gimenez - 11 septembre 2017 - Répondre

    Salut !

    Super article. Ca fait un moment que je me disais qu’il faudrait mettre à plat le thème de la casse dans Filemaker !

    (De même que la sensibilité aux accents, cédilles, etc, d’ailleurs, mais ça ferait beaucoup…)
    (Pour anecdote : « e » = « é » retourne VRAI)
    (Alors que : Substituer ( « é » ; « e » ; « z » ) retourne « é »)

    Il reste un cas pour moi mystérieux : la fonction Occurrences.
    Globalement, Occurrences n’est pas sensible à la casse.

    Occurrences ( « A » ; « a » ) retourne 1

    Pourtant, il m’est arrivé plusieurs fois de constater que ça ne marchait pas, et de devoir utiliser :

    Occurrences ( Minuscule ( « Mon Ensemble De Valeurs » ) ; Minuscule ( « Ma Valeur Testée » ) )

    Pour que ça fonctionne vraiment.

    Je n’ai encore pas réussi à établir dans quels cas précis ça se produit ! Peut-être aussi une question d’encodage des textes au départ (??)…

    Bonne journée ! 🙂

    • (Author) Fabrice Nordmann - 13 septembre 2017 - Répondre

      Merci Jérémie !
      pour ton problème d’occurrences, je n’ai -je crois- jamais rencontré ce problème. La prochaine fois que tu tombes dessus n’hésite pas à le signaler ici.
      Personnellement, je n’utilise pratiquement jamais cette fonction.

  • Charly Kitey - 28 septembre 2017 - Répondre

    Superbe article Fabrice

  • ROTTIER - 12 octobre 2017 - Répondre

    Un autre petite commentaire sur le sujet :
    Quand on tape le nom d’une rubrique dans une formule de calcul, peu importe la casse, FileMaker la comprend sans coup férir et plus magique encore rétablit la formule avec la casse de la rubrique telle qu’elle est enregistrée.
    J’aurai bien apprécié que en cochant une case Occurrences et la fonction Recherche soit sensibles à la casse. Il serait judicieux de pouvoir facilement distinguer pierre et Pierre.

    • (Author) Fabrice Nordmann - 12 octobre 2017 - Répondre

      Bonjour,
      le résultat de recherche, comme dans toutes les bases de données, dépend des choix d’indexation. Ainsi si la rubrique est indexée en Unicode (langue définie dans l’onglet Stockage des options de rubrique), la recherche sera sensible à la casse.
      Pour les fonctions de texte comme Occurrences, Position… en effet elles ne sont pas sensibles à la casse, à l’exception des 3 mentionnées. Notons qu’il est théoriquement possible de contourner cette difficulté en utilisant la fonction ExecuterSQL et les fonctions SQL dans la requête, mais je ne conseille pas du tout cette approche pour des raisons de performances.

  • Gilbert Heintje - 20 octobre 2017 - Répondre

    Article très instructif, félicitations.

Add comment

Ce site est protégé par reCAPTCHA et la Politique de confidentialité, ainsi que les Conditions de service Google s’appliquent.