Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:08


On Wed, 12 Oct 2005, Paul Eggert wrote:
Worse, when I used Emacs to copy your text into another file -- the
sort of thing that is likely to be done with an emailed patch -- the
file contained the UTF-8 encoding of the gibberish, rather than the
original bytes of your message.
Btw, this is an example of where locale-based character translations just 
fundamentally suck.

cut-and-paste quote naturally tries to translate between the source 
and destination locales, but it fundamentally cannot work. The only thing 
that ever works is bit-for-bit copying.

Any program that tries to do locale conversion is always going to be a bug 
waiting to happen.

If GNU emacs does locale translations rather than just do a binary 
transfer of the data, then that's a sign that GNU emavs is being really 
stupid. If the data was UTF-8 to begin with, then a binary copy is also 
going to be UTF-8. And if it wasn't UTF-8, then a binary copy is the only 
thing that is sensible.

And this is the thing that makes UTF-8 so wonderful: exactly the fact that 
it makes bit-for-bit copying an acceptable policy again, and locales 
become a non-issue. In a truly UTF-8 world, you should _never_ convert 
anything at all (and that includes mis-formed UTF-8).

Any non-binary file saving or transfer approach where characters have 
"meaning" is always mistake. It's why DOS/Windows "binary" vs "text" files 
was wrong. It's why font-encoding locales are wrong (Mixed text with two 
types? Yet another metadata quoting scheme? No thank you! It's also why 
UCS-16 and UCS-32 were total disasters: they had "context" in their 
encoding).

Say "yes" to binary transfer. Because text transfers are broken.

			Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help