4

MySQL 3.23.58 データベースを、5.5.19 を実行している別のサーバーに移動しようとしています。

古いものにはlatin1エンコーディングが指定されており、基礎となるデータが実際に正直にlatin1であると私が知る限り。私は多くのことを試しましたが、主に次のとおりです。

  • mysqldump と latin1 エンコーディング フラグを使用してターミナルからエクスポートします。
  • MySQL 5 との互換性のために、vim で編集して「TYPE=InnoDB」を「ENGINE=InnoDB」に変更します。
  • ターミナルから新しいサーバーにインポートします。

古いサーバー (Mac の Sequel Pro または PC の MySQL Query Browser) を参照すると、特殊文字が常に正しく表示されるとは限りませんが、そこにはあります (バイナリを 16 進数で調べます)。(いずれにせよ、PHP Web アプリで動作します。)

新しいサーバーをブラウズすると、すべての特殊文字が疑問符に置き換えられたように見えます。間違ったエンコーディングを指定すると、特殊文字が疑問符 (または �) として表示されることがあります。しかし、これらは、バイナリ レベルで正真正銘のエンコードされた ASCII クエスチョン マークであるように見えます。特殊文字 (主に波状の引用符とダッシュ) は、エクスポート/インポートで失われたか、破棄されたようです。

理由はありますか？

エンコーディングにはさまざまな問題があり、さまざまな問題が発生する可能性があることを私は知っています。私はこれについて数日間（ここと他の場所で）読んでいて、すべての適切な文字エンコーディングを設定しようと試み、UTF-8を試し、キャストと変換を試み、Sequel Proのエクスポート/インポートを試みました（端末ではなく）など。私は困惑しています。

4

1 に答える 1

2

問題が絞り込まれたようです。この投稿を見つけました

テキスト エディタが vim の場合、"<92>" は拡張 ASCII 文字の 16 進コードです。この場合、それは Hex(92) または Oct(222) または Dec(146) であり、これは「右の単一引用符」です。ASCII Dec コード 39 である「一重引用符」と混同しないでください。

ファイルからすべての非 ASCII 文字を削除する 1 つの方法は次のとおりです。

perl -plne 's/[^[:ascii:]]//g' <your_file>

それ以外の場合は、エクスポートされたファイル内の "<92>" と "<97>" を検索して適切な文字に置き換えます。

[編集]

私は VIM ユーザーではありませんが、この投稿では <92> スマート クォート文字を置き換える問題に対処しています

ファイルに表示される各値に対して、次のように文字列置換を行うだけです。

:%s/<93>/\’/g

もちろん、そこに <93> を入力することはできません。

CTRL-V×93

hex 93 を所定の位置に挿入します。

最近 Excel からエクスポートした CSV で、16 進数 91-97 を見ました。

于 2012-06-26T09:35:50.860 に答える