
En informatique, la sensibilité à la casse détermine si les lettres majuscules et minuscules sont traitées comme distinctes ( recherche sensible à la casse ) ou équivalentes ( recherche insensible à la casse ). Par exemple, lorsqu'un utilisateur souhaite en savoir plus sur les chiens et consulte un livre numérique , « chien » et « Dog » sont synonymes. Il effectue donc une recherche insensible à la casse. En revanche, s'il consulte une encyclopédie en ligne pour trouver des informations sur les Nations Unies , par exemple, ou tout autre sujet ne présentant aucune ambiguïté quant à la casse, il préférera peut-être une recherche sensible à la casse.
Recherche : Les utilisateurs s'attendent à ce que les systèmes de recherche d'informations soient capables de gérer correctement la casse en fonction de la nature de l'opération. Les utilisateurs recherchant le mot « dog » dans une revue en ligne ne souhaitent probablement pas faire de distinction entre « dog » et « Dog », car il s'agit d'une distinction orthographique ; le mot doit être trouvé, qu'il apparaisse ou non en début de phrase. En revanche, les utilisateurs recherchant des informations sur une marque, un nom de marque déposée , un nom de personne ou un nom de ville peuvent souhaiter effectuer une recherche sensible à la casse afin de filtrer les résultats non pertinents. Par exemple, une personne recherchant le nom « Jade » ne souhaiterait pas trouver de références au minéral appelé « jade ». Sur Wikipédia en anglais , par exemple, une recherche sur « friendly fire » renvoie l'article militaire, tandis que « Friendly Fire » (avec une majuscule « Fire ») renvoie la page d'homonymie.En langages de programmation
Certains langages de programmation sont sensibles à la casse pour leurs identificateurs ( C, C++, Java, C#, Verilog, Ruby, Python et Swift ) . D' autres le sont pas comme , Ada , la plupart des BASIC ( exception de BASIC ), Common Lisp , Fortran , SQL (pour la syntaxe et, pour certaines implémentations propriétaires comme Microsoft SQL Server , pour les données elles-mêmes), , Rexx et ooRexx . existe aussi des langages, tels que Haskell , Prolog et Go , dans lesquels la casse d'un identificateur fournit des informations sur sa sémantique . autres langages encore ont une sensibilité à la casse variable ; en PHP , par exemple, les noms de variables sont sensibles à la casse, mais pas les noms de fonctions. Cela signifie que si une fonction est définie en minuscules, elle peut être appelée en majuscules, mais si une variable est définie en minuscules, elle ne peut pas être référencée en majuscules. Nim est insensible à la casse et ignore les traits de soulignement, pourvu que les premiers caractères correspondent.
Recherche textuelle
Une opération de recherche textuelle peut être sensible ou non à la casse, selon le système, l'application ou le contexte. L'utilisateur peut souvent spécifier si une recherche est sensible à la casse, par exemple dans la plupart des éditeurs de texte , des traitements de texte et des navigateurs Web . Une recherche non sensible à la casse est plus exhaustive : elle trouve « Language » (en début de phrase), « language » et « LANGUAGE » (dans un titre en majuscules). Une recherche sensible à la casse trouvera le langage informatique « BASIC », mais exclura la plupart des nombreuses occurrences indésirables de ce mot. Par exemple, le moteur de recherche Google est par défaut insensible à la casse et ne propose pas d'option pour la recherche sensible à la casse. Dans Oracle SQL, la plupart des opérations et des recherches sont sensibles à la casse par défaut, tandis que dans la plupart des autres SGBD , les recherches SQL sont insensibles à la casse par défaut.
Les opérations insensibles à la casse sont parfois appelées « pliage de la casse » , d'après l'idée de plier la table de codage des caractères de sorte que les lettres majuscules et minuscules coïncident.
Dans les systèmes de fichiers
Dans les systèmes de fichiers de type Unix , les noms de fichiers sont généralement sensibles à la casse (il peut exister deux fichiers readme.txt distincts dans le même répertoire). macOS présente une particularité : par défaut, il utilise HFS+ et APFS en mode insensible à la casse (il est donc impossible d’avoir deux fichiers readme.txt dans le même répertoire), mais en mode préservant la casse (un fichier nommé readme.txt s’affiche ainsi comme readme.txt et un fichier nommé Readme.txt s’affiche ainsi comme Readme.txt). Ceci pose problème aux développeurs et aux utilisateurs avancés , car la plupart des systèmes de fichiers des autres environnements de type Unix sont sensibles à la casse. Par exemple, l’arborescence du code source d’un logiciel pour systèmes de type Unix peut contenir deux fichiers nommés Makefile dans le même répertoire. De plus, certains programmes d’installation pour macOS supposent que les noms de fichiers ne sont pas sensibles à la casse et échouent sur les systèmes de fichiers sensibles à la casse.
Les anciens systèmes de fichiers MS-DOS FAT12 et FAT16 étaient insensibles à la casse et ne la conservaient pas ; ainsi, un fichier nommé readme.txt ou ReadMe.txt était enregistré comme README.TXT. Plus tard, avec VFAT dans Windows 95, les systèmes de fichiers FAT sont devenus sensibles à la casse afin de prendre en charge les noms de fichiers longs . Les systèmes de fichiers Windows plus récents, tels que NTFS, sont sensibles à la casse en interne, et deux fichiers readme.txt peuvent coexister dans le même répertoire. Cependant, en pratique, les noms de fichiers sont considérés comme insensibles à la casse pour les utilisateurs et la plupart des logiciels. Cela peut poser des problèmes aux développeurs ou aux logiciels provenant d'environnements de type Unix, similaires à ceux rencontrés avec les systèmes de fichiers insensibles à la casse de macOS.