2009/2/18 Tanaka Akira <akr / fsij.org>:
> In article <a5d587fb0902160252u56b50cfdv8e0fd36bb4f0b1b3 / mail.gmail.com>,
>  Michal Suchanek <hramrach / centrum.cz> writes:
>
>>> What is represented by the N chars?
>>
>> I don't understand the question. N chars are N chars, they do not
>> represent anything else.
>
> I expect something like person's name, zip code, etc.
>
> However, person's name is variable length.
>
> The zip code (in Japan) is fixed length but multibyte
> encoding is not useful because it uses only digits.

As was explained by the original poster there are file formats similar
to CSV that use fixed field length instead of separators. I have
myself used such files, and they were in 8-bit fixed width encoding.

However, if you want to "upgrade" your code that uses such files to
multibyte for international support you need reading N characters.

Of course, the alternative is to change your code to use a different
format.This might make exports to and imports from legacy applications
hard, however.

Sure, the export can never be perfect if the files really contain
internationalized data because recoding to the legacy format and
encoding loses some information then.

>
> I'm not sure the usage of the method for "reading N
> characters".

Yes, reading N characters does not seem very useful outside of very
specialized scenarios. Most sane file formats use string length in
bytes or separators.

However, reading N characters, lines, or any other units for which you
have an IO enumerator seems useful to me.

Actually reading N lines using the correct line separator would fetch
N records from the file without the need to construct a loop for that
(or repeat the method for reading a line N times).

>
>> It's actually not that hard except the synchronization is not perfect.
>> By using chars and then lines I lost "F"
>
> I guess enumerator uses lookahead.

That's unfortunate for using the Enumerator with other methods for
reading files.

Thanks

Michal