这看起来像是“双重编码”的一个例子。这是右手在说utf8，而左手在听拉丁语1的地方。用utf-8字符查看故障；我所看到的并不是我所储存和看到的http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases . Réation -> Réation 在取消双重编码之后。
但是你说 R'action --我想知道你是否在打字 é 作为 e' 或者 'e ?? 我也会假设你的意思是 L’Oreal ?? (请注意“右单引号”而不是“撇号”。）
首先，我们需要验证它实际上是一个普通的双重编码。

SELECT col, HEX(col) FROM ... WHERE ...

应该给你这个 Réation :

52  E9       6174696F6E  -- latin1 encoding
52 C3A9      6174696F6E  -- utf8 encoding
52 C383 C2A9 6174696F6E  -- double encoding

（忽略间距。）
如果你得到了第三个答案，继续我的回答。如果你还有别的发现，停下来！——这个问题比我想象的要复杂。
现在，看看双编码修复程序是否会修复它（在修复之前）：

SELECT col, CONVERT(BINARY(CONVERT(CONVERT(
                  BINARY(CONVERT(col USING latin1)) USING utf8mb4)
                      USING latin1)) USING utf8mb4)
     FROM tbl;

你需要阻止它的发生并修复数据。下列某些情况是不可逆的；在table上测试一下！
你的情况是： CHARACTER SET latin1 ，但有utf8/utf8mb4字节；修复字符集时保留字节：
首先，假设您有tbl.col的声明：

col VARCHAR(111) CHARACTER SET latin1 NOT NULL

然后在不更改字节的情况下转换列：

ALTER TABLE tbl MODIFY COLUMN col VARBINARY(111) NOT NULL;
ALTER TABLE tbl MODIFY COLUMN col VARCHAR(111) CHARACTER SET utf8mb4 NOT NULL;

注意：如果你从 TEXT ，使用 BLOB 作为中间定义(确保其他规格保持不变- VARCHAR , NOT NULL 等）
对每个有问题的表中的每一列都这样做。
（在这个讨论中，我不区分utf8mb4和utf8。大多数文本对这两者都很满意；emoji和一些中文需要utf8mb4，而不仅仅是utf8。）
来自评论

CONVERT(UNHEX('C38EC2B2') USING utf8mb4) = 'β'  (Greek beta)
CONVERT(CONVERT(UNHEX('C38EC2B2') USING latin1) USING utf8mb4) = 'β'

我的结论是：首先你有一些错误的配置。然后应用了一个或多个错误修复。你现在一团糟，我不敢帮你解开。也就是说，混乱不仅仅是“双重编码”。
如果可能，重新开始，确保在添加更多数据之前正确存储了一些测试数据。如果数据不好，不要尝试修复数据；退后，重新开始。请参阅“故障…”中的“最佳括号”以正确设置。我会帮你解释你在表格里看到的十六进制数是否正确。