michael@[EMAIL PROTECTED]
wrote:
> spinoza1111@[EMAIL PROTECTED]
wrote:
> > One problem I see: your delimiters being in the range 128..255 rather
> > assume that "real" file identifiers will not contain characters with
> > these values, and this is not the case in Windows.
> >
> > International experience (the use of Chinese characters in Windows
file
> > identifiers) has shown me that owing to the proprietary character of
> > Windows, the file identifier's syntax was never defined, to my
> > knowledge, formally and instead a minimal file syntax applies where
ANY
> > unicode character other than the semicolon, backslash, asterisk and
> > question mark can be and will be accepted by most Windows
installations
> > as part of the file id.
> >
> > It is well known also that the period doesn't left-delimit the file
> > type, instead the file name to the right of the type can contain
> > multiple periods with the right period delimiting the type.
> >
> > If M$ means Microsoft, then I suggest you BNF formulate the minimal
> > syntax of a file identifier and use this to parse the file identifier.
> >
>
> Sorry. I'm a bit confused. I was only looking for something to handle
> delimited text strings within a single file. How do M$'s file naming
> "conventions" come into it. Were you expanding on the idea of using
> ReiserFS instead of a program? I realise that the characters within
> each string will be limited to the ASCII chars 0-127 inclusive (except
> that I'd also like to exclude char0).
OK, my mistake. Thought you were parsing a file name. You said "in
filename" and not "in the file".
>
> If you're wondering where I'm heading with this, think of nested data -
> like XML (only far more compact). I guess you could say that any
> characters allowed in XML should be allowed. Further.. think of two
> associated delimited strings - one to hold markup etc., the other the
> data.
>
> Mike.
|
