The hell that is filename encoding (2016)
1–10 of 121 posts
Re: The hell that is filename encoding (2016)
#2Rust `std::path` [1] has two representations under the hood for Windows (UTF-16 plus lone surrogates) and non-Windows (bytes) for the exactly same reason. Paths are not strings nor texts.
Re: The hell that is filename encoding (2016)
#3Just dealing with file extensions is enough of a head spin. We stopped trying to differentiate between .xls, .xlsx, *.xlst... etc. to show an Excel icon for a file uploaded to our SaaS and just went with a generic file icon in the end.
Re: The hell that is filename encoding (2016)
#4Just dealing with file extensions is enough of a head spin. We stopped trying to differentiate between .xls, .xlsx, *.xlst... etc. to show an Excel icon for a file uploaded to our SaaS and just went with a generic file icon in the end.
That sounds like the classic example of a decorative feature that someone thought, "oh that sounds easy, add it to someone's sprint." But of course turns out to be mind numbingly complex.
Re: The hell that is filename encoding (2016)
#5It misses a even more complex, I'd say insane, encoding problem: on HFS+ (or even APFS now?) filenames are unicode normalized.
Re: The hell that is filename encoding (2016)
#6Just dealing with file extensions is enough of a head spin. We stopped trying to differentiate between .xls, .xlsx, *.xlst... etc. to show an Excel icon for a file uploaded to our SaaS and just went with a generic file icon in the end.
That sounds like the classic example of a decorative feature that someone thought, "oh that sounds easy, add it to someone's sprint." But of course turns out to be mind numbingly complex.
Honest question, why is that feature complex? What is the problem in looking at last part after dot?
Re: The hell that is filename encoding (2016)
#7Rust `std::path` [1] has two representations under the hood for Windows (UTF-16 plus lone surrogates) and non-Windows (bytes) for the exactly same reason. Paths are not strings nor texts. [1] https://doc.rust-lang.org/stable/std/path/
They're not strings nor texts right up until the point you need to display them to users.
Re: The hell that is filename encoding (2016)
#8Earlier quoted context omitted.
That sounds like the classic example of a decorative feature that someone thought, "oh that sounds easy, add it to someone's sprint." But of course turns out to be mind numbingly complex.
Honest question, why is that feature complex? What is the problem in looking at last part after dot?
Because Microsoft made their new office extension .xml if that doesn't make your head spin i don't know what else will.
Re: The hell that is filename encoding (2016)
#9Rust `std::path` [1] has two representations under the hood for Windows (UTF-16 plus lone surrogates) and non-Windows (bytes) for the exactly same reason. Paths are not strings nor texts. [1] https://doc.rust-lang.org/stable/std/path/
Emphasis on the "plus lone surrogates" part. Like on Unix, Windows does not require a path to be valid Unicode.
That is, on Windows, paths are fundamentally sequences of 16-bit words, just like on Unix paths are fundamentally sequences of 8-bit bytes. On neither system are paths fundamentally text.
Re: The hell that is filename encoding (2016)
#10In which the author takes a long and winding path to what most of us already know, "paths are fundamentally bytes".