web-dev-qa-db-ja.com

ページに「」ではなく「’」が表示される

’の代わりに'がページに表示されます。

Content-TypeタグとHTTPヘッダーの両方でUTF-8を<head>に設定しています：

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

enter image description here

さらに、私のブラウザーはUnicode (UTF-8)に設定されています。

enter image description here

それで、問題は何ですか、どうすれば修正できますか？

encodingutf-8mojibake
112
Jitendra Vyas

ブラウザとエディターがISO-8859-1/Windows-1252の代わりにUTF-8エンコードを使用していることを確認してください。

または、&rsquo;を使用します。

48
kennytm

だから問題は何ですか、

これは、 TF-8 ではなく CP-1252 としてエンコードされた’（ RIGHT SINGLE QUOTATION MARK -U + 2019）文字です。 encodings テーブルを確認すると、この文字は0xE2、0x80、および0x99バイトで構成されるUTF-8であることがわかります。 CP-1252コードページレイアウト を確認すると、これらの各バイトが個々の文字â、€、および™を表していることがわかります。

どうすれば修正できますか？

CP-1252の代わりにUTF-8を使用して、文字の読み取り、書き込み、保存、表示を行います。

<head>タグとHTTPヘッダーの両方でContent-TypeをUTF-8に設定しています：

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

これは、文字の解釈と表示に使用するエンコードをクライアントに指示するだけです。これは、文字の読み取り、書き込み、保存、表示に使用するエンコードを独自のプログラムに指示するものではありません。正確な答えは、使用するサーバー側プラットフォーム/データベース/プログラミング言語によって異なります。 HTTP応答ヘッダーに設定されているものは、HTMLメタタグよりも優先されることに注意してください。 HTMLメタタグは、ページがHTTPではなくローカルディスクファイルシステムから開かれた場合にのみ使用されます。

さらに、私のブラウザーはUnicode (UTF-8)に設定されています。

これは、文字の解釈と表示に使用するエンコードをクライアントに強制します。しかし、実際の問題は、’ではなく’（UTF-8でエンコードされた）を既にクライアントに送信していることです。クライアントは、UTF-8エンコードを使用して’を正しく表示しています。クライアントがISO-8859-1などの使用を誤って指示された場合、代わりにââ¬â¢が表示される可能性があります。

データベースでASP.NET 2.0を使用しています。

これは、問題が存在する可能性が最も高い場所です。独立したデータベースツールを使用して、データがどのように見えるかを確認する必要があります。

’文字がある場合、データベースに正しく接続していません。データベースコネクタにUTF-8を使用するように指示する必要があります。

データベースに’が含まれている場合、台無しになっているのはデータベースです。ほとんどの場合、テーブルはUTF-8を使用するように構成されていません。代わりに、データベースのデフォルトのエンコーディングを使用しますが、これは構成によって異なります。これが問題である場合、通常はUTF-8を使用するようにテーブルを変更するだけで十分です。データベースがそれをサポートしていない場合は、テーブルを再作成する必要があります。テーブルを作成するときに、テーブルのエンコーディングを設定することをお勧めします。

ほとんどの場合、SQL Serverを使用していますが、ここにいくつかのMySQLコードがあります（ この記事 からコピー）：

CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;

ただし、テーブルがすでにUTF-8である場合は、一歩後退する必要があります。 Whoまたはwhatそこにデータを置きます。 それは問題の場所です。 1つの例は、誤ってエンコード/デコードされたHTMLフォーム送信値です。

問題について詳しく知るためのリンクを次に示します。

198
BalusC

…が…として表示され、êがêとして表示されていたドキュメントがいくつかあります。これがそこに到達した方法です（pythonコード）：

# Adam edits original file using windows-1252
windows = '\x85\xea' 
# that is HORIZONTAL Ellipsis, LATIN SMALL LETTER E WITH CIRCUMFLEX

# Beth reads it correctly as windows-1252 and writes it as utf-8
utf8 = windows.decode("windows-1252").encode("utf-8")
print(utf8)

# Charlie reads it *incorrectly* as windows-1252 writes a twingled utf-8 version
twingled = utf8.decode("windows-1252").encode("utf-8")
print(twingled)

# detwingle by reading as utf-8 and writing as windows-1252 (it's really utf-8)
detwingled = twingled.decode("utf-8").encode("windows-1252")

assert utf8==detwingled

この問題を修正するために、次のようなpythonコードを使用しました。

with open("dirty.html","rb") as f:
    dt = f.read()
ct = dt.decode("utf8").encode("windows-1252")
with open("clean.html","wb") as g:
    g.write(ct)

（誰かがきらめきバージョンを正しいUTF-8文書に挿入したため、実際にはきらきら部分のみを抽出し、それをほぐしてから挿入し直す必要がありました。これにはBeautifulSoupを使用しました。）

Webサーバーの構成が間違っているよりも、コンテンツ作成にチャーリーがいる可能性がはるかに高くなります。また、utf-8ドキュメントのwindows-1252エンコーディングを選択することで、Webブラウザーにページをきらめかせることもできます。 Webブラウザは、Charlieが保存したドキュメントを削除できません。

注：同じ問題は、windows-1252ではなく、他のシングルバイトコードページ（例：latin-1）でも発生する可能性があります。

14
Terrel Shumway

’（UnicodeコードポイントU+2019 RIGHT SINGLE QUOTATION MARK）はUTF-8でバイトとしてエンコードされます。

0xE2 0x80 0x99。

’（UnicodeコードポイントU+00E2 U+20AC U+2122）は、UTF-8でバイトとしてエンコードされます。

0xC3 0xA20xE2 0x82 0xAC0xE2 0x84 0xA2。

これらは、UTF-8として処理されたときに’を生成するためにブラウザが実際に受信するバイトです。

これは、ソースデータがブラウザに送信される前にtwo charset変換を経ていることを意味します。

  1. ソース’文字（U+2019）は最初にUTF-8バイトとしてエンコードされます。

    0xE2 0x80 0x99

  2. これらの個々のバイトはmis-interpretedであり、Windows-125Xcharsets（1252、1254）のいずれかによってUnicodeコードポイントU+00E2 U+20AC U+2122にデコードされていました、1256、および1258はすべて0xE2 0x80 0x99をU+00E2 U+20AC U+2122にマップし、それらのコードポイントはUTF-8バイトとしてエンコードされます。

    0xE2-> U+00E2-> 0xC3 0xA2
    0x80-> U+20AC-> 0xE2 0x82 0xAC
    0x99-> U+2122-> 0xE2 0x84 0xA2

手順2で余分な変換が実行されている場所を見つけて、削除する必要があります。

11
Remy Lebeau

文字エンコードに不一致があります。文字列は1つのエンコード（UTF-8）でエンコードされ、このページを解釈するものはすべて別のエンコード（ASCIIなど）を使用しています。

常にHTTPヘッダーでエンコーディングを指定し、これがフレームワークのエンコーディングの定義と一致することを確認してください。

サンプルHTTPヘッダー：

Content-Type    text/html; charset=utf-8

asp.netでのエンコーディングの設定

<configuration>
  <system.web>
    <globalization
      fileEncoding="utf-8"
      requestEncoding="utf-8"
      responseEncoding="utf-8"
      culture="en-US"
      uiCulture="de-DE"
    />
  </system.web>
</configuration>

jspでのエンコーディングの設定

8
David Waters

これは、文字列がWindows-1252からUTF-8twiceに変換されるときに発生することがあります。

これは、おそらく正しい文字セットを指定していないMySQL接続が原因で、そのような文字がデータベースに表示されるZend/PHP/MySQLアプリケーションでこれを行いました。私たちは：

  1. ZendとPHPがUTF-8でデータベースと通信していることを確認します（デフォルトではnotでした）

  2. このようないくつかのSQLクエリで壊れた文字を修復します...

    UPDATE MyTable SET 
MyField1 = CONVERT(CAST(CONVERT(MyField1 USING latin1) AS BINARY) USING utf8),
MyField2 = CONVERT(CAST(CONVERT(MyField2 USING latin1) AS BINARY) USING utf8);

    必要な数のテーブル/列に対してこれを行います。

必要に応じて、PHPでこれらの文字列の一部を修正することもできます。文字がエンコードされているためtwiceであるため、実際には逆変換fromUTF-1からWindows-1252に戻ると、最初は混乱しました。

mb_convert_encoding('’', 'Windows-1252', 'UTF-8');    // returns ’
7
Simon East

コンテンツタイプがすでにUTF8である場合、データがすでに間違ったエンコーディングで到着している可能性があります。データベースからデータを取得する場合は、データベース接続がUTF-8を使用していることを確認してください。

これがファイルのデータである場合、ファイルがUTF-8として正しくエンコードされていることを確認してください。これは通常、選択したエディターの「名前を付けて保存...」ダイアログで設定できます。

ソースファイルで表示したときにデータが既に破損している場合は、以前はUTF-8ファイルでしたが、途中で間違ったエンコーディングで保存された可能性があります。

7
Pekka 웃

誰かがWordPressウェブサイトでこのエラーを受け取った場合、wp-config db charsetを変更する必要があります。

define('DB_CHARSET', 'utf8mb4_unicode_ci');

の代わりに：

define('DB_CHARSET', 'utf8mb4');
4
Goran Jakovljevic