1

そこで、 nokogiriを使用して特定のサイトのスクリーンスクレイピングを実行しようとしていますが、サイトの所有者は<meta>タグでページの適切なエンコーディングを指定できませんでした。その結果、utf-8であると思われる文字列を処理しようとしていますが、実際にはそうではありません。

（気になる場合は、これをテストするために使用したファイルは次のとおりです。

）。

多くの検索を行った後（このSOの質問encode('iso-8859-1', 'utf-8')は特に役に立ちました）、適切な©記号を取得するという点で、そのテスト文字列を呼び出すと「機能する」ことがわかりました。ここでの問題は、ラテン語のエンコーディングに変換する際に実際には機能しない、他の文字列に他の文字が含まれていることです（Shōtaたとえば、になりますSh�\x8Dta）。

今、私はおそらく適切なウェブマスターを悩ませて、彼らに彼らのいまいましいエンコーディングを修正してもらうつもりですが、それまでの間、私は私が持っているバイトを使用できるようにしたいと思います。方法があることはかなり確信していますが、それが何であるかを一生理解することはできません。

4

2 に答える 2

1

これらのページは、UTF-8として正しくエンコードされているようです。これが私のブラウザでの表示方法です。ビューソースを作成し、エディタにUTF-8としてデコードするように指示すると、問題なく表示されます。私が見る唯一の問題は、一部の著作権記号がコンテンツに追加される前（または追加されたとき）に破損しているように見えることです。o-macronおよびその他の非ASCII文字は問題なく通過します。

あなたがこれを知っているかどうかはわかりませんが、ページのエンコーディングをクライアントに通知する適切な方法は、ヘッダーを使用することです。ページにはその情報がタグに含まれている場合があり<meta>ますが、それは必須でも期待でもありません。ヘッダーが存在する場合、ブラウザは通常、そのようなタグを無視します。

ページはXHTMLであるため、XML処理命令にエンコード情報を埋め込むこともできますが、必須ではありません。ただし、これは、NokogiriにHTMLではなくXMLとして処理させることができることを意味します。その場合、デフォルトでUTF-8を使用することを期待します。でも、のこぎりはよくわからないので、よくわかりません。そしてとにかく、ヘッダーはまだ最終的な権限です。

于 2010-03-01T01:41:04.730 に答える
1

したがって、問題は、ANNがヘッダーを介したエンコードのみを指定し、Nokogiriがopen（）関数からヘッダーを受け取らないことです。したがって、Nokogiriは、ページがラテン語でエンコードされていると推測し、元の文字を元に戻すために実際に反転できない文字列を生成します。

Nokogiri :: HTML（）の3番目のパラメーターとしてNokogiriのエンコードを指定できます。これにより、最初に解決しようとしていた問題が解決されます。したがって、私が尋ねたより具体的な質問（ラテン文字列からこれらの非ラテン文字を取得する方法）は答えられませんが、この答えを受け入れます。

于 2010-03-03T22:17:30.750 に答える