はい、変換されます。明日メールいたします!
PMを解放するには信頼レベル1に到達する必要がありますが、まだここでトピックを読む時間が不足しており、その条件を満たしていません。
こんにちは、私は DigitalOcean の Docker コンテナ上で動作しており、mybb をインポートしようとしています(このチュートリアルは Vbulletin 向けですが、Gemfile の扱いは似ています)。bundle install の段階でつまずいています:
こんにちは、
vBulletin 3.8 を Discourse へインポートしようと試みました。このスクリプトは、データベースサイズが 300MB、ユーザーが約 4 万人、投稿が 6 万件の場合には正常に動作します。しかし、インポート処理の最後に文字コードの問題に直面しました。
- 当社の vBulletin 3.8 は latin1 文字コードでエンコードされています。
----> インポートスクリプトを実行する際、Discourse の Docker 上で動作する MySQL 5.6 も UTF-8 文字コードに設定されています。 - インポートスクリプトは、データを UTF-8 に変換してインポートするよう強制しています。
そのため、インポート処理の終了時に Discourse フォーラムが UTF-8 エンコードエラーとしてデータを表示してしまいます。その様子は下の画像のようになります。
-
インポート前の vB 3.8
-
Discourse へのインポート後
試した対策:
- インポートスクリプトを実行する前に、vB 3.8 の文字コードを UTF-8 に変換
- この vB 3.8 データベースを新しい MySQL サーバーでテストしたところ、テキストは正常に表示され、エンコードエラーは発生しませんでした。
そこで、この場合のアドバイスをお願いできますでしょうか?
ご支援を心より感謝いたします(もし私の英語が理解しにくい場合は、大変申し訳ございません)
似たような問題を解決した一部を以下に示します:
### WIN1252 エンコーディング
win_encoded = ''
begin
win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
invalid: :replace, undef: :replace, replace: ""
).force_encoding('utf-8').scrub
rescue => e
puts "\n#{'-'*50}\nWin1252 で失敗しました \n\n#{raw}\n\n"
win_encoded = ''
end
raw = win_encoded
私の命を救っていただきありがとうございます。
簡単な方法として、ポスト Migrate a phpBB3 forum to Discourse - #540 by gerhard にある変換スクリプトを試しました。データベースの文字セットの問題を迅速に修正していただき、現在は完璧に動作しています。
アドバイスいただき、本当にありがとうございます。
vBulletin5 インポーターを使用して移行された方はいますか?将来的に利用する可能性があるため、すでに問題なく使用されたかどうか知りたいです。
vBulletin5 のインポートを行い、パーマリンク、いくつかの書式設定、そして記憶にない他の機能などを追加しました。PR を提出する予定ですが、まだ行われていません。
vb5 のデータベースダンプに添付ファイルが含まれています。Discourse にインポートすることはできますか?それとも、すべての添付ファイルをファイルとして持っている必要がありますか?
これについても混乱しています。添付ファイルは Discourse フォルダ内のどこにコピーすればよいのでしょうか?![]()
こんにちは、またお会いできて嬉しいです。
私の理解では、データベースからの添付ファイルは、同様にデータベース内に保存されているアバターと同じ方法で処理されるため、問題なく動作するはずです。
インポートは順調に進んでいますが、投稿の 91% でエラーが発生してしまいました😩
importing posts...
1425149 / 1564573 ( 91.1%) [1040 items/min] Traceback (most recent call last):
14: from script/import_scripts/vbulletin5.rb:726:in `<main>'
13: from /home/canapin/discourse/script/import_scripts/base.rb:47:in `perform'
12: from script/import_scripts/vbulletin5.rb:49:in `execute'
11: from script/import_scripts/vbulletin5.rb:300:in `import_posts'
10: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `batches'
9: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `loop'
8: from /home/canapin/discourse/script/import_scripts/base.rb:863:in `block in batches'
7: from script/import_scripts/vbulletin5.rb:320:in `block in import_posts'
6: from /home/canapin/discourse/script/import_scripts/base.rb:508:in `create_posts'
5: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
4: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
3: from /home/canapin/discourse/script/import_scripts/base.rb:509:in `block in create_posts'
2: from script/import_scripts/vbulletin5.rb:321:in `block (2 levels) in import_posts'
1: from script/import_scripts/vbulletin5.rb:450:in `preprocess_post_raw'
script/import_scripts/vbulletin5.rb:450:in `gsub': invalid byte sequence in UTF-8 (ArgumentError)
vbulletin のデータベースで、どの投稿が問題となっているか、その内容を確認するにはどうすればよいでしょうか?
これらを解決するために rescue を使う方法が誰かによって提案されていたので、その話題(このトピックか別のトピックかは覚えていませんが)に戻って探してみてください。問題を引き起こした id やテキストを出力するために rescue 内で put を使用することもできます。
エンコーディングに問題があります。
似たようなインポートでこれを使用しました(preprocess_post_raw に追加する必要があると思います)。
begin
win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
invalid: :replace, undef: :replace, replace: ""
).force_encoding('utf-8').scrub
rescue => e
puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
win_encoded = ''
end
こんにちは、
インポーターを修正し、以下のようにスクリプトを追加しました:
def preprocess_post_raw(raw)
return "" if raw.blank?
begin
win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
invalid: :replace, undef: :replace, replace: ""
).force_encoding('utf-8').scrub
rescue => e
puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
win_encoded = ''
end
# decode HTML entities
raw = @htmlentities.decode(raw)
# fix whitespaces
raw = raw.gsub(/(\\r)?\\n/, "\n")
.gsub("\\t", "\t")
UTF-8 の無効なバイト列の問題は、この部分で発生しています:raw = raw.gsub(/(\\r)?\\n/, "\n") .gsub("\\t", "\t")。
その後、インポーターを再起動しました。すでにインポートされているデータはスキップされますが、エラーを発生させる投稿に到達するまでに約6時間かかり、投稿コンテンツを確認するための期待される情報が追加されませんでした。
原因がわかりますか?
編集:
おそらく、エラーの原因となっている投稿の生コンテンツは以下の通りです:
I wonder if Billy is enjoying the parade.
Qwertyuiopasdfghjklzxcvbnm��
インポータースクリプトを修正して、以前の140万件の投稿を(本当に)スキップするように試みます。幸運を祈ってください。![]()
recent_data_onlyをインポートできるように、他の多くのインポーターにもimport_after設定を追加しました。私がどのように実装したか、他のインポーターを確認してみてください。
こんにちは、
ほぼすべての投稿をインポートできました!数十件を手動で修正し、UTF-8 エラーが発生するたびにインポートを再開しました… ![]()
さて、添付ファイル(VBulletin データベースに保存されています)をインポートする必要がありますが、うまくいきません。
プロセスが開始されると、約10〜20秒で RAM の使用量が急増し、以下のエラーが発生します:
importing attachments...
Failed to create upload: Cannot allocate memory - grep
Fail
私の RAM 使用状況:
私は Windows 10 上の Ubuntu 18 サブシステムで Discourse の開発版を使用しており、RAM は 16 GB です。
添付ファイルは、13 GB の vBulletin データベースから 7 GB を占めています。
なお、vbulletin5 インポーターを使用しています。
問題は、このクエリに起因しています:
SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
FROM #{DB_PREFIX}attach a
LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
このクエリを MySQL で実行すると、数秒で残りの RAM が一杯になってしまいます。
(解決策を見つけ、回避策を提供しているため、不要な情報や質問を削除して投稿を編集します)
回避策:
インポーターの SQL クエリに LIMIT と OFFSET を追加しました。20,000 件ずつ選択して添付ファイルをインポートしました:
uploads = mysql_query <<-SQL
SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
FROM #{DB_PREFIX}attach a
LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
LIMIT 20000 OFFSET 0
SQL
また、20,000 件のアップロードが完了した後、インポートスクリプトがさらに処理を続行しないように、uploads.each do |upload| ループの最後に exit を追加しました。
10,000 件のアップロードが完了したら、スクリプトを編集します(nano +353 ./scripts/import_scripts/vbulletin5.rb を使用して適切な行でファイルを開くことができます)。SQL クエリの OFFSET を 10,000 増やし、インポーターを再度実行します… これを 65,000 件の添付ファイルすべてに対して繰り返します。
添付ファイルのインポート中は、以下のエラーや警告に遭遇しました:
W, [2020-08-20T12:05:37.402860 #31042] WARN -- : Bad date/time value "0000:00:00 00:00:00": mon out of rangePost for 490451 not found(おそらく古い添付ファイルの参照切れ?)- EXIF データに関するいくつかのエラー
Failこれは私を困惑させ、インポートスクリプトを停止させました。最初の “Fail” を確認したところ、掲示板の添付ファイルが破損していました(ファイル名なし)。そのため、インポーターが “失敗” しても処理を続行できるようexit命令をコメントアウトしました。何も壊れないことを願って。
puts "Fail"
#exit
また、インポートを中断させるより厄介なエラーも発生しました:
1: from /usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:53:in `save!'
/usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:80:in `raise_validation_error':
Validation failed: Body is limited to 32000 characters; you entered 32323. (ActiveRecord::RecordInvalid)
幸い、このエラーは稀で、次に同じエラーが発生するまでこの添付ファイルをスキップするだけで済みました。65,000 件の添付ファイル全体で、おそらく十数回発生しました。SQL クエリの OFFSET を変更してインポートスクリプトを再起動するだけで対応できました。
こんにちは
カスタムフィールドの import_pass が、残りの 27,000 人のユーザーのうち約 400 人に存在しないことに気づきました(非アクティブなユーザー 154,000 人は削除済みです)。
なぜでしょうか?
フォーラムは 5 月に phpBB から vBulletin へ移行されました。それが原因でしょうか?
これらの 400 人のユーザーのパスワードをインポートして「修正」しようとは思いません(簡単な方法があるなら別ですが…)。大きな問題ではないので、単に気になったというだけです。
皆さん、こんにちは。
インポートした画像の縦横比が正しくないようです。投稿を再ベイク(リビルド)しない限り、この問題は解決しません。インポート時に正しい比率になるようにする方法を見つけたいのですが、再ベイクは避けたいです。
問題の詳細な説明:
私の理解では、Discourse が投稿を作成する際、インポートされた投稿は「ベイク」されていません(ただし、cooked フィールドは何かしらの方法で生成されます)。そのため、インポート処理は既存の Discourse 投稿をベイクする処理よりもはるかに高速です。
私の問題は、インポートされた画像の縦横比が正しくないことです。
インポートされた画像に関連する Discourse の生テキストの例:

「cooked」フィールドの内容:
<img src="https://d11a6trkgmumsb.cloudfront.net/original/3X/0/3/0379f53ed8221730ccb31807238e9c46e9fe1d37.jpeg" alt="SH-MUniFrame.JPG" data-base62-sha1="6Li1nnjbA8zDz6YJ3FqeYHV5zXK" width="517" height="500" class="d-lazyload">
投稿内での画像の表示例:
元の画像はこちら:
https://d11a6trkgmumsb.cloudfront.net/original/3X/f/7/f73a0ae8594219dd5a1620e59b3c17f9b02b1583.jpeg
vBulletin データベースから取得した元の画像サイズは以下の通りです:
select width, height from filedata where filedataid = 76237
+-------+--------+
| width | height |
+-------+--------+
| 600 | 800 |
+-------+--------+
私の推測では、height 属性は Discourse の設定(最大高さを 500px に制限)によって制約されているため、<img> タグの height 属性も同じ値(500)になっています。一方、width 属性は 600 から 517 へと何らかの理由で変更されていますが、それがどのように、なぜ行われているのかは分かりません。
同様の問題は、vBulletin の添付ファイルフィールドで幅と高さの両方が 0 になっている古い画像にも見られます。これらも縦横比が正しくありません。これらの値がインポート時に実際に使われているのかどうかも不明です。
この問題は、投稿を再ベイク(HTML の再構築)することで解決します。そうすると画像が適切にリサイズされ、画像ビューアも追加されます。しかし、160 万件の投稿があるため、すべてを再ベイクするのは避けたいです。
簡単な回避策として、Discourse で以下の CSS を適用する方法があります:
.cooked img:not(.emoji) {
height: auto;
width: auto;
}
ただし、この方法では、ユーザーが画像をアップロードする際に任意のサイズを選択できなくなるだけでなく、私が把握していない副作用が発生する可能性もあります。
インポートされた添付ファイルの画像で、正しい縦横比を維持する方法について、何かご存知ありませんか?
それは、インポート後に調理(リベイク)を行わなかったためではないかと推測します。投稿をリベイクせずに問題を解決する方法は考えられません。すべての投稿ではなく、壊れている投稿だけをリベイクするのはどうでしょうか?
インポート後、時間の経過とともに自動的に焼き直されるものなのでしょうか?最後に作成された投稿から、それとも最初に作成された投稿からでしょうか?
とはいえ、これは大きな問題ではありません。もし自動的に焼き直されない場合、おそらくすべての投稿の再焼き直しを開始して根気強く待つことになるでしょう。ただし、数日前にこの投稿を読んだところ、少し怖がらされました:https://meta.discourse.org/t/my-journey-into-a-massive-posts-rebake-job/84816。それについても質問があるのですが、適切なトピックで尋ねることにします。:blush:
はい、確かに私のコードのようです。申し訳ありません。![]()
これは以下のパターンに従うべきです:
batches(BATCH_SIZE) do |offset|
(SQL コード)
LIMIT #{BATCH_SIZE}
OFFSET #{offset}
(その他のコード)
end
インポート前にサイト設定の最大投稿長さを引き上げておいてください。



