Torrents with additonal "<blah>.utf-8" fields are unable to be parsed.

[wkpatrick]

This is due to :erlang.binary_to_existing_atom not being able to turn "name.utf-8" into an atom (the period is what causes it to trip up).

Stacktrace

** (exit) an exception was raised:
** (ArgumentError) errors were found at the given arguments:

• 1st argument: invalid UTF8 encoding

  :erlang.binary_to_existing_atom("name.utf-8", :utf8)
  (bento 0.9.2) lib/bento/metainfo.ex:48: anonymous fn/1 in Bento.Metainfo.transform/1
  (elixir 1.12.0) lib/enum.ex:1553: Enum."-map/2-lists^map/1-0-"/2
  (elixir 1.12.0) lib/enum.ex:1553: Enum."-map/2-lists^map/1-0-"/2
  (bento 0.9.2) lib/bento/metainfo.ex:30: Bento.Metainfo.info/1
  (bento 0.9.2) lib/bento/metainfo.ex:41: Bento.Metainfo.info!/1
  (bento 0.9.2) lib/bento.ex:92: Bento.torrent!/1
  

"name.utf-8" appears to be from clients such as Vuze/Azeurus for handling old torrents that did not write the name/path's in utf-8 (see here).

I am not sure how to "properly" handle this, but for now I will just have it filter out any keys with .utf-8 in the data metainfo before parsing. Id be happy to merge those changes in, or any different change you would suggest.

Thanks for the useful library!

[folz]

Oh interesting, thanks for the report. I hadn't come across the nonstandard .utf-8 naming before. This seems reasonable to support in bento.

From the issue you linked, it's true that nonstandard key names aren't disallowed by the spec (they aren't mentioned). I guess that implies we should not be converting to atoms, because keys could be named anything - so we should represent key names as strings internally.

I am not presently doing anything with this library, so I would appreciate a PR if you want to put one up. I think we should make sure that .torrent() continues to validate that the metainfo has a torrent-compliant shape, but now will allow other keys. Please make sure it also includes (a) test case(s) covering this issue, and the results of benchmarking before and after the change.