<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<!--#include file="conn.asp"-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />Le code ci-dessus est-il correct ?
Historiquement, les textes avaient un page de code qui spécifiait simplement le jeu de caractères à utiliser. Ceux-ci avaient un nombre qui différait d'un fournisseur à l'autre, Windows semble utiliser un entier non signé de 16 bits à cette fin. De nos jours, la plupart des encodages et des jeux de caractères ont noms au lieu de numéros . Je considère que le fait que l'UTF-8 ait un numéro de page de code (qui n'est ni spécifié ni utilisé en dehors de Microsoft) est un moyen de garantir qu'il fonctionne toujours avec l'ancien système de numéro de page de code à 16 bits. Même si l'UTF-8 n'a rien à voir avec une page de code en premier lieu.
@Johannes : Le numéro de page de code est toujours une caractéristique importante de la façon dont Windows gère le codage des caractères. Par exemple, dans .NET, la classe Encoding ne peut être instanciée qu'en utilisant le numéro de codepage. Je ne pense pas que le codepage soit encore "hérité".
Votre code est correct, même si je préfère définir le CharSet dans le code plutôt que d'utiliser la balise méta :-.
<% Response.CharSet = "UTF-8" %>La page de code 65001 fait référence au jeu de caractères UTF-8. Vous devez vous assurer que votre page asp (et toute inclusion) est enregistrée en UTF-8 si elle contient des caractères en dehors du jeu de caractères ASCII standard.
En spécifiant l'attribut CODEPAGE dans le bloc <%@, vous indiquez que tout ce qui est écrit à l'aide de Response.Write doit être codé selon le Codepage spécifié, dans ce cas 65001 (utf-8). Il faut garder à l'esprit que cela n'affecte pas le contenu statique qui est envoyé mot à mot dans la réponse. C'est la raison pour laquelle le fichier doit être sauvegardé en utilisant la page de code spécifiée.
La propriété CharSet de la réponse définit la valeur CharSet de l'en-tête Content-Type. Cela n'a aucun impact sur la façon dont le contenu sera encodé, cela indique simplement au client quel encodage est reçu. Encore une fois, il est important que sa valeur corresponde à l'encodage réel envoyé.
La signification et l'effet principaux de <%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%> est que l'encodage du fichier source soit UTF-8 (ou toute autre page de code spécifiée). Cela ne se répercute que sur le fichier Response.CharSet propriété. Vous pouvez enregistrer votre fichier en tant qu'UTF-8 et mettre la déclaration CODEPAGE correspondante, puis utiliser un autre encodage pour la propriété Response.CharSet . Comme la source en 65001 et la sortie en 1251 ou 1252. - Vous le savez probablement, mais je ne pensais pas que c'était complètement clair dans votre texte, qui commence par laisser entendre qu'il pourrait s'agir de simples alternatives.
@Lumi : Je ne trouve pas une telle implication, je cite "La propriété CharSet de la réponse définit la valeur CharSet de l'en-tête Content-Type. Ceci a pas de impact sur la façon dont le contenu peut être encodé". Cela me semble assez clair. BTW le seul réel L'effet de la directive CODEPAGE est de fixer la valeur de l'option Response.CodePage Il incombe au développeur de s'assurer que le fichier est enregistré en utilisant la page de code correspondante.
Vous avez raison. J'ai confondu Response.CharSet et Response.CodePage . La définition de la directive CODEPAGE se répercute sur le second, et non sur le premier ; elle n'a aucune incidence sur la directive Content-Type tête. Je crois que la directive CODEPAGE est mieux comprise comme "codage du fichier source". Voici un exemple où il est important. L'expression critique est domXml.createElement("Französisch") . Le fichier était codé en UTF-8 (il fallait que ce soit Unicode pour que tout le grec, le russe, etc. fonctionne) et donc codepage=65001 était critique.
Oui, 65001 est l'identifiant de page de code de Windows pour UTF-8, comme documenté. sur le site de Microsoft . Wikipedia propose que la page de code 128 d'IBM et la page de code 4110 de SAP sont également des indicateurs pour UTF-8.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
