0

UTF-8SqlAlchemy からの接続を除いて、すべてのテーブル/フィールドと文字セット設定が である MySQL セットアップがあります。

最近、接続文字セットをどこでもUTF-8使用できるように変更しました。UTF-8

この設定を変更すると、DB 内の古い値が次のように正しく表示されません。

Björn => Björn

これは問題ありません。Python でエンコード メソッドを使用して、値を収集してエンコードし、再び元に戻します。

この問題は、設定の変更後に挿入された、既に正しい値を変換しようとすると発生します。

値をエンコードする必要があるかどうかを判断する良い方法はありますか?

4

1 に答える 1

0

あなたの古いエンコーディングは、おそらくラテン語 1 でしたか?

文字列が UTF-8 ではなく Latin-1 でエンコードされた時期は、連続するバイトを調べることでおそらく検出できます。UTF-8 標準には、テキストの一部が Latin-1 または UTF-8 でエンコードされているかどうかを検出するために使用できる、独特のコードページ レイアウトがあります。

  • 00 ～ 7F の範囲のバイトはすべて安全です。もちろん、これらは ASCII 値であり、これらのコードポイントは 2 つのエンコーディング間で一致します。ここには助けはありません、助けは必要ありません。

  • バイト C0、C1、および F5-FF は、UTF-8 エンコーディングでは無効です。これらを含む文字列は、Latin-1 でエンコードする必要があります。

  • C2-DF の範囲のバイトの後には、80-BF の範囲のバイトが続く必要があります。これに一致しない 2 バイトがある場合は、Latin-1 でエンコードされた文字列が手元にある可能性があります。

これまでにエンコードしたのが Latin-1 文字 (Unicode コード ポイント 255 まで) だけである場合は、ここで終了できます。E0 から FF の範囲のバイトを含むものはすべて、古い Latin-1 データになります。

切り替えてから UTF-8 でデータを追加した場合、それは Latin-1 の範囲外です。次のルールも含める必要があります。

  • E0 ～ EF の範囲のバイトは、3 バイトの UTF-8 文字を示します。次の 2 バイトは、再び 80 ～ BF の範囲に収まる必要があります。

3 UTF-8 バイト データはBMPの残りの部分をカバーします。これ以外でエンコードすることはほとんどありません。ただし、これ以外でエンコードする場合は、次を探します。

  • F0 ～ F4 の範囲のバイトの後には、80 ～ BF の範囲の正確に 3 バイトが続く必要があります。

これらの基準がすべて一致する場合、文字列はおそらくUTF-8 ですが、100% 確実というわけではありません。それらのいずれかが一致しない場合は、間違いなく Latin-1 文字列を持っています。しかし、Latin-1 コードポイント C2-DF の後にコードポイント 80-BF が続く可能性はほとんどありません。後者のほとんどは制御コードか、より難解な分音記号であるためです。おそらく、複数の 2 バイト UTF-8 シーケンスを探して信頼スコアを上げることで、さらに絞り込むことができます。

したがって、結論として (tl;dr):マルチバイト シーケンスを調べることで、Latin-1 でエンコードされたほとんどの文字列を見つけることができます。それらが厳格な UTF-8 基準に該当しない場合は、Latin-1 文字列が手元にあります。

于 2012-08-14T09:59:27.873 に答える