`as_bytes()` panics if string is not utf8

[KonradHoeffner]

[...] found an unhandled bug while testing with dblp, pretty sure as_bytes() barfs if the string is not utf8?

./rdf2hdt convert -i dblp.ttl -o dblp-rust.hdt -vvv
[DEBUG hdt::rdf2hdt::rdf_reader] converting dblp.ttl to nt format
[DEBUG hdt::rdf2hdt::rdf_reader] RDF to NTriple convert time: 939.855296477s
[DEBUG hdt::rdf2hdt::dictionary] Four Section Dictions sort time: 1837.413708669s
[DEBUG hdt::rdf2hdt::dictionary] Encoding triples time: 1299.179455131s
[DEBUG hdt::rdf2hdt::dictionary] Dictionary build time: 3136.655445115s
[DEBUG hdt::rdf2hdt::bitmap_triples] BitmapTriples build time: 81.938644095s
[DEBUG hdt::rdf2hdt::builder] HDT build time: 4187.132880571s

thread 'main' panicked at src/rdf2hdt/dictionary.rs:237:52:
byte index 8 is not a char boundary; it is inside 'μ' (bytes 7..9) of `"$\\mu$μBench: An Open-Source Factory of Benchmark Microservice Applications."`

looking at the convert NT triples:

$ grep "An Open-Source Factory of Benchmark Microservice Applications." dblp.nt
<https://dblp.org/rec/journals/tpds/DettiFP23> <http://www.w3.org/2000/01/rdf-schema#label> "Andrea Detti et al.: $\\mu$μBench: An Open-Source Factory of Benchmark Microservice Applications. (2023)".
<https://dblp.org/rec/journals/tpds/DettiFP23> <https://dblp.org/rdf/schema#title> "$\\mu$μBench: An Open-Source Factory of Benchmark Microservice Applications.".

and the source TTL:

$ grep "An Open-Source Factory of Benchmark Microservice Applications." dblp.ttl
        rdfs:label "Andrea Detti et al.: $\\mu$\u03BCBench: An Open-Source Factory of Benchmark Microservice Applications. (2023)" ;
        dblp:title "$\\mu$\u03BCBench: An Open-Source Factory of Benchmark Microservice Applications." ;

Originally posted by @GregHanson in #56 (comment)

[GregHanson]

Don't think this one is specific to the HDT library, but rather an oddity of the converters.

In the original source RDF TTL literal, it includes a Unicode escape sequence. Which as far as I know is valid (passes riot validation), so I was surprised all 3 libraries performed a substitution. It'd be one thing if if both sophia and oxrdf behaved similarly since they are both written in Rust, but the Java tooling performed the same replacement.

I checked the content of the c++ generated HDT and it also has the substitution:

$ hdtSearch dblp.hdt
>> https://dblp.org/rec/journals/tpds/DettiFP23 https://dblp.org/rdf/schema#title ?
https://dblp.org/rec/journals/tpds/DettiFP23 https://dblp.org/rdf/schema#title "$\mu$μBench: An Open-Source Factory of Benchmark Microservice Applications."

So it is a bug in my implementation for how I am currently removing the common prefix substrings as reported in #56 (comment), since it assumed only ASCII text. I was surprised that the norm is to replace unicode escape sequences during conversion

[KonradHoeffner]

@GregHanson does this bug still occur?
If yes, I can try to find a solution.
Do I understand it correctly that it only occurs when converting TTL to HDT?
Is https://dblp.org/rdf/dblp.ttl.gz the correct source file link?
As it is 22.7 GB in size, I hope I can even convert that without running out of my 32 GB of RAM.
This could be a good test case for the CLI tool in the "cli" branch.

$ time cargo run --release -- info dblp.ttl
[...]
zsh: killed     cargo run --release -- info dblp.ttl
cargo run --release -- info dblp.ttl  272.48s user 10.85s system 99% cpu 4:44.22 total