From: Eli Zaretskii <eliz@gnu.org>
To: emacs-devel@gnu.org, Zhang Haijun <ccsmile2008@outlook.com>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: 26.1.50; Emacs can't decode the text file on opening the file, but can decode it on revert-buffer
Date: Sun, 04 Nov 2018 11:18:53 +0200 [thread overview]
Message-ID: <D943DF39-1828-4E44-BBD5-D1566042FAFD@gnu.org> (raw)
In-Reply-To: <SG2PR0601MB1405441899781F1B66EC1707A8C90@SG2PR0601MB1405.apcprd06.prod.outlook.com>
On November 4, 2018 10:44:36 AM GMT+02:00, Zhang Haijun <ccsmile2008@outlook.com> wrote:
> I have sent a bug report mail to bug-gnu-emacs@gnu.org, but didn't
> receive the bug number mail. So I send it here.
>
> I put the attachment file to:
> http://119.37.194.6/upload/tmp/emacs-26.txt
>
>
> Following is the bug report mail:
>
> Open the attachment text file with "emacs -Q". There are many
> unrecognized chars(like \342\200\230). Following is the encoding info
> of
> the buffer.
>
> -------------------------------------------------
> = -- no-conversion (alias: binary)
>
> Do no conversion.
>
> When you visit a file with this coding, the file is read into a
> unibyte buffer as is, thus each byte of a file is treated as a
> character.
> Type: raw-text (text with random binary characters)
> EOL type: LF
> --------------------------------------------------
>
> But if I run the command revert-buffer, then there is no unrecognized
> chars. Encoding info of the buffer becomes:
>
> ---------------------------------------------------
> U -- utf-8-unix (alias: mule-utf-8-unix cp65001-unix)
>
> UTF-8 (no signature (BOM))
> Type: utf-8 (UTF-8: Emacs internal multibyte form)
> EOL type: LF
> This coding system encodes the following charsets:
> unicode
> ---------------------------------------------------
This file includes null bytes, which by default cause Emacs to disable all decoding, because such files are deemed to be binary files.
If you don't like this, set inhibit-null-byte-detection to a non-nil value.
This is not a bug, but the intended behavior.
next prev parent reply other threads:[~2018-11-04 9:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-04 8:44 26.1.50; Emacs can't decode the text file on opening the file, but can decode it on revert-buffer Zhang Haijun
2018-11-04 9:18 ` Eli Zaretskii [this message]
[not found] ` <16B3CA28-C893-4854-AD64-1C224C1EDDB2@outlook.com>
2018-11-04 14:49 ` Eli Zaretskii
[not found] ` <B213388B-58E6-4F5B-8CE8-79AC5AD3062B@outlook.com>
2018-11-04 17:13 ` Eli Zaretskii
2018-11-05 8:59 ` Zhang Haijun
2018-11-05 9:00 ` Zhang Haijun
2018-11-05 9:00 ` Zhang Haijun
2018-11-05 9:39 ` Phil Sainty
2018-11-05 10:10 ` Stephen Berman
2018-11-05 14:08 ` Zhang Haijun
2018-11-05 15:02 ` Stephen Berman
2018-11-05 16:00 ` Eli Zaretskii
2018-11-06 1:39 ` Zhang Haijun
2018-11-06 3:31 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D943DF39-1828-4E44-BBD5-D1566042FAFD@gnu.org \
--to=eliz@gnu.org \
--cc=ccsmile2008@outlook.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.