Доброго времени суток.

Такая проблема возможна, так как в Windows и Linux почти наверняка кодировки используемые по умолчанию различны.

mysqldump сливает файл в кодировке текущего окружения, по умолчанию. В моей практике был случай, когда слитый файл остался единственной копией базы, и повторить процедуру резервирования было уже невозможно.

Для того, чтобы выйти из ситуации, мне пришлось выяснить, что во всех случаях mysqldump устанавливает в качестве параметра utf8, даже если кирилица набрана cp1251.

Открываем файл дампа, и в самом начале можем видеть нечто подобное:

-- MySQL dump 10.9
--
-- Host: localhost Database: db_oslinux
-- ------------------------------------------------------
-- Server version 4.1.25-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

Обратите внимание на строку

/*!40101 SET NAMES utf8 */;

Вот тут то и скрыта проблема. utf8 заменим на cp1251. База восстановится без сбоев.

Еще, не пытайтесь открывать графическими редакторами большие файлы. Для них это не по силам. mcedit (только для linux) справляется прекрасно.

ога, интересно