Keine Information ist nirgends so maßgeblich wie offizielle Informationen. Heute habe ich endlich eine Lösung für das ASP-Kodierungsproblem von MSDN gefunden.
Das Folgende ist eine Passage aus MSDN.
Das explizite Festlegen von @CODEPAGE wirkt sich auf Literalzeichenfolgen in einer einzelnen Antwort aus, und Session.CodePage wirkt sich auf dynamische Zeichenfolgen in allen Antworten in einer Sitzung aus.
Dieser Satz erklärt deutlich die Funktionen von @CODEPAGE, Response.CodePage und Session.CodePage.
@CODEPAGE wirkt auf alle statischen Zeichenfolgen, z. B. const blogname="my home"
,
und Session.CodePage wirkt auf alle dynamisch ausgegebenen Zeichenfolgen, z. B. <%=blogname%>
Der Punkt ist, dass der Bereich von Response.CodePage eine einzelne Antwort ist, während der Bereich von Session.CodePage, der in SXNA deklariert ist, alle Antworten in einer Sitzung umfasst.
Schauen Sie sich einen anderen Satz an.
Wenn Response.CodePage nicht explizit auf einer Seite festgelegt ist, wird es implizit von Session.CodePage festgelegt, wenn Sitzungen aktiviert sind. Wenn Sitzungen nicht aktiviert sind, wird Response.CodePage von @CodePage festgelegt, wenn @CodePage auf der Seite vorhanden ist. Wenn die Seite keine @CodePage enthält, wird Response.CodePage durch die Metabasiseigenschaft AspCodePage festgelegt. Wenn die Metabasiseigenschaft AspCodePage nicht festgelegt oder auf 0 gesetzt ist, wird Response.CodePage durch die ANSI-Codepage des Systems festgelegt.
Auf den ersten Blick habe ich diesen Satz so verstanden: Wenn Sitzungen aktiviert sind und Response.CodePage nicht deklariert ist, wird Response.CodePage von Session.CodePage zugewiesen. Wenn Sitzungen nicht aktiviert sind und @CodePage deklariert wurde, wird Response.CodePage von @CodePage usw. zugewiesen.
Dieser Satz erklärt, warum es nach dem Verlassen von SXNA leicht zu verstümmelten Zeichen kommt, wenn einige eingegeben werden andere Seiten wie oblog, z-blog usw., da andere Programme Response.CodePage nicht deklarieren und SXNA zufällig Session.CodePage deklariert. Daher wird Session.CodePage sofort ein Wert zugewiesen (anders). Es gibt einige Versionen, denen 936 und einige Versionen 65001 zugewiesen sind. Bei der Eingabe anderer Programme wird Response.CodePage sofort von Session.CodePage zugewiesen, wenn sich der Code von Response.CodePage von dem der Seite selbst unterscheidet , wird die Seite verstümmelt sein. Als also beim Betreten von z-blog verstümmelte Zeichen auftraten, überprüfte ich, ob Session.CodePage und Response.CodePage beide 936 waren, und wenn beim Betreten von oblog verstümmelte Zeichen auftraten, waren Session.CodePage und Response.CodePage beide 65001. Das heißt, Wenn ich sicherstellen möchte, dass die Blattoberfläche keinen verstümmelten Code enthält, sollte Response.CodePage deklariert werden, andernfalls wird die Webseite gemäß Session.CodePage interpretiert (anstatt die Webseite gemäß @codepage zu interpretieren)
. Folgen Sie der obigen Erklärung, ich bin eigentlich sehr verwirrt, weil wir alle es sind Es ist ein chinesisches Betriebssystem. Sie können versuchen, Session.CodePage jedes Mal auszugeben, wenn Sie den Browser aufrufen. Sie können sehen, dass es 936 ist. Warum hat er Response.CodePage beim Betreten von Z-Blog nicht die Standard-Session.CodePage 936 zugewiesen? Geben Sie stattdessen @CodePage an Response.CodePage? Unter welchen Umständen sollte Session.CodePage Response.CodePage zugewiesen werden? Wie ist der Originaltext „Sitzungen sind aktiviert“ zu verstehen?
Vielleicht sollten die obigen Worte so verstanden werden:
Wenn Session.CodePage von einem Programm deklariert wird und Response.CodePage nicht deklariert ist, wird Response.CodePage von Session.CodePage zugewiesen. Wenn Session.CodePage von keinem Programm deklariert wurde und @CodePage deklariert wurde, wird Response.CodePage von @CodePage ... ein Wert zugewiesen und der endgültige dynamische Inhaltsteil der Seite wird entsprechend dem Wert interpretiert von Response.CodePage.
Da sowohl Zblog als auch Oblog @CodePage deklarieren, wird Response.CodePage von @CodePage ein Wert zugewiesen, wenn der Benutzer gerade den Computer gestartet hat und dann den Browser zum Durchsuchen von Zblog und Oblog aufruft, sodass die Blattanzeige normal ist.
Dieser Satz erklärt weiter die Ursache für verstümmelte Zeichen.
Wenn Sie Response.CodePage oder Session.CodePage explizit festlegen, stellen Sie sicher, dass Sie nicht-literale Zeichenfolgen an den Client senden Die Codepage von @CODEPAGE stimmt mit der Codepage von Response.CodePage überein, oder die Literalzeichenfolgen sind anders als die Nichtliteralzeichenfolgen codiert und werden falsch angezeigt.
Einer der nützlicheren Sätze ist, dass, wenn Response.CodePage und @CODEPAGE unterschiedlich sind, verstümmelte Zeichen generiert werden. Das heißt, wenn @CODEPAGE=65001 von Z-blog und Response.CodePage von Z-blog von Session.CodePage 936 zugewiesen werden, werden verstümmelte Zeichen angezeigt und umgekehrt für oblog.
Ich weiß nicht, ob die obige Erklärung klar genug ist -_-||.
Lassen Sie mich erklären, warum SXNA manchmal Session.CodePage 936 zuweist. Ich habe eine Version, die so schreibt:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
Wenn der Benutzer den Browser betritt, ist Session.CodePage standardmäßig auf 936 eingestellt. Der Standardwert 936 wird derzeit nicht vom Programm deklariert und wird daher nicht Response.CodePage zugewiesen. Bei der Eingabe von SXNA wird Session.CodePage durch das oben Gesagte ersetzt Code. Es wird vom Programm zu Session.CodePage=936 deklariert, sodass bei erneuter Eingabe von Zblog 936 an Response.CodePage übergeben wird.
Bisher wurden alle Gründe klar analysiert.
Daher sollte der Code, um sicherzustellen, dass das ASP-Blatt nicht verstümmelt erscheint, wie folgt aussehen: (vorausgesetzt, es handelt sich um ein UTF-8-Blatt)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response. Zeichensatz ="UTF-8" %>
Erklären Sie weiter, warum Response.Charset hinzugefügt werden sollte, weil MSDN gesagt hat, dass es hinzugefügt werden sollte ... Haha.
Wenn die Codepage auf einer Seite festgelegt ist, sollte auch Response.Charset festgelegt werden.
Darüber hinaus muss das Dateiformat einer
Webseite mit dem auf der Seite verwendeten @CODEPAGE übereinstimmen.
Aus diesem Grund müssen einige Programme wie zblog und pjblog Dateien im UTF8-Codierungsformat speichern.
Wenn alle Programme Response.CodePage deklarieren, werden sie nicht durch Session.CodePage beeinträchtigt und verursachen verstümmelte Zeichen. Daher kann Session.CodePage immer noch nicht einfach verwendet werden!
Referenzartikel: