公式情報ほど権威のある情報はどこにもありません。今日、MSDN から ASP エンコードの問題の解決策をついに見つけました。
以下は MSDN からの一節です。
@CODEPAGE を設定すると、単一の応答内のリテラル文字列に明示的に影響し、Response.CodePage は単一の応答内の動的文字列に影響し、Session.CodePage はセッション内のすべての応答内の動的文字列に影響します。
この文では、@CODEPAGE、Response.CodePage、Session.CodePage のそれぞれの機能を明確に説明しています。
@CODEPAGE は、ファイル内の const blogname="my home" などのすべての静的文字列に作用します。Response.CodePage
、
Session.CodePage は、<%=blogname%> などのすべての動的に出力される文字列に作用します。
重要なのは、SXNA で宣言された Session.CodePage のスコープがセッション内のすべての応答であるのに対し、Response.CodePage のスコープは単一の応答であるということです。
別の文を見てください。
Response.CodePage がページ内で明示的に設定されていない場合、セッションが有効な場合、ページ内に @CodePage が存在する場合、Response.CodePage は @CodePage によって暗黙的に設定されます。ページに @CodePage がない場合、Response.CodePage は AspCodePage メタベース プロパティによって設定されます。AspCodePage メタベース プロパティが設定されていないか、0 に設定されている場合、Response.CodePage はシステム ANSI コード ページによって設定されます。
一目見ただけで、この文は次のような意味であると理解しました。セッションが有効な場合、Response.CodePage が宣言されていない場合、Response.CodePage は Session.CodePage によって割り当てられます。
セッションが有効になっていない場合、@CodePageが
宣言されている場合、@CodePage などによって Response.CodePage が割り当てられます。
oblog、z-blog などの他のページでは、他のプログラムは Response.CodePage を宣言しておらず、SXNA はたまたま Session.CodePage を宣言しているため、SXNA に入るとすぐに、Session.CodePage に値が割り当てられます。バージョンには、936 が割り当てられているバージョン、65001 が割り当てられているバージョンがあります)、その後、他のプログラムを入力すると、Response.CodePage のコードがページ自体のコードと異なる場合、Response.CodePage はすぐに Session.CodePage によって割り当てられます。 , ページが文字化けしてしまいます。そこで、z-blog入力時に文字化けした場合はSession.CodePageとResponse.CodePageがともに936であることを確認し、oblog入力時に文字化けが発生した場合はSession.CodePageとResponse.CodePageが両方とも65001であることを確認しました。
リーフ表面を保証したい場合 文字化けしたコードがない場合は、Response.CodePage を宣言する必要があります。それ以外の場合は
、(@codepage に従って Web ページを解釈するのではなく) Session.CodePage に従って Web ページを解釈します。
上記の説明に従ってください。私たちは皆、中国のオペレーティング システムなので、ブラウザに入るたびに Session.CodePage を出力してみると、936 であることがわかります。 Z-blog に入るときに、なぜデフォルトの Session.CodePage 936 を Response.CodePage に割り当てなかったのでしょうか?代わりに、Response.CodePage に @CodePage を与えますか?どのような状況で Session.CodePage を Response.CodePage に割り当てる必要がありますか? 「セッションが有効になっている」という原文をどのように理解すればよいでしょうか?
おそらく、上記の言葉は次のように理解する必要があります。Session.CodePage
がプログラムによって宣言されている場合、Response.CodePage が宣言されていない場合、Response.CodePage は Session.CodePage によって割り当てられます。 Session.CodePage がプログラムによって宣言されていない場合、@CodePage が宣言されている場合、Response.CodePage には @CodePage... によって値が割り当てられ、ページの最後の動的コンテンツ部分はその値に従って解釈されます。 Response.CodePage の。
Zblog と Oblog は両方とも @CodePage を宣言しているため、ユーザーがマシンを起動したばかりで、ブラウザに入って Zblog と Oblog を閲覧すると、Response.CodePage には @CodePage によって値が割り当てられるため、リーフ表示は正常になります。
この文では、文字化けの原因についてさらに説明しています。Response.CodePage
または Session.CodePage を明示的に設定する場合は、リテラル文字列と非リテラル文字列を同じページで使用する前に設定してください。 @CODEPAGE のコード ページが Response.CodePage のコード ページと一致しているか、リテラル文字列が非リテラル文字列とは異なる方法でエンコードされているため、正しく表示されません。
役に立つ文章としては、Response.CodePageと@CODEPAGEが異なると文字化けが発生するというものがあります。つまり、Z-blogの@CODEPAGE=65001とZ-blogのResponse.CodePageにSession.CodePageで936を割り当てると文字化けが発生し、oblogではその逆になります。
上記の説明が十分に明確かどうかはわかりません -_-||
SXNA が Session.CodePage を 936 に割り当てる理由を説明しましょう。次のようなバージョンがあります:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
ユーザーがブラウザに入ると、Session.CodePage のデフォルトは 936 になります。この時点でのデフォルトの 936 はプログラムによって宣言されていないため、SXNA に入ると、Session.CodePage は上記によって投げられます。プログラムで宣言したSession.CodePage=936となるので、再度Zblogに入るとResponse.CodePageに936が与えられます。
これまでのところ、すべての理由が明確に分析されています。
したがって、ASP リーフが文字化けしないようにするためのコードは次のようになります: (UTF-8 リーフであると仮定します)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response。文字セット ="UTF-8" %>
MSDN が追加する必要があると述べているため、Response.Charset を追加する必要がある理由をさらに説明してください... (笑)
コード ページがページ内に設定されている場合は、Response.Charset も設定する必要があります。
さらに、
Web ページのファイル形式は、ページで使用されている @CODEPAGE と同じである必要があります。
zblog や pjblog などの一部のプログラムが UTF8 エンコード形式でファイルを保存する必要があるのはこのためです。
要約すると、すべてのプログラムが Response.CodePage を宣言していれば、Session.CodePage の影響を受けずに文字化けが発生することはありません。ということで、Session.CodePageはまだ簡単には使えません！
参考記事: