Dans quels moteurs JS, en particulier, sont-ils à LowCase & toUpperCase sensibles aux paramètres régionaux?

Dans le code de certaines bibliothèques (par exemple, AngularJS , le lien conduit aux lignes spécifiques du code), je peux voir que les fonctions de conversion de cas personnalisées sont utilisées à la place des standards. Il est justifié en supposant que dans les navigateurs avec les paramètres régionaux turcs, les fonctions standard ne fonctionnent pas comme prévu:

console.log("SCRIPT".toLowerCase()); // "scrıpt" console.log("script".toUpperCase()); // "SCRİPT"

Mais est-ce vraiment ou était-il toujours le cas? Les navigateurs se comportent-ils de cette façon? Si oui, lesquels d'entre eux? Qu'en est-il de node.js? D'autres moteurs JS?

L'existence des méthodes toLocaleLowerCase et toLocaleUpperCase implique que toLowerCase et toUpperCase sont invariantes par localisation, n'est-ce pas?

Pour quels navigateurs, en particulier, l'équipe angulaire conserve-t-elle cette vérification dans le code: if ('i' !== 'I'.toLowerCase())... ?

Si votre navigateur (périphérique) utilise les paramètres régionaux de la Turquie ou de l'Azerbaïdjan, exécutez cet extrait et écrivez moi si vous découvrez que le problème existe.

 if ('i' !== 'I'.toLowerCase()) { document.write('Ooops! toLowerCase is locale-sensitive in your browser. ' + 'Please write your user-agent in the comments to this question: ' + navigator.userAgent); } else { document.write('toLowerCase isn\'t locale-sensitive in your browser. ' + 'Everything works as expected!'); }

 <html lang="tr">

Toutes les implémentations JS qui suivent la norme ECMA-262 5.1 doivent implémenter String.prototype.toLocaleLowerCase et String.prototype.toLocaleUpperCase

Et selon la norme toLocaleLowerCase est supposé convertir la chaîne dans son majuscule minuscule selon le mappage local spécifique.

Dans le cas où toLowerCase convertit en chaîne minuscule telle que définie par les mappages unicode.

Pour la plupart des langues, toLocaleLowerCase et toLowerCase donnent le même résultat. Mais pour certaines langues, comme le turc, le carnet de cas ne suit pas le cartographie unicode, de sorte que toLocaleLowerCase et toLocaleLowerCase donnent un résultat différent.

La bibliothèque / cadre que vous utilisez (Jquery, Angular, Node quoi que ce soit) ne fait aucune différence. C'est dans la mise en œuvre de JS que vous utilisez pour exécuter vos librairies JS qui fait et change les choses.

Pour toutes les raisons pratiques, il est exact de conclure que Node / Angular ou toute autre bibliothèque et cadres JS se comportent exactement les mêmes lorsqu'ils traitent des chaînes (tant qu'ils sont utilisés par JS Engine qui implémente ECMA-262 3 et plus). Cela dit, je suis sûr que plusieurs frameworks étendent l'objet de chaîne pour ajouter plus de fonctionnalités, mais les propriétés et fonctions de base définies par ECMA-262 5.1 existent toujours et se comporteront exactement de la même manière.

Pour en savoir plus: http://www.ecma-international.org/ecma-262/5.1/#sec-15.5.4.17

En ce qui concerne les navigateurs, tous les navigateurs modernes mettent en œuvre les normes ECMA-262 5.1 dans leur moteur JS. Je ne suis pas sûr de Node, mais de l'exposition limitée que j'ai avec Node, je pense qu'ils utilisent également JS mis en œuvre par ECMA-262 5.1 standard.

Remarque : Veuillez noter que je ne pouvais pas le tester!

Selon la spécification ECMAScript :

String.prototype.toLowerCase ()

[…]

Aux fins de cette opération, les unités de code à 16 bits des chaînes sont traitées comme des points de code dans le plan multilingue Unicode Basic. Les points de code de substitution sont directement transférés de S vers L sans aucun mappage.

Le résultat doit être dérivé selon les mappages de cas dans la base de caractères de caractères Unicode (ceci comprend explicitement non seulement le fichier UnicodeData.txt, mais aussi le fichier SpecialCasings.txt qui l'accompagne dans Unicode 2.1.8 et versions ultérieures).

[…]

String.prototype.toLocaleLowerCase ()

Cette fonction fonctionne exactement de la même manière que LowCase, sauf que son résultat est destiné à produire le résultat correct pour les paramètres régionaux actuels de l'environnement hôte, plutôt qu'un résultat indépendant de la localisation. Il n'y aura qu'une différence dans les quelques cas (comme le Turc) où les règles pour cette langue sont en conflit avec les mappages de cas Unicode réguliers.

[…]

Et selon l' enveloppe spéciale de la base de caractères Unicode :

[…]

Format

Les entrées de ce fichier sont dans le format lisible par machine suivant:

<code>; <lower>; <title>; <upper>; (<condition_list>;)? # <comment>

Mappages inconditionnels

[…]

Préserver l'équivalence canonique pour I avec point. Turkic est traité ci-dessous.

0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE

[…]

Mappages sensibles à la langue Ce sont des caractères dont les mappages complets dépendent du langage et peut-être aussi du contexte (quels caractères sont avant ou après). Pour plus d'informations, voir l'en-tête de ce fichier et le standard Unicode.

lituanien

Le lituanien conserve le point en minuscule i suite à des accents.

Supprimez DOT ABOVE après "i" avec la supérieure ou la titécase

0307; 0307; ; ; lt After_Soft_Dotted; # COMBINING DOT ABOVE

Présentez un point explicite ci-dessus lorsque les capitaux propres I et J sont chaque fois qu'il y a plus d'accents ci-dessus. (Des accents utilisés en lituanien: grave, aigu, tilde ci-dessus et ogonek)

0049; 0069 0307; 0049; 0049; lt More_Above; # LATIN CAPITAL LETTER I

004A; 006A 0307; 004A; 004A; lt More_Above; # LATIN CAPITAL LETTER J

012E; 012F 0307; 012E; 012E; lt More_Above; # LATIN CAPITAL LETTER I WITH OGONEK

00CC; 0069 0307 0300; 00CC; 00CC; lt; # LATIN CAPITAL LETTER I WITH GRAVE

00CD; 0069 0307 0301; 00CD; 00CD; lt; # LATIN CAPITAL LETTER I WITH ACUTE

0128; 0069 0307 0303; 0128; 0128; lt; #LATIN CAPITAL LETTER I WITH TILDE

Turc et azerbaïdjanais

I et i-dotless; I-dot et i sont des paires de cas en turc et en azeri. Les règles suivantes traitent ces cas.

0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE

0130; 0069; 0130; 0130; az; # LATIN CAPITAL LETTER I WITH DOT ABOVE

En minuit, supprimez dot_above dans la séquence I + dot_above, qui se transformera en i. Cela correspond au comportement de l'I-dot_above symboliquement canonique

0307; ; 0307; 0307; tr After_I; # COMBINING DOT ABOVE

0307; ; 0307; 0307; az After_I; # COMBINING DOT ABOVE

Lorsqu'il est en minuscule, à moins qu'un I soit avant un dot_above, il se transforme en i sans dot.

0049; 0131; 0049; 0049; tr Not_Before_Dot; # LATIN CAPITAL LETTER I

0049; 0131; 0049; 0049; az Not_Before_Dot; # LATIN CAPITAL LETTER I

En majusculant, je me transforme en une capitale pointillée I

0069; 0069; 0130; 0130; tr; # LATIN SMALL LETTER I

0069; 0069; 0130; 0130; az; # LATIN SMALL LETTER I

Remarque: le cas suivant se trouve déjà dans le fichier UnicodeData.txt.

0131; 0131; 0049; 0049; tr; # LATIN SMALL LETTER DOTLESS I

EOF

En outre, selon JavaScript pour Absolute Beginners (de Terry McNavage) :

 > "I".toLowerCase() // "i" > "i".toUpperCase() // "I" > "I".toLocaleLowerCase() // "<dotless-i>" > "i".toLocaleUpperCase() // "<dotted-I>" 
Remarque : toLocaleLowerCase() et toLocaleUpperCase() cas en fonction de vos paramètres OS . Vous devriez modifier ces paramètres en turc pour que l'exemple précédent fonctionne. Ou prenez simplement ma parole!

Et selon le commentaire de Bobince sur Convertir chaîne JavaScript pour être minuscule? Question :

Accept-Language et navigator.language sont deux paramètres complètement distincts. Accept-Language reflète les préférences choisies par l'utilisateur pour les langues qu'ils souhaitent recevoir dans les pages Web (et ce paramètre n'est pas inaccessible à JS). navigator.language ne reflète que la localisation du navigateur Web installé et ne devrait généralement pas être utilisé pour rien. Ces deux valeurs ne sont pas liées aux paramètres régionaux du système, qui est le bit qui décide ce qu'il faut faire à LocaleLowerCase (); C'est un niveau de niveau OS hors de la portée des préférences du navigateur.

Ainsi, le réglage lang="tr-TR" vers html ne reflètera pas un cas de test réel, car il s'agit d'un paramètre de système d'exploitation requis pour reproduire l'exemple de boîtier spécial.

Je pense que seuls les bascules ponctués-I ou toUpperCase() -i seraient spécifiques aux paramètres locaux lorsque vous utilisez toLowerCase() ou toUpperCase() .

Selon ces sources crédibles / officielles, je pense que vous avez raison: 'i' !== 'I'.toLowerCase() évaluerait toujours à false.

Mais, comme je l'ai dit, je ne pouvais pas le tester ici.