I'll look into that when I get home. (about an hour from now)
Thanks for identifying the likely cause.
EDIT: Okay, I looked at the source files from the backup, as well as the SQL file. Notepad++ assumes the SQL file is SHIFT-JIS encoding (a Japanese character set) which may be the source of the problem. I'm going to look at the database itself on here to see exactly how these posts imported, to see if
a) an automatic script could possibly fix them
b) if not, then if an automatic script could possibly at least
identify them
In the latter case, depending on how many there are, I'll see whether it'll be less effort to write some script to re-import the broken ones, or to simply manually fix them up.
EDIT: Okay, so the cut-off happened while importing the posts through PHPMyAdmin - the full content is there (albeit with slight corruption on those characters) in the SQL file; it's gone in the copies of the posts on the database for this forum.
Thus, the easiest way to identify them will be to modify the code used to generate the LemmingsWelt SQL import code.
EDIT: Done this, and am currently running it. Basically; the code is set to print out (to a text file) a list of posts that have non-ASCII standard characters.
EDIT: Done this too. Although they are a minority of the LemmingsWelt posts (and since the test was simply "is there any character that isn't standard ASCII", it might have some false positives), there is a significant number of them, so I modified the app again to create a SQL file that'll add these posts to a temporary database table, with the characters causing the corruption converted to the HTML special character equivalent (eg, character 0x9F would become F;, just to give an example). If this goes well and imports successfully, I'll write a PHP script that attempts to automatically fix the broken posts based on this temporary table.