HTMLエンコードの問題-「＆nbsp;」ではなく「Â」文字が表示される

203

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

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

  1. 置き換えられるトークンが含まれているDBからHTMLテンプレートをプルします（「〜CompanyName〜」、「〜CustomerName〜」など）
  2. トークンを実際のデータに置き換える
  3. HTMLタグの属性値をプロパティでフォーマットする単純な正規表現関数を使用してHTMLを整頓します（ActivePDFのレンダリングエンジンは属性値を一重引用符で囲んでいないため、引用符などを保証します）。
  4. PDFを作成するWebサービスにHTMLを送信します。

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

私の質問：問題の原因がわからず、問題を調査する時間がないので、問題のある文字を再エンコードまたは検索して置き換える簡単な方法はありますか？私は一緒に投げたこの小さな関数を使って送信してみましたが、すべてを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
html  vb.net  encoding  utf-8  iso-8859-1 
— Cᴏʀʏ
ソース
2
HTMLには、その文字セットを説明するメタ情報が含まれていますか？
— Rowland Shaw
1
[以前のコメントは削除されました]短い答え：いいえ。
— Cᴏʀʏ
1
私にとっては：utf8_decode（）
— ursuleacv 2017

回答:

340

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

その場合は、ISO-8859-1ではなく、UTF-8にエンコードされます。非改行スペース文字は、ISO-8859-1のバイト0xA0です。UTF-8にエンコードすると、0xC2,0xA0になります。ISO-8859-1として（誤って）表示すると、として出力され" "ます。これには、気付かないかもしれない末尾のnbspが含まれます。そのバイトがそこにない場合は、別の何かがあなたの文書を悪用しているため、何を見つけるためにさらに調べる必要があります。

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

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

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

それを行った場合、残っている問題はActivePDFのせいです。

— ボビンス
ソース
20
<meta charset="utf-8">まだお勧めしません。このhttp-equivバージョンは引き続きHTML5で有効であり、サポートが強化されています。
— ボビンス2012
8
どちらを使用するかの回答：<meta charset = 'utf-8'>と<meta http-equiv = 'Content-Type'は、ショートバージョンが十分にサポートされていることを示しています。
— Richard Ayotte
1
別のソースが見つかりましたこれはすべてのブラウザで機能します
— Richard Ayotte
最新のすべてのブラウザで動作します。確かに、すべてのレガシーブラウザやニッチ（モバイルなど）のブラウザ、またはすべてのスパイダーでは機能しません。
— ボビンス
3
「その混乱のどこかに」... LOL！ナイスオープン！いい答えだ！+1
— レジストデザイン
24

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

  1. .htmlファイル内のすべてのコードをコピーします。
  2. メモ帳（または任意の基本的なテキストエディター）を開き、コードを貼り付けます。
  3. 「ファイル->名前を付けて保存」に移動します
  4. ファイル名「example.html」を入力します（「ファイルの種類：すべてのファイル（。）」を選択します）
  5. UTF-8としてエンコードを選択
  6. [保存]をクリックすると、古い.htmlファイルを削除できます。エンコードは修正する必要があります
— 低
ソース
2
これでうまくいきました。今では崇高にそれはのUTF-8 with BOM代わりに言いますUTF-8。これを崇高なテキストで表示show_encodingするにtrueは、[設定]-[ユーザー]でに設定する必要があります。
— J86 2013
：私はÂを示す代わりに»、AMDこのソリューションを使用すると、問題が解決したが、PHPの警告があることが問題だった Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at D:\Program Files\wamp\wamp\www\projects\kerala\kerala_public_html\edit\business_details.php:1) in D:\Program Files\wamp\wamp\www\projects\kerala\kerala_public_html\user\include\fg_membersite.php on line 152
— SCC
この解決策は私にとってうまくいきました。私はメモ帳++で作業していて、それを基本的なmsメモ帳にUTF-8として保存したときに、メモ帳++で新しいファイルを開いた後、エンコーディングはUTF-8-BOMに設定されました（これはどういう意味かわかりません）。とにかく、それが私の問題だったようです。
— BoltKey 2017年
ありがとうございました！これでうまくいきました。リクエスト/レスポンスで、ファイル（私の場合はASPX）がUTF-8としてエンコードされていることがわかります。Notepad ++でもUTF-8にエンコードされていました。一体何なんだよね？しかし、あなたは解決策でトリックをしました。私にとっては、ページで適切にエンコードされていないスペイン語のフレーズでした。スペイン語にUTF-8 BOMを使用しないように他の場所を読みましたが、修正されました。
— user3621633
13

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

分析： 調査の結果判明した問題は、POST呼び出しではHttpWebRequest ContentTypeを「text / xml」に設定しているのに対し、GET呼び出しでは「text / xml; charset：utf-8」でした。

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

— ヒマンシュタルソリヤ
ソース
0

私の場合、これ（キャレット付き）は、コードを生成するための独自のツールを使用してVisual Studioから生成したコードで発生しました。解決は簡単でした：

ドキュメント内の単一のスペース（）を選択します。他のシングルスペースとは異なって見える多くのシングルスペースを確認できるはずです。それらは選択されていません。これらの他の単一のスペースを選択します-それらは、ブラウザ内の不要な文字の原因となるものです。「検索して単一のスペースで置換する（）」に進みます。できました。

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

— ハニントン・マンボ
ソース
-1

私の場合、ページがUTF-8に正しくエンコードされていたとしても、nbspではなくラテン語のクロス記号が表示されていました。上記のいずれも問題の解決に役立たなかったので、すべて試しました。

最終的にIEのフォントの変更（ブラウザー固有のCSSを使用）が役立つので、Arialに変更する本文フォントとしてHelvetica-Nueを使用して問題を解決しました。

— モヒカ
ソース
フォントを切り替えると効果がある場合があるのは、フォントの1つに問題の文字が含まれていないため、代わりに空の文字が表示されたためと考えられます。しかし、これは問題を解決しませんでした。
— Oliver Hausler、
-2

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

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

— フォーパート
ソース
-2

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

— JK-ライダー
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.