ファイルの文字コードの判定No.05293
マボカル さん 06/11/07 03:33
 
こんにちは。マボカルです。
秀丸のマクロで可能なのか一つご質問させていただきます。

あるフォルダにいくつものテキストファイルが入っているとして、
そのそれぞれのファイルの文字コードはSJISだったりJISだったり、UTF-16だったり、
とにかくいろんな文字コードで保存されていると
します。

このような状況下で任意のフォルダ内の全てのテキストファイルの
文字コードが何であるのか、ファイル名と共にリストアップするような
ことは秀丸のマクロで可能でしょうか?

アイディアなどありましたらご教示いただきたく思います。
もしかしたら秀丸のマクロでやる以外にももっと簡単な方法があるかも
しれませんが、そこら辺も含めてよろしくお願いします。



[ ]
RE:05293 ファイルの文字コードの判定No.05294
いいじま さん 06/11/07 15:12
 
いいじまです。

> あるフォルダにいくつものテキストファイルが入っているとして、
> そのそれぞれのファイルの文字コードはSJISだったりJISだったり、
> UTF-16だったり、とにかくいろんな文字コードで保存されていると
> します。
>
> このような状況下で任意のフォルダ内の全てのテキストファイルの
> 文字コードが何であるのか、ファイル名と共にリストアップするような
> ことは秀丸のマクロで可能でしょうか?
>
> アイディアなどありましたらご教示いただきたく思います。
> もしかしたら秀丸のマクロでやる以外にももっと簡単な方法があるかも
> しれませんが、そこら辺も含めてよろしくお願いします。

Perl を使うのはどうでしょう。
ActivePerlのインストール、Jcode.pmのインストール、ActivePerlがデフォルトでは
ワイルドカードを受け付けないことにどう対応するか、と、やや面倒はありますが…。

#日本語用以外のエンコーディングは対象外です。

[ ]
RE:05294 ファイルの文字コードの判定No.05295
マボカル さん 06/11/07 15:39
 
いいじまさん

ありがとうございます。

>Perl を使うのはどうでしょう。
>ActivePerlのインストール、Jcode.pmのインストール、ActivePerlがデフォルトでは
>ワイルドカードを受け付けないことにどう対応するか、と、やや面倒はありますが…。

パールだと目的の作業を達成できるという可能性があるというわけ
ですね。このご説明だけではどう使うかよくわからないので、関連の
サイトを調べてみます。そういうスクリプトがあればいいのですが、
パールに関してははじめたばかりで、秀丸のマクロより書けません。

>#日本語用以外のエンコーディングは対象外です。

そうですか。実はSJIS, UTF-8, UTF-16以外にもハングルコードも
混じっている可能性があるため、それに関しては対象外となるので
しょうか。

もう少し作業について説明しますと、あるフォルダに入っている
ファイルの文字コードをUTF-8に統一しようとしているのですが、
ファイル数が多くて、とてもいちいち開いて確認できるものでは
ありません。ファイルの殆どはUTF-16になってはいるのですが、
一部にSJISとかハングルのコードとかが混ざっている可能性があるため
それを探し出そうとしているのです。

実はファイルの文字コードを一括して変換するマクロがライブラリに
ありまして、それを活用させていただいているわけですが、一部に
他のファイルとは違った文字コードのファイルが存在していると
ファイルの文字コードを一括して変換するのが不可能になります。

こういうファイルの文字コードを調べるという作業はマクロでは
難しいのでしょうか?

[ ]
RE:05293 ファイルの文字コードの判定No.05296
Iranoan さん 06/11/07 16:37
 
 マボカルさん今日は、Iranoan です。
<snip>
> 文字コードが何であるのか、ファイル名と共にリストアップするような
> ことは秀丸のマクロで可能でしょうか?
 大まかには可能ですが、完全には不可能です。
 理由は、秀丸は自動でエンコードの判定をしますが、自動判定を完全に行う
のは秀丸に限らず不可能だからです。大まかで良ければ、次のマクロでどうで
しょう?
--------------------------------------------------------------------
grep "(.|\n)", "*", ".", subdir, filelist, regular, icon;
showwindow 0;
disabledraw;
#grep = hidemaruhandle( 0 );
while( code != eof ){
  tagjump;
  #charset  = charset&63;
  if( #charset == 1 )$charset = "Shift-JIS";
  else if( #charset == 2  )$charset = "Unicode";
  else if( #charset == 3  )$charset = "EUC";
  else if( #charset == 4  )$charset = "JIS";
  else if( #charset == 5  )$charset = "UTF-7";
  else if( #charset == 6  )$charset = "UTF-8";
  else if( #charset == 7  )$charset = "Unicode (Big-Endian)";
  else if( #charset == 8  )$charset = "欧文";
  else if( #charset == 9  )$charset = "簡体字中国語";
  else if( #charset == 10 )$charset = "繁体字中国語";
  else if( #charset == 11 )$charset = "韓国語";
  else if( #charset == 12 )$charset = "韓国語(Johab)";
  else if( #charset == 13 )$charset = "中央ヨーロッパ言語";
  else if( #charset == 14 )$charset = "バルト語";
  else if( #charset == 15 )$charset = "ギリシャ語";
  else if( #charset == 16 )$charset = "キリル言語";
  else if( #charset == 17 )$charset = "シンボル";
  else if( #charset == 18 )$charset = "トルコ語";
  else if( #charset == 19 )$charset = "ヘブライ語";
  else if( #charset == 20 )$charset = "アラビア語";
  else if( #charset == 21 )$charset = "タイ語";
  else if( #charset == 22 )$charset = "ベトナム語";
  else if( #charset == 23 )$charset = "Macintosh";
  else if( #charset == 24 )$charset = "OEM/DOS";
  else if( #charset == 25 )$charset = "その他";
  else if( #charset == 26 )$charset = "バイナリモード";
  ##sub = hidemaruhandle( 0 );
  setactivehidemaru #grep;
  closehidemaru ##sub;
  golineend2;
  insert "\t" + $charset;
  movetolineno 1, lineno + 1;
}
replaceallfast "\([0-9]+\)\t", "\t", regular;
showwindow 1;

[ ]
RE:05295 ファイルの文字コードの判定No.05297
いいじま さん 06/11/07 16:38
 
いいじまです。

> >#日本語用以外のエンコーディングは対象外です。
>
> そうですか。実はSJIS, UTF-8, UTF-16以外にもハングルコードも
> 混じっている可能性があるため、それに関しては対象外となるので
> しょうか。
>
> もう少し作業について説明しますと、あるフォルダに入っている
> ファイルの文字コードをUTF-8に統一しようとしているのですが、
> ファイル数が多くて、とてもいちいち開いて確認できるものでは
> ありません。ファイルの殆どはUTF-16になってはいるのですが、
> 一部にSJISとかハングルのコードとかが混ざっている可能性があるため
> それを探し出そうとしているのです。

確認です。
ハングルは EUC-KR の範囲に収まっているでしょうか?
それとも、Windows が拡張した(EUC-KRから除外された文字をSJISのような未定義
コードに埋め込んだ)CP949のコードが混じっている可能性はありますか?
EUC-JPのファイルは混じっていますか?
それによってプログラミングの難易度が変わってきます。

Perlではバイナリデータの解析もプログラムを書けばできますから、まずは
ファイルを
「UTF-16と断定できるファイル」
「UTF-8に変換済みのファイル」
「SJISの可能性が高いファイル」
「ハングルの可能性が高いファイル」
のようにプログラムで分けてから、少数になる後2者については個別に開いて
最終的にエンコードごとに振り分けて変換マクロに食わせる、というのが合理的な
ように思います。

[ ]
RE:05297 ファイルの文字コードの判定No.05298
マボカル さん 06/11/07 17:43
 
いいじまさん

ありがとうございます。

>確認です。
>ハングルは EUC-KR の範囲に収まっているでしょうか?
>それとも、Windows が拡張した(EUC-KRから除外された文字をSJISのような未定義
>コードに埋め込んだ)CP949のコードが混じっている可能性はありますか?
>EUC-JPのファイルは混じっていますか?
>それによってプログラミングの難易度が変わってきます。

不勉強なもので、韓国語の代表的な文字コード(完成型=EUC-KR、
組合型=Johab)はわかるのですが、そのコード体系にCP949のコードが
混じっているかどうかはわかりません。
http://home.att.ne.jp/yellow/han-lab/com/code1.html#ksset1
http://ja.wikipedia.org/wiki/EUC-KR
http://www013.upp.so-net.ne.jp/ranran/re-world/cjk-n.html

韓国のサイトでは拡張完成型 (Unified Hangul Code) という記述も
ありますので、CP949のコードが混じっているのはそっちのほうなの
でしょうか?いずれにしてもよくわかりません。
http://b.mytears.org/2005/01/101

1.組合型 (Johab)
2.完成型(EucKR)
3.拡張完成型 (Unified Hangul Code)
4.iso2022-kr

>Perlではバイナリデータの解析もプログラムを書けばできますから、まずは
>ファイルを
>「UTF-16と断定できるファイル」
>「UTF-8に変換済みのファイル」
>「SJISの可能性が高いファイル」
>「ハングルの可能性が高いファイル」
>のようにプログラムで分けてから、少数になる後2者については個別に開いて
>最終的にエンコードごとに振り分けて変換マクロに食わせる、というのが合理的な
>ように思います。

1つ目と2つ目のユニコードのファイルは文字コードの表記自体が
ユニコードであると明示的に書かれているために、機械的な振り分けが
可能であり、残りの3つめと4つめのファイルに関しては、ある程度
特定は出来るが機械的に完全な断定は出来ないということで理解して
もよろしいでしょうか。

文字コードの種類の特定も機械的には難しいのですね。ちなみに
ユニコードの場合だと、BOM付きでなくても特定が可能なのでしょうか?

いろいろと勉強させていただきます。

[ ]
RE:05296 ファイルの文字コードの判定No.05299
マボカル さん 06/11/07 17:49
 
Iranoanさん

ありがとうございます。

> 大まかには可能ですが、完全には不可能です。
> 理由は、秀丸は自動でエンコードの判定をしますが、自動判定を完全に行う
>のは秀丸に限らず不可能だからです。大まかで良ければ、次のマクロでどうで
>しょう?

そうなんですか。文字コードは奥が深いですね。問題が発生するたびに
そのつど勉強していかないとついていけなくなります。

マクロを実行してみました。対象となるフォルダへ行って、どれか一つ
ファイルを開いた上で実行するのですよね。こんな感じでUTF-16以外の
ファイルを特定できました。

jb0612jj.txt(1) Unicode
jb0612jk.txt(1) Unicode
jb0613jj.txt(1) Unicode
jb0613jk.txt(1) Unicode
jb0614jj.txt(1) Unicode
jb0614jk.txt(1) Unicode
ji0601kj.txt(1) Unicode
ji0601kk.txt(1) Unicode
ji0602kj.txt(1) Unicode
ji0602kk.txt(1) Unicode
jk0601jj.txt(1) Shift-JIS ←探していたのはこれと
jk0601jk.txt(1) 韓国語   ←これ
jk0602jj.txt(1) Unicode
jk0602jk.txt(1) Unicode
jk0603jj.txt(1) Unicode
jk0603kk.txt(1) Unicode

これで事が足りました。どうもありがとうございました。

ところで参考までに

>大まかには可能ですが、完全には不可能です。

というのはどういう意味で大まかだというのでしょうか?今回は
うまく特定できましたが、ファイルの内容、つまり記述されている
文字コードによってはうまく特定できない場合もあるということ
でしょうか?勉強させていただきたく思います。

[ ]
RE:05299 ファイルの文字コードの判定No.05300
マボカル さん 06/11/07 18:17
 
追加で報告いたします。

>大まかには可能ですが、完全には不可能です。

この点に関していろんなファイルで試してみたところ、判定に
失敗したファイルもありました。

UTF-8なのにShift-JISと判定
UTF-16なのにShift-JISと判定
HangulなのにShift-JISと判定

うまく判定できたファイルと比べるとどういう点が違って
誤判断したのでしょうか?といってもこれはファイルの内容を
お見せしないとわからないことなのでしょうか?

またUnicodeの場合はBOM付とそうでない場合とでも判断に
違いが出るのでしょうか?

[ ]
RE:05299 ファイルの文字コードの判定No.05301
Iranoan さん 06/11/07 18:32
 
 マボカルさん今日は、Iranoan です。
> >大まかには可能ですが、完全には不可能です。
>
> というのはどういう意味で大まかだというのでしょうか?
 自動判定を ON にしていてもファイルによっては、複数のエンコードのどれ
と想定しても問題ないので、どのエンコードとして開くか確認が出ることが有
りますよね。
 半角カタカナだかで書かれたファイルだと頻繁に起きます。

[ ]
RE:05301 ファイルの文字コードの判定No.05302
マボカル さん 06/11/07 21:06
 
Iranoanさん

ありがとうございます。

> 自動判定を ON にしていてもファイルによっては、複数のエンコードのどれ
>と想定しても問題ないので、どのエンコードとして開くか確認が出ることが有
>りますよね。
> 半角カタカナだかで書かれたファイルだと頻繁に起きます。

私は半角カタカナは使わないので、それ以外の文字コードでそうなって
いると思いますが、たとえばユニコードのファイルで韓国語で書かれた
内容だとすると、文字コードを強制的にハングルコードに変えることで
文字化けした文字の中に半角カタカナが入っていることがありますが、
特に半角カタカナでの内容でなくても、コード値として半角カタカナに
相当するものが一つの誤判断の原因になっていると考えてもいいの
でしょうか?

この文字コードの判定というのが不思議で、ファイルのどこまで見て
判定しているのかも気になります。初めの何文字かだけ見ているのか、
全体的に見ているのかなどなど。

この辺はエディタ側で判定しているので、サイトー企画さん独自の
判定方法があるんでしょうかね?

ご意見参考になりました。

[ ]
RE:05302 ファイルの文字コードの判定No.05303
Iranoan さん 06/11/08 00:28
 
 マボカルさん今日は、Iranoan です。
> たとえばユニコードのファイルで韓国語で書かれた
> 内容だとすると、文字コードを強制的にハングルコードに変えることで
> 文字化けした文字の中に半角カタカナが入っていることがありますが、
> 特に半角カタカナでの内容でなくても、コード値として半角カタカナに
> 相当するものが一つの誤判断の原因になっていると考えてもいいの
> でしょうか?
 そう言えば、先の投稿で、
> UTF-8なのにShift-JISと判定
> UTF-16なのにShift-JISと判定
> HangulなのにShift-JISと判定
ということでしたね。UTF-8 は Unicode の一種なので、ひょっとすると、誤
判定が起きるのは想定外かもしれません。そんなわけで内容が英数字のみで書
かれたファイルでなければ、秀丸担当さんにご報告したほうが良いかも知れま
せん。

> またUnicodeの場合はBOM付とそうでない場合とでも判断に
> 違いが出るのでしょうか?
については、詳しくはヘルプを御覧ください。一般的には、付けた方が認識率
はあがりますが、本来 UTF-8 では付けないはずです。

> この文字コードの判定というのが不思議で、ファイルのどこまで見て
> 判定しているのかも気になります。初めの何文字かだけ見ているのか、
> 全体的に見ているのかなどなど。
 現在の最新版は、確か全体を見て、どのエンコードの可能性が高い見ていた
と思います。過去ログを「自動認識」で検索し、「秀丸担当」さん、「秀まる
お」さんの投稿で絞り込めば見つかるとは思うのですが...、それだけの気力
はありません(^^;。

[ ]
RE:05303 ファイルの文字コードの判定No.05304
マボカル さん 06/11/08 01:23
 
Iranoanさん

ありがとうございます。

> マボカルさん今日は、Iranoan です。
>> たとえばユニコードのファイルで韓国語で書かれた
>> 内容だとすると、文字コードを強制的にハングルコードに変えることで
>> 文字化けした文字の中に半角カタカナが入っていることがありますが、
>> 特に半角カタカナでの内容でなくても、コード値として半角カタカナに
>> 相当するものが一つの誤判断の原因になっていると考えてもいいの
>> でしょうか?
> そう言えば、先の投稿で、
>> UTF-8なのにShift-JISと判定
>> UTF-16なのにShift-JISと判定
>> HangulなのにShift-JISと判定
>ということでしたね。UTF-8 は Unicode の一種なので、ひょっとすると、誤
>判定が起きるのは想定外かもしれません。そんなわけで内容が英数字のみで書
>かれたファイルでなければ、秀丸担当さんにご報告したほうが良いかも知れま
>せん。

もともと完全に判定できるものではないということですので、取り立て
てどうにかしてくれと問題化するわけではありませんが、バクらしき
ものでしたら、報告したほうが秀丸ユーザーのためにもなりますし、
一応報告しておきます・・・。と思って報告のためにもう一度Iranoan
さんから頂いたマクロを実行して、ファイルを確認している過程で
気づいたのですが、これは文字コード判定の問題の前に、別の問題で
起こっているのではないかと思い始めました。

実はここにその問題を報告してありますが
http://www.maruo.co.jp/hidesoft/2/x22142_.html?a=2#22142

一部タグジャンプが出来ないファイルがあるという問題で、マクロの
動きにも影響が出ているのではないかということです。Iranoanさんの
マクロを見ると、まずGrepでリストを作成した後、そのリストを元に
ファイル一つ一つにジャンプして文字コードを判定後、再びGrepリスト
に戻って、結果を貼り付けるという過程だと思いますが、このとき
タグジャンプに失敗したものは、結果がSJISになるのではないかと
いうことです。

(書き込み中にそういえばとアイディアが浮かぶ)

と思って、それでは現状で問題となっているタグジャンプの出来ない
ファイルの名前を半角英数字とかに変えて、もう一度Iranoanさんの
マクロを実行したところ、今度はうまく判定出来ていました。
やっぱりタグジャンプが問題で、マクロが正しく動いていなかった
ようです。

タグジャンプの問題が解決した後にもう一度マクロのテストを
行ってみたいと思います。

>> またUnicodeの場合はBOM付とそうでない場合とでも判断に
>> 違いが出るのでしょうか?
>については、詳しくはヘルプを御覧ください。一般的には、付けた方が認識率
>はあがりますが、本来 UTF-8 では付けないはずです。

本来UTF-8にはBOMはつけないんですね。ヘルプ等を詳しく読んでみます。

>> この文字コードの判定というのが不思議で、ファイルのどこまで見て
>> 判定しているのかも気になります。初めの何文字かだけ見ているのか、
>> 全体的に見ているのかなどなど。
> 現在の最新版は、確か全体を見て、どのエンコードの可能性が高い見ていた
>と思います。過去ログを「自動認識」で検索し、「秀丸担当」さん、「秀まる
>お」さんの投稿で絞り込めば見つかるとは思うのですが...、それだけの気力
>はありません(^^;。

過去ログをもとに、どういう検索語で探せば関連した内容が出てくる
かもしれないというヒントだけおっしゃってもらっただけでも大変
助かりました。調べてみます。
ありがとうございました。

[ ]
RE:05300 ファイルの文字コードの判定No.05305
アルビレオ さん 06/11/08 01:38
 
ユーザーのアルビレオです。

>この点に関していろんなファイルで試してみたところ、判定に
>失敗したファイルもありました。
>
>UTF-8なのにShift-JISと判定
>UTF-16なのにShift-JISと判定
>HangulなのにShift-JISと判定
>
>うまく判定できたファイルと比べるとどういう点が違って
>誤判断したのでしょうか?といってもこれはファイルの内容を
>お見せしないとわからないことなのでしょうか?

文字コードの判定というのはいくつかの候補を仮定して「その文字エンコードで
はありえないコードが出てきたら候補から除外」という消去法ぐらいしか方法が
ありません。
消去法で複数の候補が残った場合は適当に優先順位をつけて選ぶしかなく、秀丸
エディタのユーザー層や実行環境を考えれば外国語よりも日本語、日本語の候補
が複数あった場合はShiftJISだと仮定するのは妥当なところでしょう。

そういうわけで短いテキストでは誤判定の可能性は高くなりますし、正しく判定
できない例を示してもコードとしては矛盾していないものであれば改善には繋が
らないことも十分考えられます。
だから「文字コードとしては矛盾がないけど文字列としてはムチャクチャ」みた
いなものは結局人間の目で判定する必要があります。(パスワードのように意図
的にデタラメな文字列になっていることも考えられるので)

>またUnicodeの場合はBOM付とそうでない場合とでも判断に
>違いが出るのでしょうか?

本来UTF-8の仕様はBOMをつけないのが正しいのですが、BOMをつけても特に問題
はないので文字エンコードを正しく認識させる方法としては有効だと思います。
ちなみにUnicodeにBOMは存在しません。「UTF-なんたら」といったUnicodeを元
にしたエンコードの中に出てくる特殊文字という扱いです。

[ ]
RE:05304 ファイルの文字コードの判定No.05308
秀丸担当 さん 06/11/08 10:29
 

自動判定をする方法は、[ファイル]→[開く]→[自動判定の設定](または[動作
環境]→[ファイル]→[エンコード1])で指定します。

各エンコードのチェック状態と、「複数のエンコードの種類に適合する場合」で
精度が変化します。
「複数のエンコードの種類に適合する場合」が「最初に確定したものにする」だ
と、ファイルの最後まで全て解析しません。
最初にShift-JISと思わしき文字があって、最後のほうに韓国語があったとして
も、Shift-JISになります。
「優先順位に従う」または「候補の一覧を表示」だと、ファイルの最後まで解析
します。

ですが、マクロの場合は、常に「最初に確定したものにする」として動作してい
ます。
V4.10β1では動作環境の設定が影響するようにしていましたが、マクロで「候補
の一覧を表示」でダイアログが出てくる場合があるのはマクロの動作が止まって
しまうので非互換ということで、「最初に確定したものにする」で固定というこ
とになりました。

でも「優先順位に従う」の場合は、マクロの実行に影響も無く精度が高まるので
マクロでも有効にしたほうがよかったかもしれません。

[ ]
RE:05305 ファイルの文字コードの判定No.05311
マボカル さん 06/11/08 16:18
 
アルビレオさん

ありがとうございます。

>文字コードの判定というのはいくつかの候補を仮定して「その文字エンコードで
>はありえないコードが出てきたら候補から除外」という消去法ぐらいしか方法が
>ありません。

なるほど。そういう判定法ですか。

>消去法で複数の候補が残った場合は適当に優先順位をつけて選ぶしかなく、秀丸
>エディタのユーザー層や実行環境を考えれば外国語よりも日本語、日本語の候補
>が複数あった場合はShiftJISだと仮定するのは妥当なところでしょう。

この辺も納得しました。もともと日本語用のエディタを多言語処理に
対応しているものなので、妥当だと思います。

>そういうわけで短いテキストでは誤判定の可能性は高くなりますし、正しく判定
>できない例を示してもコードとしては矛盾していないものであれば改善には繋が
>らないことも十分考えられます。
>だから「文字コードとしては矛盾がないけど文字列としてはムチャクチャ」みた
>いなものは結局人間の目で判定する必要があります。(パスワードのように意図
>的にデタラメな文字列になっていることも考えられるので)

全体的にファイルを見て判断しているということですね。その辺が
知りたい部分でもありました。

>ちなみにUnicodeにBOMは存在しません。「UTF-なんたら」といったUnicodeを元
>にしたエンコードの中に出てくる特殊文字という扱いです。

秀丸エディタでは保存のときに

Unicode(UTF-16)
Unicode(UTF-16,Big-Endian)
Unicode(UTF-7)
Unicode(UTF-8)

と出ますから、全体でUnicodeと呼んで、その中で「UTF-なんたら」と
言うときの説明でBOMという表現を使うべきだということで理解すれば
よろしいのですね。

ちなみにUTF-16で保存したファイルを秀丸エディタで開くと、タイトル
バーやステイタスバーには[Unicode]と表示されますが、本来これは
UTF-16と表示するのが正しいというわけでしょうか?

秀丸エディタでの表記をみて、Unicode=UTF-16という関係があって、
取り立てて「UTF-なんたら」といわない限りUnicodeという表現が
なされている場合は、UTF-16とみなすものと思っていました。

この部分は一般にどういった概念で理解すればいいのでしょうか?
他のエディタなどはどう表記されているのでしょうか?

[ ]
RE:05308 ファイルの文字コードの判定No.05312
マボカル さん 06/11/08 16:28
 
秀丸担当さん

ご回答ありがとうございます。

>自動判定をする方法は、[ファイル]→[開く]→[自動判定の設定](または[動作
>環境]→[ファイル]→[エンコード1])で指定します。
>
>各エンコードのチェック状態と、「複数のエンコードの種類に適合する場合」で
>精度が変化します。
>「複数のエンコードの種類に適合する場合」が「最初に確定したものにする」だ
>と、ファイルの最後まで全て解析しません。
>最初にShift-JISと思わしき文字があって、最後のほうに韓国語があったとして
>も、Shift-JISになります。
>「優先順位に従う」または「候補の一覧を表示」だと、ファイルの最後まで解析
>します。

なるほど。そういう仕組みでしたか。精度を高めるための細かな設定は
例えるならOCRで文字をテキスト化する際の、漢字・仮名・カナ・
数字・アルファベット・記号などなど、画像ファイルの内容にあわせて
どういう文字の認識度の精度を上げたいかというときに行う、チェック
項目のかけ方によって変わってくるようなものですね。ちょっと例えが
変でしょうか?

>ですが、マクロの場合は、常に「最初に確定したものにする」として動作してい
>ます。
>V4.10β1では動作環境の設定が影響するようにしていましたが、マクロで「候補
>の一覧を表示」でダイアログが出てくる場合があるのはマクロの動作が止まって
>しまうので非互換ということで、「最初に確定したものにする」で固定というこ
>とになりました。

マクロで動くときとはまた判定方法が違うんですね。

>でも「優先順位に従う」の場合は、マクロの実行に影響も無く精度が高まるので
>マクロでも有効にしたほうがよかったかもしれません。

どうしてほしいというわけではありませんが、今回の投稿がこういった
事例もあるということで参考になればと思います。

[ ]
RE:05311 ファイルの文字コードの判定No.05313
アルビレオ さん 06/11/08 17:18
 
アルビレオです。

>ちなみにUTF-16で保存したファイルを秀丸エディタで開くと、タイトル
>バーやステイタスバーには[Unicode]と表示されますが、本来これは
>UTF-16と表示するのが正しいというわけでしょうか?
>
>秀丸エディタでの表記をみて、Unicode=UTF-16という関係があって、
>取り立てて「UTF-なんたら」といわない限りUnicodeという表現が
>なされている場合は、UTF-16とみなすものと思っていました。
>
>この部分は一般にどういった概念で理解すればいいのでしょうか?
>他のエディタなどはどう表記されているのでしょうか?

普通はあまり意識する必要はないんですが、フルセットのUnicode(≒UCS-4)を表
現するには1文字21ビット必要になります。
これを単純に1文字=4バイトにしたものがUTF-32ですが、実際には漢字やハン
グル文字を含むほとんどの文字は16ビットコード(UCS-2)に収まっているため、
基本は1文字=2バイト、古代文字などのめったに使われない文字は1文字=4
バイトに拡張するのがUTF-16です。
このためごく一部の例外を除けば「UTF-16とUnicodeは同一」と考えることがで
きます。
UTF-8はアルファベットや数字は1バイトで表せるようにしたもので、漢字など
は3バイトになるかわりに英数字は従来のASCIIコードと互換性があります。

詳しい解説
http://ja.wikipedia.org/wiki/Unicode
http://www.ffortune.net/comp/develop/data/utf.htm

[ ]
RE:05312 ファイルの文字コードの判定No.05314
秀丸担当 さん 06/11/08 17:51
 

>なるほど。そういう仕組みでしたか。精度を高めるための細かな設定は
>例えるならOCRで文字をテキスト化する際の、漢字・仮名・カナ・
>数字・アルファベット・記号などなど、画像ファイルの内容にあわせて
>どういう文字の認識度の精度を上げたいかというときに行う、チェック
>項目のかけ方によって変わってくるようなものですね。ちょっと例えが
>変でしょうか?

まあ、そんなようなものかもしれません。

>どうしてほしいというわけではありませんが、今回の投稿がこういった
>事例もあるということで参考になればと思います。

次のV6.06β3で「最初に確定したものにする」以外の場合は、マクロでは全て解
析する方法ようにしてみようと思います。

[ ]
RE:05313 ファイルの文字コードの判定No.05315
マボカル さん 06/11/08 18:13
 
アルビレオさん

>普通はあまり意識する必要はないんですが、フルセットのUnicode(≒UCS-4)を表
>現するには1文字21ビット必要になります。
>これを単純に1文字=4バイトにしたものがUTF-32ですが、実際には漢字やハン
>グル文字を含むほとんどの文字は16ビットコード(UCS-2)に収まっているため、
>基本は1文字=2バイト、古代文字などのめったに使われない文字は1文字=4
>バイトに拡張するのがUTF-16です。
>このためごく一部の例外を除けば「UTF-16とUnicodeは同一」と考えることがで
>きます。
>UTF-8はアルファベットや数字は1バイトで表せるようにしたもので、漢字など
>は3バイトになるかわりに英数字は従来のASCIIコードと互換性があります。

詳しく分かりやすいご説明ありがとうございます。

>詳しい解説
>http://ja.wikipedia.org/wiki/Unicode
>http://www.ffortune.net/comp/develop/data/utf.htm

こちらも参考にさせて頂きます。情報提供ありがとうございました。

[ ]
RE:05314 ファイルの文字コードの判定No.05316
マボカル さん 06/11/08 18:14
 
>次のV6.06β3で「最初に確定したものにする」以外の場合は、マクロでは全て解
>析する方法ようにしてみようと思います。

いろいろ試してみて、もっと使いやすくなるといいですね。

[ ]