Aucune information, où que ce soit, ne fait autant autorité que les informations officielles. Aujourd'hui, j'ai enfin trouvé une solution au problème d'encodage ASP de MSDN.
Ce qui suit est un passage de MSDN.
La définition de @CODEPAGE affecte explicitement les chaînes littérales dans une seule réponse. Response.CodePage affecte les chaînes dynamiques dans une seule réponse, et Session.CodePage affecte les chaînes dynamiques dans toutes les réponses d'une session.
Cette phrase explique clairement les fonctions de @CODEPAGE, Response.CodePage et Session.CodePage respectivement.
@CODEPAGE agit sur toutes les chaînes statiques, telles que const blogname="my home" dans un fichier.
Response.CodePage
, Session.CodePage agit sur toutes les chaînes générées dynamiquement, telles que <%=blogname%>.
Le fait est que la portée de Response.CodePage est une réponse unique, tandis que la portée de Session.CodePage déclarée dans SXNA correspond à toutes les réponses d'une session.
Regardez une autre phrase.
Si Response.CodePage n'est pas explicitement défini dans une page, il est implicitement défini par Session.CodePage, si les sessions sont activées. Si les sessions ne sont pas activées, Response.CodePage est défini par @CodePage, si @CodePage est présent dans la page. S'il n'y a pas de @CodePage dans la page, Response.CodePage est défini par la propriété de métabase AspCodePage. Si la propriété de métabase AspCodePage n'est pas définie ou est définie sur 0, Response.CodePage est définie par la page de codes ANSI du système.
À première vue, j'ai compris cette phrase comme signifiant ceci : lorsque les sessions sont activées, si Response.CodePage n'est pas déclaré, Response.CodePage sera attribué par Session.CodePage. Si les sessions ne sont pas activées, si @CodePage a été déclaré, Response.CodePage sera assigné par @CodePage, etc.......
Cette phrase explique pourquoi après être sorti de SXNA Il est facile d'avoir des caractères tronqués lors de la saisie de certains d'autres pages telles que oblog, z-blog, etc., car d'autres programmes ne déclarent pas Response.CodePage et SXNA déclare Session.CodePage. Par conséquent, dès que vous entrez SXNA, Session.CodePage se voit immédiatement attribuer une valeur (différente). versions, certaines versions reçoivent 936, certaines versions reçoivent 65001), puis lors de la saisie d'autres programmes, Response.CodePage est immédiatement attribué par Session.CodePage si le code de Response.CodePage est différent de celui de la page elle-même. , la page sera tronquée. Ainsi, lorsque des caractères tronqués sont apparus en entrant dans z-blog, j'ai vérifié que Session.CodePage et Response.CodePage étaient tous deux 936, et lorsque des caractères tronqués sont apparus en entrant dans oblog, Session.CodePage et Response.CodePage étaient tous deux 65001. C'est-à-dire, si je veux garantir la surface de la feuille. S'il n'y a pas de code tronqué, Response.CodePage doit être déclaré, sinon il interprétera la page Web selon Session.CodePage (au lieu d'interpréter la page Web selon @codepage)
. suivez l'explication ci-dessus, je suis en fait très confus, car nous sommes tous un système d'exploitation chinois. Vous pouvez essayer de sortir Session.CodePage à chaque fois que vous entrez dans le navigateur. Vous pouvez voir qu'il s'agit de 936 ! Pourquoi n'a-t-il pas attribué le Session.CodePage 936 par défaut à Response.CodePage lors de l'entrée dans Z-blog ? Au lieu de cela, donnez @CodePage à Response.CodePage ? Dans quelles circonstances Session.CodePage doit-il être attribué à Response.CodePage ? Comment devons-nous comprendre le texte original « les sessions sont activées » ?
Peut-être que les mots ci-dessus devraient être compris de cette façon :
lorsque Session.CodePage est déclaré par un programme, si Response.CodePage n'est pas déclaré, Response.CodePage sera attribué par Session.CodePage. Si Session.CodePage n'a été déclaré par aucun programme, si @CodePage a été déclaré, Response.CodePage se verra attribuer une valeur par @CodePage..., et la partie finale du contenu dynamique de la page sera interprétée en fonction de la valeur. de Réponse.CodePage.
Étant donné que Zblog et Oblog déclarent @CodePage, lorsque l'utilisateur vient de démarrer la machine et entre ensuite dans le navigateur pour parcourir Zblog et Oblog, Response.CodePage se verra attribuer une valeur par @CodePage, donc l'affichage des feuilles est normal.
Cette phrase explique plus en détail la cause des caractères tronqués.
Si vous définissez explicitement Response.CodePage ou Session.CodePage, faites-le avant d'envoyer des chaînes non littérales au client. Si vous utilisez des chaînes littérales et non littérales dans la même page, assurez-vous. la page de codes de @CODEPAGE correspond à la page de codes de Response.CodePage, ou les chaînes littérales sont codées différemment des chaînes non littérales et s'affichent de manière incorrecte.
L'une des phrases les plus utiles est que si Response.CodePage et @CODEPAGE sont différents, des caractères tronqués seront générés. C'est-à-dire que lorsque @CODEPAGE=65001 de Z-blog et Response.CodePage de Z-blog se voient attribuer 936 par Session.CodePage, des caractères tronqués apparaîtront, et vice versa pour oblog.
Je ne sais pas si l'explication ci-dessus est suffisamment claire -_-||
Laissez-moi vous expliquer pourquoi SXNA attribue parfois Session.CodePage à 936. J'ai une version qui écrit comme ceci :
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
Lorsque l'utilisateur entre dans le navigateur, Session.CodePage est par défaut 936. Le 936 par défaut à ce moment n'est pas déclaré par le programme, il ne sera donc pas attribué à Response.CodePage Lors de la saisie de SXNA, Session.CodePage est lancé par ce qui précède. code. Il devient Session.CodePage=936 déclaré par le programme, donc lors de la nouvelle saisie de Zblog, 936 est donné à Response.CodePage.
Jusqu’à présent, toutes les raisons ont été clairement analysées.
Par conséquent, le code garantissant que la feuille asp n'apparaîtra pas tronquée devrait ressembler à ceci : (en supposant qu'il s'agisse d'une feuille UTF-8)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response. Jeu de caractères = "UTF-8" %>
Expliquez davantage pourquoi Response.Charset doit être ajouté, car MSDN a dit qu'il devrait être ajouté... Haha
Si la page de codes est définie dans une page, alors Response.Charset doit également être défini.
De plus, le format de fichier d'une
page Web doit être le même que le @CODEPAGE utilisé dans la page.
C'est pourquoi certains programmes tels que zblog et pjblog doivent enregistrer les fichiers au format d'encodage UTF8.
En résumé, si tous les programmes déclarent Response.CodePage, ils ne seront pas interférés par Session.CodePage et ne provoqueront pas de caractères tronqués. Donc Session.CodePage ne peut toujours pas être utilisé facilement !
Article de référence :