Thanks Rick, the query gave the results:
+-----------+----------------------+-----------------+----------------------+
| english | hex(english) | length(english) | char_length(english) |
+-----------+----------------------+-----------------+----------------------+
| clientÞle | 636C69656E74C3A86C65 | 10 | 9 |
+-----------+----------------------+-----------------+----------------------+
The word should have been clientèle (naturally, the modern spelling, clientele, was one of the skipped rows).
I don't understand anything useful about hex data but the length and char_length values explains why apparently null fields in another table have a LENGTH of 1 rather than 0.
And the plot thickens. Following the suggestions on another site
http://www.blueboxgrp.com/news/2009/07/mysql_encoding I edited my.cnf so that it connected as utf8, created a completely clean database and table using the default settings and tried to import the same data from my Tab Delimited text file. This time I got even more skipped rows and also 39 warnings about Incorrect String Values.
I repeated this whole procedure with the server setting being utf but specified the COLLATE as utf8_bin but the results were exactly the same. Only when the server was the default setting of latin 1 and the database also used the default settings could I import the data without the Incorrect String Values errors and only the 'duplicate' rows being skipped.
So far, the only conclusion I can draw is that I have no real choice but to import the text using the default latin character set on server and database, alter tables and database to utf8_bin and then edit the text in my BASE front end. The article above refers to 'mangled' text but there seems to be no way around this. I would understand this if I was trying to import say Chinese or Hebrew but find it surprising that this happens with what is actually English text with accented letters.
I see that one letter on this subject warned darkly that altering the database and all its tables to UTF8_bin could cause 'other problems' but failed to specify what they would be so no doubt I will be writing back as they occur. Thanks for spending time on this, Rick. So far, I've not seen any solutions online that actually worked.