230

理由がわからないのに、レガシーアプリが誤動作し始めたところです。ActivePDFによってPDFレポートに変換される一連のHTMLを生成します。

プロセスは次のように機能します。

  1. 置き換えられるトークンを含むDBからHTMLテンプレートをプルします（例： "〜CompanyName〜"、 "〜CustomerName〜"など）
  2. トークンを実際のデータに置き換えます
  3. プロパティがHTMLタグ属性値をフォーマットする単純なregex関数を使用してHTMLを整理します（ActivePDFのレンダリングエンジンは属性値の前後に一重引用符以外のものを嫌うため、引用符などを保証します）
  4. PDFを作成するWebサービスにHTMLを送信します。

その混乱のどこかで、HTMLテンプレートの改行なしスペース（ s）はISO-8859-1としてエンコードされているため、ブラウザー（FireFox）でドキュメントを表示すると、「Â」文字として誤って表示されます。ActivePDFは、これらの非UTF8文字を非難します。

私の質問：問題の原因がわからず、調査する時間がないので、悪い文字を再エンコードしたり、見つけて置き換えたりする簡単な方法はありますか？一緒に投げたこの小さな関数を使って送信しようとしましたが、すべてがgobbledegookに変わり、何も変わりません。

Private Shared Function ConvertToUTF8(ByVal html As String) As String
    Dim isoEncoding As Encoding = Encoding.GetEncoding("iso-8859-1")
    Dim source As Byte() = isoEncoding.GetBytes(html)
    Return Encoding.UTF8.GetString(Encoding.Convert(isoEncoding, Encoding.UTF8, source))
End Function

何か案は？

編集：

私は今のところこれでうまくいっていますが、それは良い解決策のようには思えません：

Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
    Return Regex.Replace(html, "[^\u0000-\u007F]", " ")
End Function
4

8 に答える 8

365

その混乱のどこかで、HTMLテンプレートの改行なしスペース（s）はISO-8859-1としてエンコードされているため、「Â」文字として誤って表示されます。

その場合、ISO-8859-1ではなくUTF-8にエンコードされます。ノーブレークスペース文字は、ISO-8859-1のバイト0xA0です。UTF-8にエンコードすると、0xC2,0xA0になります。これを（誤って）ISO-8859-1と見なすと、として出力され" "ます。これには、気付かない可能性のある末尾のnbspが含まれます。そのバイトが存在しない場合は、他の何かがあなたのドキュメントを破壊しているので、何を見つけるためにさらに上を見る必要があります。

正規表現とは何ですか、テンプレートはどのように機能しますか？ 文字列が（正しく）U + 00A0ノーブレークスペース文字に変換されている場合は、適切なHTMLパーサーがどこかに含まれているように見えます。その場合は、テンプレートをDOMでネイティブに処理し、ASCIIエンコーディングを使用してシリアル化するように依頼して、非ASCII文字を文字参照として保持することができます。これにより、HTML自体に対して正規表現の後処理を行う必要がなくなります。これは常に非常に危険なビジネスです。

とにかく、今のところ、次のいずれかをドキュメントに追加<head>して、ブラウザで正しく表示されるかどうかを確認できます。

  • HTML4の場合：<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  • HTML5の場合：<meta charset="utf-8">

それを行った場合、残りの問題はActivePDFの障害です。

于 2009-09-22T19:13:53.790 に答える
25

誰かが私と同じ問題を抱えていて、文字セットがすでに正しい場合は、次のようにします。

  1. .htmlファイル内のすべてのコードをコピーします。
  2. メモ帳（または基本的なテキストエディタ）を開き、コードを貼り付けます。
  3. [ファイル]->[名前を付けて保存]に移動します
  4. ファイル名「example.html」を入力します（「ファイルの種類：すべてのファイル（。）」を選択します）
  5. EncodingasUTF-8を選択します
  6. [保存]をクリックすると、古い.htmlファイルを削除できるようになり、エンコーディングを修正する必要があります
于 2012-07-04T08:43:44.650 に答える
14

問題： POSTリクエストで文字列を含む「£」をCRMシステムに 送信するという問題に直面していましたが、CRMからGET呼び出しを行うと、文字列の内容を含む「£」が返されていました。したがって、分析したのは、「£」が「£」に変換されていたということです。

分析： 調査を行った後に見つかった不具合は、POST呼び出しではHttpWebRequestContentTypeを"text / xml"として設定し、GETCallでは" text / xml; charset：utf-8"であったことです。

解決策：解決策 の一部として、POSTリクエストにcharset：utf-8を含め、機能します。

于 2015-09-24T04:46:53.917 に答える
3

私の場合、これ（注意を払って）は、コードを生成するための独自のツールを使用してVisualStudioから生成したコードで発生しました。解決するのは簡単でした：

ドキュメント内の単一のスペース（）を選択します。他の単一スペースとは異なって見える多くの単一スペースを見ることができるはずです、それらは選択されていません。これらの他の単一のスペースを選択してください-それらはブラウザの不要な文字の原因です。[検索して単一のスペースに置き換える]（）に移動します。終わり。

PS：カーソルを1つに置くか、VS2017 +で選択すると、類似するすべての文字が見やすくなります。他のIDEにも同様の機能があるといいのですが

于 2020-02-15T18:20:31.887 に答える
-1

私の場合、ページがUTF-8に正しくエンコードされていても、nbspではなくラテン十字記号が表示されていました。上記のどれも問題の解決に役立ちませんでした、そして私はすべてを試しました。

最終的に、IEのフォントを変更すると（ブラウザー固有のcssを使用）、Arialに変更することで問題が解決したボディフォントとしてHelvetica-Nueを使用していました。

于 2013-11-04T12:00:59.880 に答える
-2

この問題は、いくつかのWebサイトでも発生しました。必要なのは、HTMLエンティティのコンテンツフェトラーをカスタマイズすることだけです。その前に、私はそれらをより多く削除するので、ページのhtmlフィッターまたは解析関数を変更するだけで機能しました。これは主に、ほとんどのCMSのHTMLエディターによるものです。それらがデータを解析するために保存する方法がこの問題を引き起こしました（私の場合）。これがあなたの場合にも役立つかもしれません

于 2016-03-25T04:01:26.487 に答える
-3

私も同じような問題を抱えていました。どうやらそれはPHPがutf-8を認識しないからです。

DreamWeaverでは問題ないように見えたにもかかわらず、「£」記号が「£」として表示され続けたとき、最初は髪を引き裂いていました。最終的には、ページを直接表示した場合はスライドショーで機能するが、インクルードで使用した場合は機能しない場合に、インデックスファイルに関連するリンクに問題があったことを思い出しました（ただし、それは重要ではありません。とにかく、これは同様の問題なので、問題が発生していたページに配置する代わりに、index.phpファイルに配置するだけです。問題は全体的に修正されています。

于 2013-12-16T20:17:33.120 に答える
-3

この理由は、PHPがutf-8を認識しないためです。

ここでは、HTMLのすべての特殊文字を確認できます

http://www.degraeve.com/reference/specialcharacters.php

于 2014-06-05T13:50:50.123 に答える