J'étudie le codage UTF-8 depuis quelques jours et je suis tellement confus que je vais discuter de mes opinions avec vous. Bienvenue à approuver. Voici mes réflexions. S'il y a quelque chose qui ne va pas, n'hésitez pas à m'éclairer et à m'aider à le signaler.
Digressions connexes :
1. Système d'exploitation
Le système de fenêtres est entièrement Unicode en interne. Les noms de dossiers, les noms de fichiers, etc. sont tous unicode et peuvent être affichés normalement dans n'importe quel système linguistique.
2. Méthode de saisie :
La sortie Microsoft Pinyin est Unicode et la sortie Smart ABC est en chinois simplifié (Smart ABC ne peut donc pas du tout être utilisé dans les systèmes en chinois non simplifié et ne peut taper qu'en anglais).
3. Zone de texte de la page Web
La zone de texte de la page Web est affichée en Unicode. Ainsi, tout ce que vous tapez sera affiché. Mais certaines zones de saisie créées en flash ne fonctionneront pas.
4. Accès2000
Les données enregistrées lors de l'accès sont unicode et peuvent être affichées dans n'importe quel système de langue.
Si certains caractères ne sont pas normaux lorsqu'ils sont affichés dans la vue des données, c'est que la police utilisée pour l'affichage n'est pas une police Unicode.
Passez à la police Arial Unicode MS pour tout afficher. (accéder à l'aide, rechercher, saisir unicode, des instructions sont disponibles)
5. Mot
Conversion entre le chinois traditionnel et le chinois simplifié dans Word. Après la conversion du chinois simplifié en chinois traditionnel, le code interne est toujours du chinois simplifié. En fait, il ne s'agit que de caractères chinois traditionnels en chinois simplifié.
6. ASP est Unicode en interne et tout le texte est stocké en Unicode. Convertissez vers le jeu de caractères spécifié si nécessaire.
Tirons d’abord la conclusion :
<%@ codepage=936%>Chinois simplifié
<%@ codepage=950%>Chinois traditionnel
<%@codepage=65001%>UTF-8
La page de codes spécifie le codage dans lequel IIS lit la chaîne transmise (soumission de formulaire, transmission de barre d'adresse, etc.).
Spécifie également le codage vers lequel toutes les variables de texte sont converties à partir d'Unicode,
Il spécifie également le codage dans lequel les données extraites de la base de données sont converties à partir d'Unicode. (Notez ceci, c'est très important.)
Mots-clés :
Lecture : Une chaîne, si elle est lue en chinois simplifié, ce sera quelques caractères, si elle est lue en chinois traditionnel, ce sera quelques caractères, l'encodage de la chaîne elle-même n'a pas changé.
Conversion : le système convertit activement, par exemple, du caractère "化" d'Unicode en caractère "化" de Big5, le code interne devient celui de Big5. S'il n'y a pas de mot correspondant dans Big5, la forme Unicode est conservée (&#xxxx;)
Chinois simplifié : six conclusions
Forme hexadécimale Unicode : six conclusions
Forme décimale Unicode : six conclusions
Voici le processus de conversion d'encodage que j'ai spéculé :
Client : méthode de saisie Unicode - zone de saisie Unicode - conversion d'Unicode en codage correspondant par charset () - formulaire d'envoi de codage
Côté serveur : IIS décode le formulaire - lit selon l'encodage spécifié par la page de code - convertit en Unicode correspondant - peut être lu avec request ("") - effectue certains traitements - enregistre dans la base de données en encodage Unicode
Côté serveur : lisez les données Unicode de la base de données et convertissez-les dans l'encodage spécifié par la page de code --- générer le code source -- IE les lit et les affiche en fonction du jeu de caractères.
Voici quelques exemples :
Exemple 1 :
Supposons qu'il existe trois pages asp, une page de message typique :
1.write.asp est un simple formulaire de saisie et est soumis à add.asp.
<META http-equiv="Content-Type" content="text/html; charset=big5">
2.add.asp reçoit les messages et les enregistre dans la base de données
<%@page de code=936%>
3.read.asp obtient les messages de la base de données et les affiche.
<%@ codepage=936%> charset=GB2312 ou
<%@ codepage=950%> charset=big5
Vous pouvez deviner. J'ai utilisé la méthode de saisie Microsoft Pinyin pour saisir "Hua Liu Discussion" dans write.asp. Qu'est-ce qui sera affiché dans read.asp à la fin ?
Avez-vous le vertige? Analysons-le depuis le début.
Exemple 2 :
Que se passera-t-il si nous modifions le <%@ codepage=936%> dans add.asp dans l'exemple 1 en <%@ codepage=950%> ?
Qu'avez-vous trouvé ici ?
1. Si le texte saisi est différent du Charset correspondant, une fois converti, les caractères sous forme Unicode peuvent apparaître. Voici pourquoi. L'ensemble du processus est désormais conservé.
2. La page de codes dans Add.asp détermine le texte enregistré dans la base de données et quelle langue correspond à Unicode. Par exemple, codepage=936,
Ensuite la base de données enregistre le chinois simplifié Unicode (la base de données récupère le système chinois simplifié, tout est normal),
Codepage=950 enregistre l'Unicode chinois traditionnel (ce serait une erreur de reprendre le système chinois simplifié).
3. Faites attention au processus de changement de chaîne :
1) Méthode de saisie --- CharsetUnicode---- spécifie le mappage du jeu de caractères
2) Jeu de caractères ---- chaîne d'encodage de formulaire encodage simple
3) Processus inverse de l'étape précédente de décodage de forme, les deux étapes sont décalées.
4) La chaîne à appuyer sur codepage pour lire la chaîne et la chaîne n'a pas changé. Cette étape peut provoquer un "malentendu de lecture".
5) Convertir en jeu de caractères spécifié par Unicode Codepage correspondant ---- Mappage Unicode
6) Traitement intermédiaire, aucun changement dans la base de données, directement saisi sous forme Unicode
7) Appuyez sur codepage pour lire la base de données Unicode ---- mappage du jeu de caractères spécifié par la page de code
8) Cela montre que la chaîne lue à partir du jeu de caractères spécifié par Charset n'a pas changé.
Illustrons avec l’exemple 1 :
Exemple 2 :
Vertigineux. Maintenant, mettons ces connaissances à profit.
Cas 1.
Le code qui fonctionne bien sous le système chinois simplifié est tronqué dans la base de données lorsqu'il est placé dans un espace étranger, et les données originales sont également tronquées.
Analyse : Parce que la plupart des gens utilisent généralement le système chinois simplifié, la page de code par défaut = 936, donc peu importe si tout le monde ne l'écrit pas.
Mais quand on part à l’étranger, des problèmes d’espace se posent. L'Unicode de la base de données a été converti en codage anglais, donc une fois le chinois simplifié original de la base de données converti en anglais, l'affichage GB sera naturellement tronqué.
Comme le montre l'image, le texte nouvellement saisi s'affiche normalement, mais l'Unicode anglais est enregistré dans la base de données.
Solution : ajoutez <%@codepage=936%> à tous.
L'ensemble du processus implique uniquement une conversion entre le chinois simplifié et l'Unicode correspondant.
Cas 2 :
Que dois-je faire si je souhaite convertir le code et les données en chinois simplifié vers la version complète en chinois traditionnel ?
Analyse : 1. L'encodage de tous les fichiers de code est modifié en Big5 et le fichier lui-même est enregistré en chinois traditionnel.
2. <%@page de code=936 %>
3.Charset=big5
4. La version d'accès n'a pas d'importance, car les données en accès sont Unicode.
5. Ok, le code peut s'exécuter sous le système chinois traditionnel pur.
6. Problèmes restants : il y aura quelques points d'interrogation lors de la lecture des données originales en chinois simplifié. L'effet est le même que celui de la lecture 950 dans l'exemple 1, affichage big5. Étant donné que l'Unicode du chinois simplifié est converti en chinois traditionnel, certains caractères ne sont pas en chinois traditionnel, des points d'interrogation apparaîtront donc.
7. Solution : utilisez une page asp temporaire, codepage=65001, lisez-la en chinois simplifié Unicode, utilisez une fonction Unicode->Big5 pour la convertir en chinois traditionnel, puis réécrivez-la dans la base de données. Cela devrait fonctionner, n'est-ce pas ?
Les deux cas sont entièrement déduits par moi sur la base de la théorie et n’ont pas été confirmés.
Les critiques et corrections sont les bienvenues si vous vivez des expériences similaires.