I think your reading of the code is fine - it's not entirely logical.
* Avoiding '.', but using it in the encoding doesn't make any sense, although I'm not sure there was a good reason to avoid it in the first place.
* Avoiding '_' but still using it is somewhat reasonable, because it's used as the sigil to mark the names as alt-base64 encoded.
* The alt-base64 encoding goes out of its way handle case folding (which is a real issue on Windows and macOS) - but the same issue can occur with the unencoded names too, and that's not handled.
* isDirChar permits characters that aren't valid on all platforms, like backslash on Windows.
The Preferences class was introduced in Java 1.4 according to the docs, and there's a bug report[1] referencing the encoding behaviour in the 1.4.0 release, so it's probably been like this since the initial implementation.
> P.S. A minor observation; the alphabet on the URL has a slight typo
If the requested directory name has certain "inappropriate" characters in it, it'll encode it using Base64.byteArrayToAltBase64, which is a non-standard base64 encoding using the alphabet defined here:
https://github.com/openjdk/jdk/blob/4f607f2adac3798c16a62e90...
Prior to that I was using Miniflux, but I wanted to apply some filters to a particular feed and I realised that I already had a tool with advanced features for filtering and organising short messages with a subject and body: email.
* Avoiding '.', but using it in the encoding doesn't make any sense, although I'm not sure there was a good reason to avoid it in the first place.
* Avoiding '_' but still using it is somewhat reasonable, because it's used as the sigil to mark the names as alt-base64 encoded.
* The alt-base64 encoding goes out of its way handle case folding (which is a real issue on Windows and macOS) - but the same issue can occur with the unencoded names too, and that's not handled.
* isDirChar permits characters that aren't valid on all platforms, like backslash on Windows.
The Preferences class was introduced in Java 1.4 according to the docs, and there's a bug report[1] referencing the encoding behaviour in the 1.4.0 release, so it's probably been like this since the initial implementation.
> P.S. A minor observation; the alphabet on the URL has a slight typo
Bad search-and-replace. Oops :)
[1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4696941