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

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 12, 2005, 21:24 UTC
Message-ID: <Pine.LNX.4.64.0510121411550.15297@g5.osdl.org>
In-Reply-To: <87vf02qy79.fsf@penguin.cs.ucla.edu>

On Wed, 12 Oct 2005, Paul Eggert wrote:

Show 5 quoted lines

> 
> 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