It would be possible to provide a consistent experience, if it weren't for windows. Using non-latin characters in filenames is messy. We've seen characters replaced by question marks before, but this is the first time it ends up in a literal string. This time however, the korean characters were replaced by %3F, which is, surprise: the question mark. Im creating a file called test_ü.txt and listing it with the following script: I'm now creating a new file from the Nautilus interface, and want to see how it shows up for PHP. For this example I'm using ü, because it's a bit ambiguous as there's multiple ways to encode it using unicode (more on this later) and it also appears in ISO-8859-1.īack to the test. The other thing I wanted to test on linux is how it behaves if I create a file in the filemanager using a special character. A symptom of this is that any non-ascii characters look different when read them from Putty vs. However, I believe for the PuTTY application this was for the longest time ISO-8859-1 (latin1). Most of them, such as Gnome Terminal and Nautilus, default to UTF-8. This also applies to the applications on your linux machine. You can't even show this character in any PHP page, and firewalls might even block this if you used this in a url. Even though the underlying filesystem is binary-safe, applications that list filenames will still have to make a decision on an encoding to display the characters to the user. This doesn't mean it's a good idea to do this. The output is simply missing my bell character, and I get a short beep.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |