Prev: Interference from cassette player
Next: "iTunes Store simulator" for jailbroken iPod Touch?
From: Martin-S on 17 May 2010 14:47
Traditionally the mac OS has been very good with handling special
characters from the upper ascii range, even though some applications
weren't. So I usually "dumb down" file names to using the plain English
alphabet.

As far as I understand OSX since its first incarnation has been able to
handle the full unicode character set.

But what is the status in recent versions of Windows, Vista and 7?

Are special characters finally cross-platform?

--
Martin
From: Duncan Kennedy on 17 May 2010 15:59
Martin-S <cgzjmthpzs(a)lzrpqi.net> wrote:

> Traditionally the mac OS has been very good with handling special
> characters from the upper ascii range, even though some applications
> weren't. So I usually "dumb down" file names to using the plain English
> alphabet.
>
> As far as I understand OSX since its first incarnation has been able to
> handle the full unicode character set.
>
> But what is the status in recent versions of Windows, Vista and 7?
>
> Are special characters finally cross-platform?

Can't speak with confidence on this but, from many years of Windows web
design, Windows has always accepted just about everything in filenames,
including spaces and a completely cavalier attitude to upper and lower
case - not caring which. This always catches the newcomer who uses
Microsoft applications and sends their pages to a Linux / UNIX server
which is case sensitive, with predictable results and much loss of hair.


--
duncank
From: Martin-S on 17 May 2010 16:32
In article <1jinlqm.tufvzw10vplv0N%nospam(a)nospamottersonbg.couk>,
nospam(a)nospamottersonbg.couk (Duncan Kennedy) wrote:

> This always catches the newcomer who uses
> Microsoft applications and sends their pages to a Linux / UNIX server
> which is case sensitive, with predictable results and much loss of hair.

Yes, I realise web design is a different issue and I do stick to the
lower ascii range, lowercase, no spaces in that area.

I was just curious, whether things had improved exchanging files via
email etc.

--
Martin
From: Chris Ridd on 17 May 2010 16:45
On 2010-05-17 21:32:10 +0100, Martin-S said:

> In article <1jinlqm.tufvzw10vplv0N%nospam(a)nospamottersonbg.couk>,
> nospam(a)nospamottersonbg.couk (Duncan Kennedy) wrote:
>
>> This always catches the newcomer who uses
>> Microsoft applications and sends their pages to a Linux / UNIX server
>> which is case sensitive, with predictable results and much loss of hair.
>
> Yes, I realise web design is a different issue and I do stick to the
> lower ascii range, lowercase, no spaces in that area.
>
> I was just curious, whether things had improved exchanging files via
> email etc.

The Wikipedia articles on NTFS and HFS+ suggest that you should be OK
using long Unicode filenames. They're stored differently on Macs and
PCs, but that doesn't matter when you're emailing. You might encounter
problems with the versions of Unicode supported on both ends, but you'd
be using pretty obscure stuff if you did!

There are some special filenames on PCs (things like NUL:) which you
should avoid, also the obvious path separators like / and \.

--
Chris

From: Graham J on 17 May 2010 17:06

"Martin-S" <cgzjmthpzs(a)lzrpqi.net> wrote in message
news:cgzjmthpzs-7EC496.20321017052010(a)news.simnet.is...
> In article <1jinlqm.tufvzw10vplv0N%nospam(a)nospamottersonbg.couk>,
> nospam(a)nospamottersonbg.couk (Duncan Kennedy) wrote:
>
>> This always catches the newcomer who uses
>> Microsoft applications and sends their pages to a Linux / UNIX server
>> which is case sensitive, with predictable results and much loss of hair.
>
> Yes, I realise web design is a different issue and I do stick to the
> lower ascii range, lowercase, no spaces in that area.
>
> I was just curious, whether things had improved exchanging files via
> email etc.

Fairly obviously, the "\" cannot be part of a filename in windows.

Similarly * and ? indicate wildcards (multiple or single)

>< imply redirection

| means pipe

: identifies the preceding character as a logical device name which is
meaninless in a UNIX environment

~ implies a short name derived from a longer name - again meaninless in a
UNIX environment

Not sure what happens with non-printing characters

The "." (full point) creates problems. Searching for *.* in Windows finds
all the files in the path, while searching for *.* in UNIX finds all all the
files in the path that contain a full point in their names. You could argue
that the full point is not part of a Windows filename - rather it is a
separator like \

The double-quote allows you to specify filenames that contain spaces. I
don't know how you would escape it so as to include double quotes in a
filename.

There are reserved names (e.g. COM1) - I suspect these differ between
Windows & UNIX

The total number of characters in a path is arbitrarily limited in Windows -
different values in different flavours of Windows, I think. Not sure such a
limit exists in UNIX.

--
Graham J


 |  Next  |  Last
Pages: 1 2
Prev: Interference from cassette player
Next: "iTunes Store simulator" for jailbroken iPod Touch?