Проблемы с кодировкой при импорте 23Mb .sql файла в MySQL через phpMyAdmin

Question

Когда я импортирую следующий файл .sql (вставлено 4 записи)

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";


/*!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 */;

CREATE TABLE IF NOT EXISTS `sentences` (
  `jp` text character set utf8 collate utf8_unicode_ci,
  `eng` text character set utf8 collate utf8_unicode_ci,
  `reading` text character set utf8 collate utf8_unicode_ci,
  `query` varchar(50) character set utf8 collate utf8_unicode_ci default NULL,
  `patternIDs` varchar(100) character set utf8 collate utf8_unicode_ci default NULL,
  `hasImage` tinyint(1) NOT NULL,
  `imageURL` varchar(100) character set utf8 collate utf8_unicode_ci NOT NULL,
  `id` int(11) NOT NULL auto_increment,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=eucjpms;

INSERT INTO `sentences` (`jp`, `eng`, `reading`, `query`, `patternIDs`, `hasImage`, `imageURL`, `id`) VALUES
('ムーリエルは２０歳になりました。', 'Muiriel is 20 now.', 'はにぜろさいになりました。', 'ムーリエル', '64', 0, 'none', 1),
('すぐに戻ります。', 'I will be back soon.', 'すぐにもどります。', 'すぐ', '4', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=959017328936&id=b33b9daf539756a8b0b2364f63088008', 2),
('すぐに諦めて昼寝をするかも知れない。', 'I may give up soon and just nap instead.', 'すぐにあきらめてひるねをするかもしれない。', '昼寝', '19', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=888895375610&id=5debb6afed90989674d447f9493b4a1d', 3),
('ログアウトするんじゃなかったよ。', 'I shouldn\'t have logged off.', 'ログアウトするんじゃなかったよ。', 'ログアウト', '16', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=846535990996&id=4e0ad521154e2e7456330af87b24ee71', 4);

, а затем просматриваю таблицу предложений, все предложения на японском языке можно просматривать без проблем в кодировке UTF-8.Однако, когда я импортирую следующий файл (точно так же, единственная разница в размере, вставлено ~ 73000 записей, а не 4)

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";


    /*!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 */;

    CREATE TABLE IF NOT EXISTS `sentences` (
      `jp` text character set utf8 collate utf8_unicode_ci,
      `eng` text character set utf8 collate utf8_unicode_ci,
      `reading` text character set utf8 collate utf8_unicode_ci,
      `query` varchar(50) character set utf8 collate utf8_unicode_ci default NULL,
      `patternIDs` varchar(100) character set utf8 collate utf8_unicode_ci default NULL,
      `hasImage` tinyint(1) NOT NULL,
      `imageURL` varchar(100) character set utf8 collate utf8_unicode_ci NOT NULL,
      `id` int(11) NOT NULL auto_increment,
      PRIMARY KEY  (`id`)
    ) ENGINE=MyISAM  DEFAULT CHARSET=eucjpms;

    INSERT INTO `sentences` (`jp`, `eng`, `reading`, `query`, `patternIDs`, `hasImage`, `imageURL`, `id`) VALUES
    ('ムーリエルは２０歳になりました。', 'Muiriel is 20 now.', 'はにぜろさいになりました。', 'ムーリエル', '64', 0, 'none', 1),
    ('すぐに戻ります。', 'I will be back soon.', 'すぐにもどります。', 'すぐ', '4', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=959017328936&id=b33b9daf539756a8b0b2364f63088008', 2),
    ('すぐに諦めて昼寝をするかも知れない。', 'I may give up soon and just nap instead.', 'すぐにあきらめてひるねをするかもしれない。', '昼寝', '19', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=888895375610&id=5debb6afed90989674d447f9493b4a1d', 3),
    ('ログアウトするんじゃなかったよ。', 'I shouldn\'t have logged off.', 'ログアウトするんじゃなかったよ。', 'ログアウト', '16', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=846535990996&id=4e0ad521154e2e7456330af87b24ee71', 4)
('先生に質問したら、すぐに答えてくれました。', 'When I asked a question to my teacher, he/she immediately answered it.', 'せんせいにしつもんしたら、すぐにこたえてくれました。', '先生', '64, 189', 1, 'http://ts1.mm.bing.net/images/thumbnail.aspx?q=889488746606&id=53a411907232964b30b9ebde03093a66', 73660),
('薬を飲んだら、すぐになおりました。', 'I took a medicine, and soon recovered.', 'くすりをのんだら、すぐになおりました。', '薬', '19, 64, 189', 1, 'http://ts2.mm.bing.net/images/thumbnail.aspx?q=934254550695&id=4400863ae021a4827dd7f9f7380fc2a2', 73661);

Я не вижу японские символы.Это почему?Почему phpMyAdmin имеет проблемы с кодировкой при импорте больших файлов .sql?Спасибо, ребята!

Answer 1

Существует много трудностей, которые могут возникнуть из-за используемого языка и кодировки.В http://www.herongyang.com/PHP-Chinese/ имеется неоценимый источник информации специально для китайских вопросов, и многие обсуждения будут также применяться к любому Юникоду, включая японский.

Например, Херон Ян дает возможный поток:

H1.Последовательности клавиш -> с клавиатуры (текстовый редактор) ->H2.HTML-документ -> (веб-сервер) ->H3.HTTP Response -> (Интернет TCP / IP-соединение) ->H4.HTTP Response -> (Веб-браузер) ->H5.Визуальные символы на экране

В основном вам необходимо убедиться, что на каждом этапе процесса импорта (и процесса вывода) нет никаких проблем.Первый шаг - это " искаженные данные на phpmyadmin wiki ", указанные Плебсори.К сожалению, эта вики иллюстрирует некоторые проблемы, но я думаю, что нет решений.

Я бы начал с проверки того, что кодировка двух файлов .sql абсолютно одинакова.Чтобы проверить, вы можете отредактировать 73 000 файлов ввода с помощью Notepad ++ и удалить все, кроме первых четырех строк.Некоторые текстовые редакторы могут изменять кодировку во время процесса сохранения, делая кодировку двух файлов разной, даже если они выглядят одинаково.Поэтому убедитесь, что вы сохраняете оба файла одинаково.Для китайского я бы часто использовал Notepad ++, чтобы изменить кодировку файла.Убедитесь, что файлы .sql сохранены в той же кодировке.Кодирование так важно, поэтому notepad ++ имеет его как одно из меню в строке меню.

Еще одна проблема, которая может возникнуть с файлами, - это маркер спецификации в начале текстового потока.http://en.wikipedia.org/wiki/Byte-order_mark. Эта невидимая метка - то, что PHPmyAdmin может использовать для определения языка конвертации.Опять же, я бы использовал notepad ++, чтобы гарантировать наличие спецификации.(Кодировка меню).Вы также можете использовать, потому что копирование / вставка может изменить кодировку (TextFX> TextFX Viz Settings> Viz Copy-Cut также в Unicode).

Наконец, в цепочке все еще много ссылок.Хорошо, что как только вы поймете, как правильно вводить и выводить данные, сохраняя язык, тогда будет довольно просто сделать это позже.Кстати, если вы попробуете совет по кодированию, который я предложил, и убедитесь, что форматы файлов не являются источником проблемы, то есть некоторые приемы для импорта данных.Вы можете преобразовать UTF8 в ascii (будет выглядеть как символы мусора), импортировать его, а затем преобразовать обратно в кодировку, которую вы хотите внутри sql.

Answer 2

Вот несколько советов, которые могут помочь.

Я бы посоветовал вам подтвердить, что вы можете отправить файл размером 23 Мб на сервер.Конфигурационный файл PHP имеет ограничение на размер сообщения.

Я бы также посоветовал вам подтвердить, что время выполнения php max не нарушено и что импорт не завершается досрочно.

Может быть, вы могли бы импортировать файл SQL из командной строки

mysql -u {username} -p{password} -h {serverHost} {databaseName} < {fileName}.sql

Answer 3

Вы достигли ограничения по времени / размеру сервера, и phpmyadmin достаточно умен (или нет), чтобы продолжить с того места, где он остановился (приблизительно), поскольку команда кодирования находится в начале файла, когда начинается второе соединение, он не имеет никаких настроек кодирования.
Решение: либо поместите команду кодирования каждые несколько сотен строк, либо используйте импорт файла

импорт файла в Ubunto:

sudo mysql -u [user name] -p [database name] < [sql file name]
[ubunto root password]
[mysql password]