J'ai appris JDBC il y a quelque temps et connecté à MySQL pour obtenir des données. Selon les exemples de données de l'enseignant, j'ai dû enregistrer des informations telles que des noms, et ils étaient tous en anglais. Je ne voulais pas utiliser l'anglais à l'époque, alors j'ai sauvé le nom de mon colocataire. Hehe, en conséquence, quelque chose s'est mal passé.
Connectez-vous à l'instruction de la base de données:
chaîne finale statique db_url = "jdbc: mysql: // localhost / filemanagement";
Déclaration de requête:
chaîne finale statique privée theUserQuery = "Select Name, Mot de passe, Rôle dans UserInfo WHERE NAME =?";
J'utilise mon nom pour interroger, nullpointerException, il est évident qu'aucune donnée correspondante n'a été trouvée avec mon nom, et elle existe dans la base de données. Pourquoi est-ce?
La réponse de Baidu est le code brouillé chinois. La solution consiste à modifier l'instruction de base de données de connexion à:
chaîne finale statique db_url = "jdbc: mysql: // localhost / fileManagement? useunicode = true & caractot encoding = gbk";
Essayer à nouveau!
C'est bon! Mais pourquoi est-ce? Quels sont ces deux paramètres? Pourquoi le problème a-t-il été résolu après l'avoir ajouté?
Ces deux paramètres sont expliqués comme suit:
Les valeurs par défaut pour les deux paramètres sont fausses. En d'autres termes, lorsque nous spécifions le jeu de caractères utilisé pour la connexion lors de la connexion de MySQL, tout est normal. Mais je ne connais toujours pas grand-chose sur le mécanisme, donc je continue à le vérifier.
Il s'avère qu'il existe un processus de conversion de caractéristique lorsque la connexion MySQL effectue une requête et d'autres opérations:
1. Lorsque MySQL Server reçoit la demande, convertit les données de la demande de caractères_set_client à caractères_set_connection;
2. Avant d'effectuer des opérations internes, convertissez les données demandées à caractères_set_connection au jeu de caractères de fonctionnement interne. La méthode de détermination est la suivante:
• Utilisez la valeur de définition du jeu de caractères pour chaque champ de données;
• Si la valeur ci-dessus n'existe pas, utilisez la valeur de définition de définition de caractères par défaut (extension MySQL, norme non-SQL) de la table de données correspondante;
• Si la valeur ci-dessus n'existe pas, la valeur de définition de définition de caractères par défaut de la base de données correspondante est utilisée;
• Si la valeur ci-dessus n'existe pas, utilisez des caractères_set_server pour définir la valeur.
3. Convertir le résultat de l'opération du jeu de caractères de fonctionnement interne sur caractères_set_results.
Que représentent ces ensembles de caractères?
caractères_set_server: jeu de caractères de fonctionnement interne par défaut
caractères_set_client: le jeu de caractères utilisé par les données de la source du client
caractères_set_connection: jeu de caractères de calque de connexion
caractères_set_results: jeu de caractères de résultat de requête
caractères_set_database: le jeu de caractères par défaut de la base de données actuellement sélectionnée
caractères_set_system: métadonnées du système (nom de champ, etc.) jeu de caractères
J'ai également trouvé des questions courantes. Bien qu'ils soient différents des miens, ils ont une grande valeur de référence.
• Avant d'insérer des données codées UTF8 dans une table de données avec le jeu de caractères par défaut est UTF8, le jeu de caractères de connexion est UTF8.
Lors de l'insertion, selon les paramètres par défaut du serveur MySQL, caractères_set_client, caractères_set_connection et caractères_set_results sont latin1;
Les données de l'opération d'insertion passeront par le processus de conversion du jeu de caractères de latin1 => latin1 => utf8. Au cours de ce processus, chaque caractère chinois inséré sera sauvé des 3 octets d'origine à 6 octets;
Le résultat pendant la requête passera par le processus de conversion du jeu de caractères de UTF8 => UTF8, et les 6 octets enregistrés sont retournés intacts, ce qui entraîne un code brouillé ...
• Définissez le jeu de caractères de connexion sur UTF8 avant d'insérer des données codées UTF8 dans une table de données avec le jeu de caractères par défaut Latin1.
Lors de l'insertion, caractères_set_client, caractères_set_connection et caractères_set_results sont tous utf8;
Les données d'insertion seront converties via le jeu de caractères de UTF8 => UTF8 => Latin1. Si les données d'origine contient des caractères Unicode autres que / u0000 ~ / u00ff, il sera converti en "?" (0x3f) Symbole car il ne peut pas être représenté dans le jeu de caractères de Latin1. À l'avenir, quel que soit le jeu de caractères de connexion, son contenu ne peut pas être restauré.
(Cette partie est extraite du blog de Brother Bird, et le lien est joint plus tard)
Les tableaux de ma base de données sont tous définis avec le codage UTF8, mais lorsque je me suis connecté pour la première fois, je n'ai pas défini le jeu de caractères de connexion, donc la valeur par défaut est Latin1. Après la conversion de UTF8 => Latin1, le code brouillé est généré. Le codage GBK que j'ai utilisé pour la deuxième fois, et je n'ai pas utilisé de codage UTF8. Pourquoi ça va? En fait, c'est la même chose. Le chinois n'est pas en codage latin1, mais dans GBK et UTF8, il n'y aura donc pas de problèmes.
Ce qui précède est la solution à l'exception brouillée de la connexion JDBC à MySQL. Si vous avez encore des questions, vous pouvez en discuter dans la zone de commentaires ci-dessous.