Modify

Opened 10 years ago

Closed 10 years ago

#1054 closed Feature Request (Completed)

Character Encoding

Reported by: anonymous Owned by: Jon
Milestone: 3.3.5.0 Component: AutoIt
Version: Severity: None
Keywords: Cc:

Description

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

Attachments (0)

Change History (6)

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by Valik

  • Owner set to Valik
  • Status changed from new to accepted

comment:3 Changed 10 years ago by Jon

  • Owner changed from Valik to Jon
  • Status changed from accepted to assigned

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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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. :)

comment:6 Changed 10 years ago by Jon

  • Milestone set to 3.3.5.0
  • Resolution set to Completed
  • Status changed from assigned to closed

Added by revision [5621] in version: 3.3.5.0

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jon.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.