Re: The module version works, but the standlone version crashes with "Malformed UTF-8 character"

The error message states:

Malformed UTF-8 character: \xf6\x6e\x20\x26

In latin-1 encoding this would be "ön &". This string (or something similar in another encoding) apparently occurs in any of your files and at least this file is not utf-8 encoded.

-jo

Comment on Re: The module version works, but the standlone version crashes with "Malformed UTF-8 character"

Replies are listed 'Best First'.
Re^2: The module version works, but the standlone version crashes with "Malformed UTF-8 character" by choroba (Cardinal) on Mar 09, 2020 at 20:51 UTC
Yes, it's file blues/020d9511 which is Latin-1 encoded. In UTF-8, the problematic line would be `TTITLE2=Jung, schön & stylish feat. Justus` [download] `map{substr$_->[0],$_->[1]\|\|0,1}[\\|\|{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^ARGV,3]`	[reply] [d/l] [select]
Re^2: The module version works, but the standlone version crashes with "Malformed UTF-8 character" by Perlfan52 (Novice) on Mar 09, 2020 at 21:15 UTC
The question is not why the standalone version does not work or where it doesn't work. If you delete blues/020d9511 it crashes immediately at next UTF-8 encoded file. The question is why the standalone version does not work and the module version works without any problem, although the code is absolutely the same. What makes a module so different internally so that perl has a different interpretation in both cases? For me as a developer a particular code must always give the same result, but in this case I am really helpless.	[reply]
Re^3: The module version works, but the standlone version crashes with "Malformed UTF-8 character" by jo37 (Curate) on Mar 10, 2020 at 15:18 UTC
Here I disagree. The input is malformed and a crashing program is the right thing™ here. I would not care why the other version does not crash but instead correct the input data. -jo	[reply]