So, they were utf8_bin? And you've altered the table and removed utf8_bin? jpg is "before" and pdf is "after"? Did that help?

If did not, please provide "show create table adressen" result, so I could test what is wrong with the table.
Otherwise I am closing the issue.

I haven´t altered the tables. Here the create statement:

CREATE TABLE `adressen` (
`NUMMER` smallint(6) NOT NULL,
`VORNAME` varchar(40) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`ZUNAME` varchar(40) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`VOLLMACHT` varchar(40) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`STRASSE` varchar(35) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`PLZ` varchar(7) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`ORT` varchar(25) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`BANK` varchar(30) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL COMMENT 'Land',
`TELEFON` varchar(60) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`EMAIL` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`UID` varchar(20) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`USER` varchar(20) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
`TS` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`NUMMER`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;
/*!40101 SET character_set_client = @saved_cs_client */;

I am not sure there is a bug here. Server reports binary flag for fields, thus connector report to dao that fields are binary, dao fetches values as binary.
On other hand, if someone chooses utf8_bin collation for his/her utf8 field, unlikely he/she expects it to be treated as a binary field. And maybe connector should not trust server, and check some other conditions, to establish the fact whether the field is binary or not. I will think some more on this.

Does that table have utf8_bin collation intentionally? To change to other collation would be one work-around for your problem. Other work-around to view those fields correctly, probably, would be to use convert/cast functions for those fields.

The fix has been pushed (to 2.0 branch) as rev. b0e0d7c2a489dd4436256a7f8bb644f6641fa8ad

I've decided that is a bug And fixed. If you care to verify it - I have attached the dll with it. That is not any official release, and good only for testing/verification.
And thanks once again - you were really helpful!