From: Bernard D. <bde...@or...> - 2017-12-08 07:24:07
|
Hi Chris, A few remarks to clarify how encodings are handled by Alpha: when a file is opened via File ↣ Open, the dialog lets you specify the encoding. when a file is opened by Drag and Drop on Alpha's icon, there is no way to know the encoding of the file, so Alpha tries the default input encoding (which is usually UTF8). If this fails, it presents a dialog asking to specify the encoding. when a file is opened via the recent files menu (File ↣ Open Recent), it means that this file was already edited recently. This menu is clever and remembers the encoding which was used the first time, so it does not ask (and it could be wrong if in the meantime the file was reencoded into something different). Some considerations useful to know about encodings: UTF8 is a multi-bytes encoding with very strict rules about the byte sequences. A character may be represented by 1 to 4 bytes, and bytes are formatted so that there is no ambiguity about whether a particular byte is the first, second, third or fourth element of a sequence. This is why if you attempt to edit as UTF8 a file which is not UTF8-encoded, it is most likely that some bytes will be seen as malformed and Alpha will scream. MacRoman, Latin1, CP1252 are single byte encodings, so if you attempt to open any file in one of these encodings, the file will be read byte by byte, and opening will never fail. Every byte will be accepted but of course may be misinterpreted if you specified the wrong (single-byte) encoding. Files in pure ascii (with all the bytes less than 127) may be successfully opened in any encoding. Ascii is a common denominator of all these encodings, including UTF8 (possibly with a few exceptions concerning control codes). Now, concerning the issue reported by this ticket, is it possible to have (privately) a file which fails to be opened as you describe ? Le 8 déc. 2017 à 02:22, Chris Skeels via AlphaCocoa-devel <alp...@li...> a écrit : > One further observation. The earlier comments were based on experience on a machine running OS X 10.9.5. I don't observe any of these symptoms on a machine running OS X 10.12.6. > > [tickets:#147] Encoding issues > > Status: open > Created: Thu Dec 07, 2017 08:01 PM UTC by Chris Skeels > Last Updated: Thu Dec 07, 2017 08:01 PM UTC > Owner: nobody > > Milestone: Version 9.0rc1 (RC1) (31) > > Alpha is inconsistent in how it deals with encoding issues. > > Suppose I wish to open a file that I have most recently edited in AlphaX, so that I know the encoding is macRoman. If I use the menu item File>Open, or equivalently cmd-O, the Alpha opens the file quite happily. Conversely, if I drag the file from a Finder window to the Alpha icon in the Dock then I am greeted by a dialog box telling me that the file couldn't be opened using text encoding UTF8 but that I can try again using a different encoding. However, selecting Western (Mac OS Roman) is unsuccessful, as was anything else I tried. On cancelling out of this dialog I get another dialog telling me that the file couldn't be opened because it doesn't exist, although it does and it continues to open happily in AlphaX. > > Similarly, having successfully opened the file via File>Open, its name is now available in the File>Open Recent sub-menu.. If I select it the Alpha just silently does nothing. > > Sent from sourceforge.net because alp...@li... is subscribed to https://sourceforge.net/p/alphacocoa/tickets/ > > To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/alphacocoa/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > AlphaCocoa-devel mailing list > Alp...@li... > https://lists.sourceforge.net/lists/listinfo/alphacocoa-devel |