保存で文字化け	No.37847
フィードバック さん　19/12/19 00:39
動作報告　 秀丸エディタ8.90ベータ10 上書き保存・別名保存ののち 開いたテキストデータがすべて文字化け どのエンコードで開いても化けます このテキストデータ、復旧できません 保存時の設定 .txt UTF-8（自動判別） 改行コード（自動）変更しない BOM付けるにチェックしない テキストデータ 日本語縦書き用　全角１１万字 262KB UTF-8 １０月２７日更新日付け これが文字化け 別のアプリケーションで開く メモ帳、ワードパッド、Firefoxなどでも文字化け バージョンを上げる前に自動世代バックアップされていたものは １０月２４日更新日付けまで 秀丸では正常のように開けますが メモ帳Ver.5.1で開くと改行が無効 左右方向に非常に長いスクロール Firefox52.9で開くと改行は正常 再現しようと何度か秀丸から保存したりしていると 262KBが70KBになっているものがありましたが これは再現ができません 本日、検証で新規文字入力して保存したもの １００字程度のテキストは正常 データ容量1KB 別のテキストデータ.txt 日本語横書き用　全角数千字　が１６ファイル UTF-8　合計75KB １１月から１２月８日更新日付け これは上書き保存して開きなおしても正常でした メモ帳でも改行が反映されていました 別のテキストデータ.txt　１ファイル 日本語縦書き用　全角１２万字 UTF-8　362KB １２月１５日更新日付け これも正常 当時操作したこと 「ファイルタイプ別の設定のリスト」から「適用」 秀丸エディタ環境設定.hmereg https://www.axfc.net/u/4015343?key=ありません

[ △ ]

RE:37847 保存で文字化け	No.37849
秀丸担当 さん　19/12/19 09:49
文字化けしたものが、文字化けしたままになる可能性がある操作としては、文字化け した状態のものを保存するとそうなる場合があります。 例えば、開いた段階で認識がうまくいかず文字化けして、その段階ではエンコードの 種類を変更すれば正しく認識可能だったとします。そこでエンコードの種類を変更し て読み込みし直しせず、文字化けした状態で、上書きまたは名前を付けて保存すると、 文字化けしたままになります。 その状態だと元の状態に戻すのは難しいです。 もし差し支えなければ、"taki@maruo.co.jp"まで問題のファイルを送っていただける と、どういう操作によってそうなったかが推測はできるかもしれないです。

[ △ ]

RE:37849 保存で文字化け	No.37852
フィードバック さん　19/12/19 17:33
問題のファイルをメールにて送信しました データは３つです ●文字化けしているもの ●秀丸エディタは文字化けしていないがメモ帳で開くと改行が無効のもの ●それを秀丸エディタで保存しなおしたもの

[ △ ]

RE:37852 保存で文字化け	No.37853
でるもんたいいじま さん　19/12/19 18:56
横やり失礼します。でるもんた・いいじまです。 > 問題のファイルをメールにて送信しました これ、もしかしてファイルをそのまま添付しちゃいましたでしょうか？ 担当さんのほうでできる限りのことはしてくれると思いますが、 もし再送となった場合には「ファイル3つをどこかの新しいフォルダに コピーして、そのフォルダを丸ごとzip圧縮して」送ってください。 メーラーがテキストデータを加工してしまうことが多々ありますから。 ☆　☆　☆ > データは３つです > ●文字化けしているもの > ●秀丸エディタは文字化けしていないがメモ帳で開くと改行が無効のもの > ●それを秀丸エディタで保存しなおしたもの 担当さんからは明朝にお返事があると思いますので、それまでの間に、 ファイル(F)→エンコードの種類(D)　で各ファイル、どの項目にチェックが ついているか確認してみてください。 まず、最初のファイルは、この点： 　　　hidesoft.2:37847| 保存で文字化け 　　　> 保存時の設定 　　　> .txt 　　　> UTF-8（自動判別） 　　　> 改行コード（自動）変更しない 　　　> BOM付けるにチェックしない が問題のはずです。 UTF-8のデータは、BOM（バイト・オーダー・マーク）という記号を先頭に つけてあげないと自動認識してくれないアプリが多々あります。 文字化けしないファイルのほうは、同じUTF-8でもBOMありになっているはずです。 https://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC%E3%83%9E%E3%83%BC%E3%82%AF 一方で、UTF-8のファイルにBOMをつけてはいけないシチュエーションも世の中には 多々あります。なので、秀丸はどちらにも対応できるように作られています。 この場合、動作環境のほうで「上級者向け設定」をONにしていただいて、 ファイル→エンコード1　のページで「Unicode(UTF-8)」はONになっている でしょうか？これをONにしておくと自動認識できる可能性が大です。 2番目のやつは、「改行＝CR」か「改行＝LF」にチェックが入っていると 思います。メモ帳は「改行＝CR+LF」でないと認識しません。 （Windows10の最新版のメモ帳ならばどれでもOKですが、古いメモ帳は 　CR+LFだけしか改行とは認識しないはずです。） 動作環境の「ウィンドウ」でステータスバーにこのへんの情報を表示する ようにもできますし、上級者向け設定ではタイトルバーにも出す設定が できます。 また、ファイルタイプ別の設定の　デザイン→表示1　で「改行コードを 区別して表示」にチェックを入れておくと、CRは行頭方向（左または上）を 向いた矢印、LFは次行方向（下または左）を向いた矢印、CR+LFはこの 2つの動きを合成したカギ型の矢印、で表示されます。 https://i.imgur.com/h0a9Q8V.png 3番目のものは、2番目のものとファイルサイズが全く同一ならば効果なしです。 その場合、ファイル(F)→エンコードの種類(D)　で「改行＝CR+LF｝に変更して から保存してください。その場合、テキストの行数ピッタリだけ、ファイル サイズが増えるはずです。 もし最初から「改行＝CR+LF」になっていたら、一旦「改行＝CR」または 「改行＝LF」に切り替えて（そうすると上記の設定により、矢印の形が 変わります）、それから「改行＝CR+LF」に戻してみてください。 P.S. うまくいきましたら、「ご指摘いただいた◯◯が原因でした。◯◯をして うまくいきました。」という具合にお返事を投稿していただけると助かります。 アドバイスを出した側としても、そのアドバイスが的確だったかどうかの 判断材料があると嬉しいですので。

[ △ ]

RE:37853 保存で文字化け	No.37854
秀丸担当 さん　19/12/20 09:36
データはzipファイルで受け取りました。フィードバックさんありがとうございます。 データを見てみたところ、エンコードを誤って読み込んだとか保存したとか、そうい うデータでは無さそうでした。 バイナリ情報にして0x00〜0xFFの値がまんべんなく存在し、圧縮ファイルか暗号化さ れた情報のどちらかの可能性が高いと思います。 テキストファイルであれば例え誤ったエンコードだったとしても、00が多いとか制御 コードが少ないとかE3〜EAが多いとか、何らかの偏りの特徴が出るはずです。 EXEやDLLだったりプログラム上のデータだったとしても、何らかの偏りはあります。 例えばファイルの属性が暗号化属性になっていて、暗号化された情報が、OSレベルの 問題か何かで出てきてしまっていると、そうなったりする可能性がありそうな気がし ます。 全然違っていたらすみません。 関係あるかわからないですが参考情報： https://social.technet.microsoft.com/Forums/ja-JP/3a24b228-7f98-4ef1-8e7b-c8ad6e67581c/efs262632149521270125011244912452125231239825991233832127012369?forum=win10itprogeneralJP http://forums.techarena.in/windows-software/1357516.htm

[ △ ]

RE:37854 保存で文字化け	No.37855
フィードバック さん　19/12/20 21:01
やはりうちの環境がおかしいんでしょうね。 日数が前で、気付いたのが先日なので、どういう作業でこうなったかまで覚えていま せん。 何かノイズが入って１ビットずつずれたとか。ウイルスとか。数百キロバイト分のう ち数キロバイトをハードディスクに書き込み保存中にマシンが落ちて、壊れたデータ とか。そういう見方にしたいと思います。 改行うんぬんは、直前まで開けるデータの中を説明しただけで、問題なのはどのエン コードを指定しても化けることです。 ありがとうございました。

[ △ ]

---