Comment convertir la casse d'un texte

Les conventions de nommage comptent. Que vous écriviez du code, créiez des noms de fichiers ou formatiez des titres, utiliser la bonne casse de texte garde les choses cohérentes et professionnelles. Convertir entre les casses manuellement est fastidieux et sujet aux erreurs, surtout avec du texte long ou des noms de variables. Un convertisseur basé sur navigateur gère tous les formats de casse courants instantanément.

Casses de texte courantes et où elles sont utilisées

Comment convertir la casse de texte

1. Collez votre texte : entrez n'importe quel texte dans le convertisseur. Cela fonctionne avec des mots simples, des noms de variables, des phrases ou des paragraphes entiers.
2. Choisissez une casse : cliquez sur le format que vous voulez. La conversion s'applique instantanément.
3. Copiez le résultat : cliquez sur Copier pour saisir le texte converti pour votre code, document ou nom de fichier.

Une brève histoire des conventions de nommage en code

Les premiers langages de programmation avaient des limites strictes sur la longueur des identifiants : FORTRAN (1957) permettait 6 caractères ; ALGOL (1958) permettait des caractères limités. Les programmeurs devaient abréger agressivement. Il n'y avait pas besoin de conventions de casse parce que les identifiants étaient trop courts pour avoir plusieurs mots.

Lorsque les langages ont permis des identifiants plus longs (C 1972, Pascal 1970), la séparation des mots est devenue une question. Pascal a popularisé l'utilisation de lettres majuscules pour séparer les mots : MyVariable. C utilisait historiquement les minuscules avec des soulignements : my_variable. La division a persisté : la plupart des langages de la famille C et Unix préfèrent snake_case (Python, Ruby, Rust par défaut, colonnes PostgreSQL), tandis que les langages de la famille Java et Microsoft préfèrent camelCase (JavaScript, Java, C#, Swift, Kotlin).

PascalCase a émergé de Smalltalk (années 1980) pour les noms de classes, puis a été adopté par C++ (1985), Java (1995) et C# (2000). Aujourd'hui, la plupart des langages utilisent PascalCase pour les types/classes et camelCase pour les instances/fonctions, indépendamment de la préférence pour le séparateur de mots.

kebab-case est apparu avec le Web : CSS a choisi les traits d'union (background-color) et les URL les préfèrent aussi. La plupart des langages Web modernes (HTML, CSS, chemins d'URL, schémas JSON) utilisent kebab-case pour les identifiants visibles à l'utilisateur.

La convention la plus récente est SCREAMING_SNAKE_CASE pour les constantes et les variables d'environnement : un héritage du shell Unix qui a traversé dans la plupart des langages de programmation dans les années 2000.

Quand utiliser chaque convention

Un guide pratique :

• MAJUSCULES en prose : acronymes (NASA, HTML, CSS), emphase (rarement ; le gras est généralement meilleur), titres dans les systèmes de design qui le spécifient.
• minuscules en prose : URL, adresses e-mail, hashtags, chat décontracté. Dans le code : rarement, sauf dans certaines variantes Lisp.
• Casse Titre : titres de livres, titres d'articles, noms propres. Différents guides de style ont différentes règles sur quels mots capitaliser.
• Casse phrase : standard pour le texte corps, descriptions, étiquettes d'interface utilisateur dans les systèmes de design modernes (Material Design, Apple HIG préfèrent tous deux la Casse phrase pour les boutons).
• camelCase : variables JavaScript/TypeScript, noms de méthodes Java/Swift, variables d'instance dans la plupart des langages OO.
• PascalCase : noms de classes, noms de types, noms de composants React/Vue, types enum.
• snake_case : variables/fonctions Python et Ruby, noms de colonnes de base de données, noms de champs GraphQL (parfois), variables shell.
• SCREAMING_SNAKE_CASE : constantes dans la plupart des langages, variables d'environnement (DATABASE_URL, NODE_ENV), clés de config en YAML/JSON.
• kebab-case : slugs d'URL, noms de classes CSS, attributs HTML data-*, noms de packages npm, noms de fichiers dans les générateurs de sites statiques.
• dot.case : chemins de propriétés d'objets en code, fichiers de config (propriétés Nginx, Spring Boot), événements namespaced.

Règles de Casse Titre

« Casse Titre » semble simple mais a des complications de guide de style :

• Style APA : capitalisez les mots de 4+ lettres ; capitalisez tous les noms, verbes, adjectifs, adverbes indépendamment de la longueur.
• Chicago Manual of Style : capitalisez les premiers/derniers mots ; capitalisez tous les noms, verbes, adjectifs, adverbes, pronoms ; mettez en minuscules les articles (a, an, the), prépositions courtes, conjonctions de coordination (and, but, or).
• Style AP : capitalisez tous les mots de 4+ lettres ; exceptions spécifiques pour les prépositions.
• Style MLA : similaire à Chicago mais avec de légères différences dans la gestion des prépositions.

Un convertisseur « simple title case » capitalise chaque mot (ce qui ne correspond techniquement à aucun guide de style majeur). La plupart des convertisseurs offrent « Title Case » comme estimation rapide mais signalent le résultat pour une revue manuelle de :

• Articles (a, an, the)
• Conjonctions (and, but, or, for, nor)
• Prépositions courtes (in, on, at, by, to, of)
• Acronymes (API, HTTP, CSS)

Pièges courants

• Acronymes en camelCase : xmlHTTPRequest est maladroit. Le guide de style JavaScript de Google recommande de traiter les acronymes comme des mots : xmlHttpRequest ou XmlHttpRequest. Les guides de style Microsoft et Java les gardent tout en majuscules : XMLHttpRequest. Choisissez une convention.
• Nombres dans les identifiants : version2Point0 vs version2_0 vs version20. Pas de règle universelle ; dépend de la convention du langage.
• Acronymes capitalisés à la lettre initiale : « i18n » est camelCase, « I18n » est PascalCase, « I18N » est screaming. Adaptez à votre contexte.
• Casse Titre sur les prépositions : « Off The Record » semble incorrect à la plupart des éditeurs ; « Off the Record » suit la plupart des guides de style. Vérifiez avant de publier.
• Les conventions de casse de base de données varient : PostgreSQL et la plupart des implémentations SQL sont insensibles à la casse pour les identifiants non cités mais sensibles à la casse pour les identifiants cités. SELECT myColumn FROM table peut échouer si le nom de colonne réel est mycolumn.
• Sensibilité à la casse des noms de fichiers par OS : macOS HFS+ est insensible à la casse par défaut ; APFS est insensible à la casse mais préserve la casse ; Linux ext4 est sensible à la casse ; Windows NTFS est insensible à la casse (mais les sous-systèmes Linux sur Windows sont sensibles à la casse). MyFile.txt et myfile.txt peuvent ou non etre le meme fichier.
• La casse Unicode dépend de la locale : İ majuscule (I pointé turc) vs I (anglais). Certaines implémentations de toUpperCase() font cela mal sans locale explicite.

Conseils

• Correspondez à la convention de votre langage : Python utilise snake_case, JavaScript utilise camelCase et CSS utilise kebab-case. La cohérence au sein d'une base de code est plus importante que la préférence personnelle.
• Unicode est supporté : le convertisseur gère les caractères accentués, les emoji et les caractères CJK, donc il fonctionne avec du texte dans n'importe quelle langue.
• Vérifiez les acronymes en Casse Titre : la plupart des convertisseurs de casse titre capitalisent chaque mot, ce qui peut transformer « API » en « Api ». Revoyez les acronymes après la conversion.
• Utilisez la Casse phrase pour la lisibilité : pour le texte orienté utilisateur comme les étiquettes de boutons et descriptions, la casse phrase est souvent plus facile à lire que la Casse Titre.
• Configurez votre linter : ESLint, Prettier, Pylint, RuboCop peuvent tous appliquer les conventions de nommage automatiquement. Configurez-les une fois et laissez le linter attraper les violations de casse à l'enregistrement.
• Utilisez un guide de style de code : Google, Airbnb, Microsoft, GitHub publient tous des guides de style pour les langages majeurs. Choisissez-en un pour votre projet et tenez-vous-y.

Confidentialité et texte sensible

Le convertisseur de casse fonctionne entièrement dans votre navigateur. Le texte que vous collez, les conversions intermédiaires et la sortie restent tous sur votre appareil. Rien n'est téléversé sur un serveur, enregistré ou partagé avec qui que ce soit.

Cela importe parce que les chaines que vous convertissez sont souvent confidentielles : noms de variables provenant de bases de code propriétaires, points de terminaison d'API internes, titres d'articles en brouillon, copies orientées client sous embargo, noms de colonnes de base de données qui révèlent la structure du produit. Les convertisseurs de casse en nuage enregistrent chaque conversion dans leurs journaux de requete et peuvent les utiliser pour « amélioration » ou analytique. Un convertisseur exclusivement basé sur navigateur a zéro exposition, et fonctionne hors ligne une fois la page chargée.