Codage de caractères étrange pour le stockage des données, l'ancien script les affiche correctement, le nouveau script ne le fait pas

Question

J'essaie de réécrire un ancien site Web.

Il est en persan et utilise des caractères persans/arabes.

CREATE DATABASE `db` DEFAULT CHARACTER SET utf8 COLLATE utf8_persian_ci;
USE `db`;

Presque toutes mes tables/colonnes ont COLLATE défini sur utf8_persian_ci

J'utilise codeigniter pour mon nouveau script et j'ai

'char_set' => 'utf8',
'dbcollat' => 'utf8_persian_ci',

Dans les paramètres de la base de données, donc pas de problème.

Alors voici la partie bizarre

L'ancien script utilisait une sorte de moteur de base de données appelé TUBADBENGINE 或 TUBA DB ENGINE... rien de spécial.

Lorsque j'ai saisi des données (persan) dans la base de données à l'aide d'un ancien script, lorsque j'ai regardé la base de données, les caractères étaient stockés sous la forme Ø1مران .

L'ancien script récupère/affiche correctement les données, mais le nouveau script les affiche en utilisant la même police/jeu de caractères étrange que la base de données

Alors quand je tape rather 时，数据库存储的数据看起来像 Ø1مراÙ ，当我在新脚本中获取它时，我会看到 Ø1Ù …راÙ 但在旧脚本中我看到?????

CREATE TABLE IF NOT EXISTS `tnewsgroups` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `fName` varchar(200) COLLATE utf8_persian_ci DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_persian_ci AUTO_INCREMENT=11 ;

--
-- Dumping data for table `tnewsgroups`
--

INSERT INTO `tnewsgroups` (`ID`, `fName`) VALUES
(1, 'عمران'),
(2, 'معماری'),
(3, 'برق'),
(4, 'مکانیک'),
(5, 'test'),
(6, 'test2');

---

Par contre, lorsque je saisis ??? directement dans la base de données

Bien sûr, j'ai stocké la même chose dans la base de données rather

Le nouveau script s'affiche très bien

Mais dans l'ancien script, je reçois ？？？

Quelqu’un peut-il comprendre cela ?

C'est un gros moteur

https://github.com/maxxxir/mz-codeigniter-crud/blob/master/tuba.php

Exemple d'utilisation d'un ancien script :

define("database_type" , "MYSQL");
define("database_ip" , "localhost");
define("database_un" , "root");
define("database_pw" , "");
define("database_name" , "nezam2");
define("database_connectionstring" , "");
$db = new TUBADBENGINE(database_type , database_ip , database_un , database_pw , database_name , database_connectionstring);
$db->Select("SELECT * FROM tnews limit 3");
if ($db->Lasterror() != "") { echo "<B><Font color=red>ÎØÇ ! áØÝÇ ãÌÏøÏÇ ÊáÇÔ ˜äíÏ";  exit(); }
for ($i = 0 ; $i < $db->Count() ; $i++) {
    $row = $db->Next();
    var_dump($row);
}

Answer 1

La réponse de

deceze est très bonne, mais je peux ajouter quelques informations qui pourraient aider à gérer un grand nombre d'enregistrements sans avoir à les tester manuellement.

Si vous convertissez CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8) 失败，则会打印 NULL 而不是 field_name du contenu.

J'ai donc utilisé ceci pour trouver ces enregistrements :

SELECT IFNULL(
    CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8)
    , '**************************************************')
FROM table_name

Ou ceci :

SELECT id, field_name, CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8)
FROM table_name
WHERE CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8) IS NULL

UPDATE avec cette clause n'affecte que les enregistrements où la conversion a réussi :

UPDATE table_name
SET
field_name = CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8mb4 )
WHERE
CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8mb4) IS NOT NULL

Answer 2

En bref, parce que cette question a déjà été abordée mille fois :

1. PHP enregistre une chaîne, telle que "汉字"，以 UTF-8 编码。该字节为 E6 BC A2 E5 AD 97.
2. Il envoie cette chaîne via la connexion à la base de données latin1 définie sur .
3. La base de données reçoit les octets E6 BC A2 E5 AD 97，认为它们代表 latin1E6 BC A2 E5 AD 97 et pense qu'ils représentent
caractères.
4. Caractères de stockage de base de données
5. æ¡ ¡ ¿ Li>
Le même processus inversé fait que PHP reçoit les mêmes octets et les traite ensuite comme UTF-8. L'aller-retour fonctionne très bien pour PHP, même si la base de données ne gère pas les caractères comme elle le devrait.

Le problème ici est donc que la connexion à la base de données n'est pas configurée correctement lorsque les données sont saisies dans la base de données. Vous devez convertir les données de la base de données en caractères corrects. Essayez ceci :

SELECT CONVERT(BINARY CONVERT(field_name USING latin1) USING utf8) FROM table_name

utf8 不是您所需要的，请尝试一下。如果有效，请将其更改为 UPDATEPeut-être que utf8 n'est pas ce dont vous avez besoin, essayez-le. Si cela fonctionne, remplacez-le par une instruction 🎜UPDATE pour mettre à jour les données de manière permanente. 🎜