UTF-8ファイル編集について - 秀丸エディタ関連ソフト会議室 - スレッド12106, 2002/06/15

UTF-8ファイル編集について

Ya-Bo- さん　02/06/15 14:48

皆さん、こんにちはYa-Bo-です。お世話になります。
確認していただきたいことがあります。
UTF-8コードのファイルを編集後、保存して
もう一度開くと、文字化けを起こしてしまいます。

＜設定＞
保存・読込みの設定は
１．標準文字コード(D)→自動選択、改行=自動
２．保存するときの変換(C)→変換なし
３．読み込むときのEOF制御文字を無視(F)をチェック

＜現象＞
１．UTF-8で書かれたファイルを開くと、
　　タイトルバーには、
　　　　ファイル名 [UTF-8][LF]-秀丸
　　と表示されます。
２．そこで編集を行い上書き保存後もう一度開くと
　　タイトルバーには、
　　　　ファイル名[SHIFT-JIS][LF]-秀丸
　　となって表示が化けてしまいます。

＜調査結果＞
編集前後でファイルがどうなっているかをBINARY Editorで
調査すると、ファイルの先頭の3バイト分
　0xEF 0xBB 0xBF
が消えてしまっているようです。
そこで、化けてしまったファイルに上記3バイトを書き足した
後、再び秀丸でオープンすると、文字化けは解消され
タイトルバーもUTF-8と表示されるようになります。
以上の現象について、過去に何らかの記述があった場合
はご容赦ください。また、長い書き込みになったことをお詫びします。

以上ご確認ください。

RE:12106 UTF-8ファイル編集について

ひろさん　02/06/15 23:50

　Ya-Bo- さん今日は、ひろです。
> ファイルの先頭の3バイト分
> 　0xEF 0xBB 0xBF
> が消えてしまっている
　この原因は分かりませんが、「動作環境」の「編集」→「文字コードを自
動認識する」を ON にするとどうでしょうか? もし既に ON なら [詳細] の
指定はどうなっていますか?

RE:12106 UTF-8ファイル編集について

vickwei さん　02/06/16 00:21

　こんにちは。vickweiです。

>調査すると、ファイルの先頭の3バイト分
>　0xEF 0xBB 0xBF
>が消えてしまっているようです。

　「0xEF 0xBB 0xBF」は「BOM」(Byte Order Mark)ですね。ヘルプ等ではなく私の
勝手な理解ですが、秀丸はUTF-8で保存する時に、この「BOM」を付けない仕様(?)
のように思います。このために「0xEF 0xBB 0xBF」が消えてしまうのではないでし
ょうか。

　私の方で試してみたところ、UTF-8ファイルを編集後、保存して再度開いてもち
ゃんとUTF-8として認識され、文字化けは起こりませんでした。
　勝手な想像ですが、改行コードが「LF」というのが何か関係あるのかもしれませ
ん。私の場合はもともとWindowsで作成していたファイルですので、改行コードは
「CR+LF」でした。

……何の解決にもならず、申し訳ありません……。

RE:12112 UTF-8ファイル編集について

vickwei さん　02/06/16 00:34

>勝手な想像ですが、改行コードが「LF」というのが何か関係あるのかも
>しれません。私の場合はもともとWindowsで作成していたファイルです
>ので、改行コードは「CR+LF」でした。

　いい加減なことを書いてしまい、申し訳ありません。
　改行コードを「LF」にして、編集、保存、開く、を繰り返しても、UTF-8として
開いてくれました。
　「文字コードの自動認識」をon、「詳細」では「日本語EUC」をoff、それ以外を
onにしています。

RE:12109 UTF-8ファイル編集について

Ya-Bo- さん　02/06/16 23:06

ひろさんへ
Ya-Bo-です。
毎度、貴重なご意見とご指摘感謝いたします。
>　Ya-Bo- さん今日は、ひろです。
>> ファイルの先頭の3バイト分
>> 　0xEF 0xBB 0xBF
>> が消えてしまっている
>　この原因は分かりませんが、「動作環境」の「編集」→「文字コードを自
>動認識する」を ON にするとどうでしょうか? もし既に ON なら [詳細] の
>指定はどうなっていますか?
確かに、動作環境の編集の自動認識にチェックを入れると文字化けは
発生しないようです。（先頭の3バイトの有無にかかわらず）
ただし、編集後の保存ファイルは、例の３バイトは消えてしまって
いるため、UNIXマシーンへFTP（Binary)転送で転送してリードすると
コードエラーとなってしまうようです。（アプリケーションで読み込ん
でいます）
逆に、上記設定のチェックをはずして、文字化けが起こるようにして
コード欠落の確認をするようにしておいたほうがいいのかも知れませんね。
もしくは、UNIXマシーン上で、先頭３バイトの欠落でもコードエラー
にならないように、ソフト変更を考える必要があるのかもしれません。

RE:12112 UTF-8ファイル編集について

Ya-Bo- さん　02/06/16 23:25

vickweiさん
はじめました。Ya-Bo-です。
貴重な情報ありがとうございます。
>　こんにちは。vickweiです。
>
>>調査すると、ファイルの先頭の3バイト分
>>　0xEF 0xBB 0xBF
>>が消えてしまっているようです。
>
>　「0xEF 0xBB 0xBF」は「BOM」(Byte Order Mark)ですね。ヘルプ等ではなく私の
>勝手な理解ですが、秀丸はUTF-8で保存する時に、この「BOM」を付けない仕様(?)
>のように思います。このために「0xEF 0xBB 0xBF」が消えてしまうのではないでし
>ょうか。
>
なるほど、秀丸の仕様（？）なわけですね。
ひろさんへの返信書き込みでも書いたのですが、現在開発中の
アプリケーションで、UTF-8で書かれたリソースファイルを
読み込むと言う分部があり、読込み後のファイルのチェックに
「BOM」の有無をチェックしており、この分部のチェックをはずす
必要があるかもしれません。
>　私の方で試してみたところ、UTF-8ファイルを編集後、保存して再度開いてもち
>ゃんとUTF-8として認識され、文字化けは起こりませんでした。
>　勝手な想像ですが、改行コードが「LF」というのが何か関係あるのかもしれませ
>ん。私の場合はもともとWindowsで作成していたファイルですので、改行コードは
>「CR+LF」でした。
>
私の環境でも、ひろさんの指摘にあった設定で、文字化けはせずに
開くことが確認できました。（「BOM」の有無にかかわらず）

>……何の解決にもならず、申し訳ありません……。
いえいえ、とんでもありません。大変参考になりました。
現在開発中のシステムのリソースの編集は、私のように秀丸を使っている
者とそうでない者がおり、この辺に「BOM」の有り無しの不整合がでていた
ため、UNIX側のアプリケーションで「BOM」のチェックを行っていたの
ですが、原因がどうも秀丸で編集したリソースにあるということになり
調査して、結果をこちらに書き込んだ次第です。

できれば、秀丸も「BOM」を「つける」/「つけない」の設定があれば
ありがたいのですが。

RE:12116 UTF-8ファイル編集について

小西さん　02/06/17 09:32

小西です。

XML関連でUTF-8を使うので、ちょこっと気になったので調べてみたのですが...

http://homepage1.nifty.com/nomenclator/unicode/ucs_utf.htm

ここの記述によれば、UTF-16にはBOMがありますが、UTF-8にはBOMはないとあります。
また、BOMのタグもWindowsの場合リトルエンディアンですから、FF FEとなります。
私は今までUTF-8、-16ともにBOMがFEFFでエンディアンでひっくり返ったりと思って
いたので、ちょっとびっくり。
果たして現在の正しい定義はどうなのでしょうか？

RE:12118 UTF-8ファイル編集について

小西さん　02/06/17 09:48

小西です

追加です。

UTF-8は、1～4バイトの可変文字コードなので、扱うときにはエンディアンにかかわ
らず、必ずバイト単位で処理する必要があるのですね。
勉強になりました。

RE:12118 UTF-8ファイル編集について

Ya-Bo- さん　02/06/17 11:47

小西さん。こんにちは、Ya-Bo-です。
アドバイスありがとうございます。
私の理解不足と調査不足が露呈しまい恥ずかしい次第です。
>小西です。
>
>XML関連でUTF-8を使うので、ちょこっと気になったので調べてみたのですが...
>
>http://homepage1.nifty.com/nomenclator/unicode/ucs_utf.htm
>
>ここの記述によれば、UTF-16にはBOMがありますが、UTF-8にはBOMはないとあります。
>また、BOMのタグもWindowsの場合リトルエンディアンですから、FF FEとなります。
>私は今までUTF-8、-16ともにBOMがFEFFでエンディアンでひっくり返ったりと思って
>いたので、ちょっとびっくり。
>果たして現在の正しい定義はどうなのでしょうか？
UTF-8コードの場合はもともと、BOMがつかないわけですから、
UTF-8の編集をサポートしている秀丸は当然、UTF-8で保存するとき
この分部がついていた場合は取り除くということで、動作としては
正しいということですね。
アプリケーション側のソフト変更及び、リソース作成時の
エディター（秀丸以外を使用している人のもの）をもう一度調査して、
対応したいと思います。

この場の書き込みをお借りして、
　皆さん、大変お騒がせ致しました。
　また、何か情報がありましたら、ご教授下さいますようお願いします。