Eh bien, ce n'est qu'un double échappement, mais oui, cela fonctionne et voici pourquoi :dans MySQL, il y a une deuxième couche d'échappement impliquée lorsque vous utilisez le LIKE opérateur.
services LIKE '%L\\\\u00e4mm\\\\u00f6n%'
l'analyse de ce littéral de chaîne MySQL vous donne une comparaison avec la requête LIKE %L\\u00e4mm\\u00f6n% . Parce que MySQL traite \ dans une requête LIKE en tant qu'échappement, cela correspondra en fait à la chaîne littérale contenant L\u00e4mm\u00f6n .
La raison en est que vous pouvez faire correspondre des chaînes à une expression de requête contenant un % littéral ou _ personnage. Par exemple, si je veux rechercher une colonne pour la chaîne littérale 100% , je peux le comparer à 100\% (écrit dans une requête sous la forme '100\\%' ) et assurez-vous que j'obtiens vraiment cent pour cent et pas n'importe quelle chaîne commençant par cent.
Il est regrettable que MySQL utilise une barre oblique inverse à la fois pour l'échappement de sa requête LIKE et pour son échappement littéral de chaîne, d'autant plus que vous écrivez probablement dans un langage de programmation englobant qui les utilise également, se retrouvant avec un triple encodage réel, qui ressemble à "services LIKE '%L\\\\\\\\u00e4mm\\\\\\\\u00f6n%'" - argh !
C'est doublement regrettable étant donné que ce comportement n'est pas conforme à ANSI SQL et ne fonctionnera dans aucune autre base de données. ANSI SQL dit qu'il n'y a pas de caractère d'échappement dans les requêtes LIKE par défaut, donc si vous voulez faire correspondre un littéral % ou _ vous devez vous inscrire en nommant votre propre caractère d'échappement, par exemple :
something LIKE '100=%' ESCAPE '='
Pour la compatibilité entre les bases de données, il est préférable de toujours utiliser le LIKE ...ESCAPE forme, et choisissez autre chose que l'horrible antislash ! (En passant, les barres obliques inverses de MySQL pour l'échappement littéral de la chaîne SQL ne sont pas non plus conformes à la norme ANSI ! Mais vous pouvez désactiver ce mauvais comportement avec le paramètre NO_BACKSLASH_ESCAPES sql_mode.)
Une meilleure idée serait probablement de casser les services dans une deuxième table plutôt que de les écraser dans une seule colonne de chaîne - c'est-à-dire. mettez votre schéma en première forme normale. Ensuite, vous pouvez obtenir une simple recherche de valeurs individuelles plutôt que d'avoir à faire une lente correspondance de sous-chaînes d'analyse complète de la table.
