最近、会社には日本のプロジェクトがあります。以前は、自然に開発された中国のCMSを使用していて、言語パッケージを分離しなかったため、ウェブサイトの構築とデバッグプロセス中に頭痛を引き起こす文字化けの問題に遭遇しました。
文字化けしたコードの理由
各文字エンコードのストレージスペースは異なるため、データがデータを読み取るために使用される場合、文字スペースが小さすぎる場合、正常に表示することはできません。
たとえば、漢字の文字セットは一般にGB2312です。 UTF-8を使用してGB2312の文字を読み取りおよび変更すると、Carled Codeがある場合があります。 UTF-8のキャラクターセットのストレージスペースはGB2312よりも大きいため、UTF-8を使用して読み取ると、一部のキャラクターGB2312はエンコーディングには存在しません。静的ファイルの場合、ファイルのストレージエンコードがWebページのエンコード設定（charset）と矛盾している場合、上記の理由により、文字化けコードが発生します。
上記は、既存の問題を解決する際の国際化のASPのサポートを含む、文字化けの問題の単純な分析です。
関係する3つの機能：@codepage、response.codepage、session.codepage
以下はMSDNからの通路です。
setting@codepageexplictliclitylyctringstringsinasingleresponse.response.codepageafectsdynamicstringsinasingleresponse、およびsession.codepageaffectsdynamicstringsinasingleresponse。
3つの機能すべてがASPのエンコードを設定できます。ここで、 @CodePageはPHPのヘッダーに相当し、ドキュメントの先頭に発行する必要があります。
中国のオペレーティングシステムのIISでは、デフォルトはGB2312、パラメーター値は「936」であり、日本の文書を指定するコードページを指定する必要があります。
<％@codepage = 932％>
この関数を使用して、特定の使用方法のドキュメントエンコードを設定します：http：//www.cloudward.net/techlife/article.asp?id=490
今は問題ないはずですよね？うわー、問題はまだ存在します。すべてのSEO会社のASPプログラムが静的ページを生成する必要があることを考慮してください。生成されたページはすべてWindowsのデフォルトANSIであり、日本語の文字を含むコードがまだ集まっています。このようにして、UTF-8または日本にエンコードされたファイルを生成するには、ASP関数が必要です。次のコードを使用して完了します。
setobjstream = server.createObject（ "adodb.stream"）
withoutbjstream
。開ける
.charset = "utf-8" //エンコード、ここでは任意のエンコードに変更できます
.position = objstream.size
.writeText = pencat // pencatは書かれたデータです
.savetofilesserver.mappath（ "patch/flilename.html"）、2 //ファイルパスを生成します
。近い
終わりに
setobjstream =何もない
テスト後の文字化けコードの問題が解決されました。