我一直在彻底浏览网络，但似乎找不到包含此类转换的表格。我发现的有一些错误，不太可靠，所以我找了一些官方表或类似的，但不幸的是我没有..所以我在这里..
正如标题中提到的，我想做的是例如，知道“ñ”代表什么（这个我已经知道..“ñ”），但不仅适用于西班牙字符，还适用于其他字符（我已经知道波兰人）。
主要问题是我在 PHP 中有一个字符串，有时可能会出现例如“eñe”（没关系）和其他人作为“eñe”.. 在最新的我应该能够将其更改为“eñe”所以它是可读的.. 但如果没问题我不想改变它。为了做到这一点，我使用了 utf8_decode 函数，但如果字符串是可读的，它仍然会将“ñ”更改为“■”（但白色）..所以我不能总是解码字符串，并且如果我使用 mb_detect_encoding 函数，我总是会得到“UTF-8”作为响应..它不是那么有用..
一旦我知道所有的 utf8 位字符都写成例如“ñ”的“ñ”，“Ź”的“Ź”等，我计划做一个基本上将一个替换为另一个的函数......这是有点像 utf8_decode 所做的事情.. 除非这里有人有更好的解决方案！
提前致谢！问候！
你为什么要这样做？你想恢复损坏的数据吗？
它真的不应该作为通常的业务代码流的一部分来完成。您需要做的就是确保您的 web 应用程序的所有层都正确使用 UTF-8。PHP 源、HTTP 响应标头和正文、数据库表、数据库连接等。另请参阅PHP UTF-8 备忘单。
如果您确实想将此作为一项一次性任务来恢复损坏的数据，那么很高兴知道您问题中的损坏数据表示 UTF-8 数据被错误地存储或显示为 ISO-8859-1。您只需将数据读取为 ISO-8859-1 并写入为 UTF-8。一度。然后以正确的方式去做。
作为证据，ñ（Unicode Character 'LATIN SMALL LETTER N WITH TILDE' (U+00F1)）存在于 Unicode（UTF-8，一种多字节编码）字节0xC3和0xB1. 当这些字节使用像 ISO-8859-1 这样的单字节编码进行编码时，0xC3就会变成Ã和0xB1变成±。另请参见ISO-8859-1 代码页布局。
问题是一旦你有了mojibake，就没有可靠的方法将它转换回它应该的意思。有关该问题的解释，请参阅Wikipedia 上的此段落：
考虑一个包含ISO-8859-1 编码的德语单词für的文本文件。该文件现在使用假定输入为 UTF-8 的文本编辑器打开。由于第一个字节 (
0x66) 在 -<code>0x7F 范围内0x00，因此 UTF-8 将其正确解释为f. 第二个字节 (0xFC) 不是任何 UTF-8 编码字符开头的合法值。因此，文本编辑器可以用替换字符符号替换字节，以警告用户出现问题。最后一个字节 (0x72) 也在代码范围0x00–<code>0x7F 内，可以正确解码。整个字符串现在显示如下：f�r.实现不佳的文本编辑器可能会以 UTF-8 格式保存替换；文本文件数据将如下所示：
0x66 0xEF 0xBF 0xBD 0x72，在 ISO-8859-1 中将再次显示为f�r. 替换还会破坏原始字节，从而无法恢复预期的字符。
您需要避免从一开始就使用错误的编码错误地解释文本。当它坏了时修复它为时已晚。
您的问题是解释问题而不是转码问题。在任何现代计算机上，ñ 通常输入为二进制 0xc3b1，因为它是 UTF-8 代码。如果您在旧的 iso-latin-15 代码中解释（不转码），您将得到 0xc3 = Ã 后跟 0xb1 = ±。这就是为什么没有“表格”的原因：这是一个显示问题。
最好的办法是完全避免使用异拉丁语。它会给你带来很多问题。修复程序的真正方法是：在任何地方都只使用 utf-8，它会为您节省大量时间和麻烦。
同时，如果您真的想将等效的 iso-latin-15 字符串获取到您的 utf-8 输入（如果您没有上述权利，您可以将您的字符串传递给任何代码转换器，询问它将 utf-8 转换为 iso-latin-15。您应该注意的一件事是双重转码。如果你有一个 utf-8 字符串并错误地要求从 iso-lating-15 转换为 utf-8，那么你得到的 utf-8 字符串实际上是 ñ，即二进制 0xc383c2b1。要取回正确的 utf-8 字符串，anwser 是相同的：要求将您的乱码字符串从 utf-8 转换为 iso-latin-15，这将很高兴将 0xc383 转换为 0xc3，然后将 0xc2b1 转换为0xb1，为您提供包含正确 ñ 的正确 utf-8 字符串。
特别是对于 PHP 和 Web 应用程序，请记住很多计算机（以及未来越来越多的计算机）默认会向您发送 utf-8。