intvsteve
commented
5 years ago Inspected the code here.
When serializing / deserializing the long and short names, ASCII encoding is used. Based on the API documentation for ASCIIEncoding here, if, somehow, UNICODE characters outside the ASCII range -- and not already coerced to valid GROM characters -- were to somehow inveigle themselves into the data structures, the behavior will be to replace such characters with '?', and the data will be truncated to the appropriate maximum length (60 or 18 bytes, respectively).
Simply stated: There is no UTF-8 support in LUI for file / folder names when sending data to LTO Flash!. IIRC, the specification calls for ASCII here, so LUI is behaving correctly, and not susceptible to UTF-8 related "corruption". Unless / until the LTO Flash! firmware and corresponding on-cartridge menu browser implements some form of UTF-8 character support, even considering supporting UTF-8 at this level is moot.
Specifically, since LUI uses UNICODE strings, but encodes them as UTF-8 to send over the wire, it's possible that > MAX_[SHORT|LONG]_LEN bytes are sent.
This is likely already mitigated by LUI's enforcement of restricting ROM names in the menu to valid GROM characters. That's fine -- but that means LUI is more or less accidentally avoiding the issue.
A little extra inspection of the serialization code in the communication stream cannot be a bad thing.