Thread (12 messages) flat view 12 messages, 5 authors, 2016-06-15

Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.

From: Lars Noschinski <hidden>
Date: 2016-06-15 22:46:19

* Peter Krefting [off-list ref] [09-03-03 12:54]:
Lars Noschinski:
quoted
Changing the filename (on checkout), so that the user sees an Ü regardless of 
his or her locale (instead of an \0xDC, which only resolves to an Ü on 
latin-1) would be an absolutely broken concept here.
Why would it? It is my view as a user on my files that define how file names 
are looked upon. If I have three machines, one Linux box using a iso8859-1 
locale, an OS X box (where, I would believe, file APIs use UTF-8, someone 
please correct me if I'm wrong), and a Windows box (which uses UTF-16 on the 
file system layer, but does provide compatibility functions that use char 
pointers), and create a file on each of these called "Ü.txt" (which would be 
the sequence "DC 2E 74 78 74" on the Linux box, "C3 9C 2E 74 78 74" (or 
probably something else since I believe OS X decomposes the string) on the OS X 
box and "00DC 002E 0074 0078 0074" on the Windows box, I see these three file 
names as equal.
Because a function in the source code refers to (e.g.) "DC 2E 74 78 74",
not "C3 9C 2E 74 78 74" nor "00DC 0024 0074 0078 0074". And it does so
regardless of the locale.

The file name may look funny depending on your locale, but if you rename
the file to fit your local enconding, it would not work.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help