0

約 3 GB の巨大なファイルである MySQL バックアップ ファイルがあります。JPEG 画像データを格納する LONGBLOB 列を持つテーブルが 1 つあります。

MySQL Workbench - Data Import/Restore から実行した場合、ファイルは正常にインポートされます。

別のプログラムがこのデータを別の MySQL データベースにインポートできるかどうかをテストできるように、このファイルを開いて最初の数行 (画像データを含むテーブルの INSERT の約 2 行) を抽出する必要があります。

EmEditor (大きなファイルを開くのに適しています) でファイルを開いてから、スクリプトの Insert ステートメントを 1 つだけ新しいファイルにコピー/貼り付けしてみました (問題のテーブルが最初のテーブルであるため、25 行目まで)。バックアップ スクリプト)、選択内容を新しいファイルに貼り付けます。

問題は次のとおりです。

ただし、これはエンコーディングを台無しにします（utf8として保存しても）。この新しいファイルを (再び MySQL Workbench を使用して) MySQL データベースにインポート (復元) しようとすると、復元はエラーなしで続行されますが、blob 列の JPEG 画像は現在破棄/破損しています。

私の推測では、元のファイルと新しいファイルの間でエンコーディングが異なっています。

EmEditor は元のファイルのエンコーディングを表示しません。検出するオプションがあり、'UTF8 Unsigned' として検出します。ただし、保存するときはUTF8で保存します。ANSI、ISO8859（Windowsのデフォルト）などとしても保存しようとしましたが、毎回同じ結果です。

この特定の問題に対する解決策はありますか? つまり、画像 (ブロブ) が変更されないように、巨大なバックアップ ファイルの最初の数行だけを切り取り、同じエンコーディングを維持したまま新しいファイルに保存したいと考えています。これを EmEditor で行う方法はありますか (つまり、間違ったアプローチ [つまり、カット アンド ペースト] を使用していますか?) これを行うことができる専用のソフトウェアはありますか? ここで何が問題なのかをどのように診断できますか?

返信ありがとうございます。

4

2 に答える 2

0

これはエンコーディングを台無しにします（utf8として保存しても）

UTF-8 は、任意のバイナリ データには適していません。UTF-8 では無効な上位バイトのシーケンスが多数あるため、ロード-変更-保存プロセス中のある時点でそれらをマングルします。

すべての単一バイトを一意の文字にマップするエンコーディングを使用してファイルをロードし、同じエンコーディングを使用してファイルを再保存する場合は、元のコンテンツを保持する必要があります(*)。ISO-8859-1 は、各バイト 0..0xFF を同じ番号の Unicode コード ポイントに単純にマップするため、この目的で通常選択されるエンコーディングです。

\n(*: null や/やその他の制御文字のような他のトリッキーな点に関して、エディターがバイナリセーフであると仮定し\rます... EmEditor はそうであると私は信じています。)

于 2011-07-12T21:28:09.863 に答える
0

元のファイルを EmEditor で開いたときに、エンコードを Binary (ASCII View) にしてみました。バイナリ (ASCII ビュー) は、ボビンスが言ったように、各バイトを一意の文字にマップし、ファイルを保存するときにそれを保持します。これで問題が解決すると思います。

于 2011-08-01T21:54:09.723 に答える