Character Encoding

[anonymous]

Would like to know what character encoding the file has. FileOpen() or Fileread could set that information in @Extended macro?

[Valik]

Hm. How about this: Instead of setting @extended I can add a new function called FileGetEncoding(). It will take either a handle (from FileOpen()) or a string specifying a file. It will return the encoding in BinaryToString() format and set @extended to the encoding in FileOpen() format.

The problem I have with setting @extended for FileRead() is the information doesn't really need returned every single time FileRead() is called. It's more of a check it once kind of thing. I don't think returning it from FileOpen() makes much sense, either. It's only useful when a mode isn't specified which makes it kind of redundant.

[Jon]

Actually, the FileOpen/@extended thing sounds OK to me. The current FileOpen flags for encoding are only enforced when the file is BOM-less or when a new file is created. If there is a BOM then the flags are ignored. So, the @extended flag returning the actual mode the file was opened sounds kinda useful (and avoids us having to add another function including the documentation). Unless I've missed something.

I'll add some "get_file_mode" code to our internal class and check back later to see for any more comments before changing any public function.

[Zedna]

From my point of view.
If you add this into FileOpen it can reduce performance (testing encoding) in case I don't want to check result of @extended.
I think it will be majority of cases when we will not test it.

Because of that I vote for FileGetEncoding() as alone function which can be called only when needed.

[Jon]

Logic flaw. Encoding has to and is tested anyway when you open a file in anything other than binary mode. The data read in to test is cached and reused anyway. :)

[Jon]

Added by revision [5621] in version: 3.3.5.0