ステータスに表示される文字コード

  1. シフトJISで保存されているテキストの中黒にカーソルを合わせるとステータスに表示される文字コードが「0x30FB」になります。
    バイナリエディタで見ると「0x8145」となっています、保存されているエンコードに合わせた文字コードの表示にはならないのでしょうか?

     |  pico  |  返信
  2. ご愛用いただきありがとうございます。

    > シフトJISで保存されているテキストの中黒にカーソルを合わせるとステータスに表示される文字コードが「0x30FB」になります。

    はい。Mery では、シフト JIS のファイルを編集する場合でも、内部的には Unicode でデータを管理しています。

    そのため、たとえば中黒 (・) の場合、ステータスバーには「U+30FB」という Unicode のコードポイントが表示されます。

    なお、現在の表示仕様としては、Unicode (UTF-8、UTF-7、UTF-16) の場合は「U+30FB」、それ以外 (シフト JIS、JIS、EUC など) の場合は「0x30FB」と表示されます。

    これは内部処理の違いによるもので、Unicode の場合はサロゲートペア (1 文字を 2 つの値で表す仕組み) に対応しています。

    いずれの場合も表示しているのは Unicode のコードポイントであり、シフト JIS などのエンコードにおけるバイト列を表示しているわけではありません。

    > バイナリエディタで見ると「0x8145」となっています、保存されているエンコードに合わせた文字コードの表示にはならないのでしょうか?

    もし、エンコードに応じたバイト列 (例:「0x81 0x45」) を表示してほしい、というご要望でしたら、どのような用途で必要とされているのか教えていただけると、今後の検討の参考にさせていただきたいと思います。

     |  Kuro  |  返信
  3. 返信ありがとうございます。
    コードポイントの表示について理解できました。

    > もし、エンコードに応じたバイト列 (例:「0x81 0x45」) を表示してほしい、というご要望でしたら、どのような用途で必要とされているのか教えていただけると、今後の検討の参考にさせていただきたいと思います。

    とある装置へ送信するテキストファイル(シフトJIS)の内容が正しく格納されたかを確認するために使用していました。
    その装置では16進数で内容を確認するしかなく、今まで半角英数字であったのに全角中黒が含まれるようになり、Meryでコードポイントを確認したとき違うなとなった次第です。
    バイナリエディタを使えば良かったのですが、テキスト編集にも便利なのでMeryポータブル版を実機に入れていました。

     |  pico  |  返信
  4. ご返信ありがとうございます。

    なるほど、おっしゃるように、装置に送るデータの確認という用途ですと、コードポイントよりも「実際のバイト列」が見えたほうが安心ですよね。普段の編集の流れの中で確認したい、というのもとても納得しました。

    ご要望としても実用的だと感じました。

    もし対応する場合は、Unicode 以外のエンコードについては、たとえば次のように

    • コードポイント (U+XXXX)
    • エンコード後のバイト列 (例: 0x81 0x45)

    の両方を表示できるようにすると、分かりやすくなりそうですね。

    すぐに対応できるかはまだ分かりませんが、今後の改善の検討材料にさせていただきたいと思います。

     |  Kuro  |  返信
  5. MeryRowCol.dll に文字コードの表示機能を追加してみました。
    ダウンロードは以下から可能です。
    https://www.bonsfm.com/merywindows/meryrowcoldllwin

    プロパティ画面のコンボボックスの候補に「文字コード」を追加しました。
    デフォルトではコンボボックスの7個目が「文字コード」に設定されます。

    ## Ver8.40 2026-03-26
    - プロパティ画面の内容で、文字コードの表示を設定するコンボボックスを追加しました
    カーソル位置の UTF16の文字コードと Ansiの文字コードを表示します
    画面上の文字が「・」の場合で「UTF16」「UTF8」「UTF7」の場合は
    U+30FB 0x81 0x45
    それ以外は
    0x30FB 0x81 0x45
    と表示します

    最近の発言で「マーカー機能」を使ってみました。
    今回の場合も「・」をマーカー機能で追加すると見ただけで判定できますね。

    よろしくお願いします。

    別件ですがDelphiのFMXで開発を始めました。
    文字通りWindowsとiOSで同じコードで開発が可能ですね。
    ただしプラットフォームにより異なり個所は個別に記述します。
    なおiOSではフォームを複数作成すると安定しないようです。
    最終的にフォームは1個にしてLayOutのVisibleを切り替えて作成しました。
    iOSでのシュミレーションでの確認は終わりましたが、実機での動作確認はこれからです。
    公開できましたら、別途報告させていただきます。
    来週でComunityEditionのライセンスがきれますが更新する予定です。

    よろしくお願いします。

     |  大石剛司  |  返信
  6. こんばんは~。

    MeryRowCol.dll のアップデート、さっそく拝見しました。文字コード値の表示機能の追加、とても分かりやすくて良いですね。

    これを使えば、pico さんのご要望はうまく満たせそうですね。

    ちょうど私も Mery に実装しようとしていたのですが、仕様をどうするかで少し悩んでいたところでした。

    エンコードがシフト JIS や EUC などの場合は、レガシーなシステムで扱うケースもあると思うので、

    U+30FB (0x81 0x45)
    

    のように、シフト JIS のバイト列として表示する需要はありそうだと感じています。

    一方で、UTF 系の場合はバイト列を表示するメリットがあまり思いつかなくて…。

    たとえば UTF-8 の場合に

    U+30FB (0xE3 0x83 0xBB)
    

    や、UTF-7 の場合に

    U+30FB (0x2B 0x4D 0x50 0x73 0x2D)
    

    と表示されても、ステータスバーが賑やかになるだけで、あまり実用的ではない気がしています。

    必要以上の情報は表示しないほうが見やすさの面でも良いと思うので、UTF 系以外のときだけバイト列を表示する、という仕様もありかなと考えていました。

    > 最近の発言で「マーカー機能」を使ってみました。
    > 今回の場合も「・」をマーカー機能で追加すると見ただけで判定できますね。

    マーカー機能、お試しいただきありがとうございます。

    実は私自身はあまり使っていなかったのですが、誤ったデータの混入チェックや表記ゆれの確認など、いろいろ応用できそうですね。

    > 別件ですがDelphiのFMXで開発を始めました。
    > 文字通りWindowsとiOSで同じコードで開発が可能ですね。
    > ただしプラットフォームにより異なり個所は個別に記述します。

    おお、FMX に行かれましたか!

    VCL とは使えるコンポーネントが違うので最初は少し戸惑いますが、基本的な文法は同じなので、使っていくうちに慣れてきますよね。

    ただ、Windows API を使うと他のプラットフォームでは動かなくなってしまうので、クロスプラットフォーム開発だと細かい部分で制約を感じることもありそうですね。

    > iOSでのシュミレーションでの確認は終わりましたが、実機での動作確認はこれからです。

    iOS 実機は私もまだ試したことがないのですが、Mac の実機で動かしたことはあります。

    最近の macOS だと、いわゆる野良アプリの実行に制限がかかるので、個人配布のアプリだと少し扱いづらい部分がありますよね。

    Apple の署名が必要になるあたりも、なかなかハードルが高い印象です。(私も詳しくはないのですが…)

    > 公開できましたら、別途報告させていただきます。

    iOS で動く Delphi 製アプリはあまり見かけないので、楽しみにしています!

    > 来週でComunityEditionのライセンスがきれますが更新する予定です。

    Delphi 13 の Community Edition がそろそろ来てくれると嬉しいのですが、まだまだ先ですかね…。

     |  Kuro  |  返信
  7. 動作確認ありがとうございます。

    画面上の文字コードのみで良いかなと考えてロジックを作成していましたが、Kuroさんの発言を読んで使う側が知りたい情報となるように以下のように変更しました。先ほど最新版をアップロードしました。

    ## Ver8.50 2026-03-27
    - プロパティ画面の内容で、文字コードの表示方法を変更しました。
    「文字コード」と「バイナリエディタ」で見た内容に変更しました。
    画面上の文字が「・」の場合
    「UTF16BE」: UTF16BE(0x30 0xFB)
    「UTF16LE」: UTF16LE(0xFB 0x30)
    「UTF8」 : UTF8(0xE3 0x83 0xBB)
    「UTF7」 : UTF7(0x2B 0x4D 0x50 0x73 0x2D)
    「Ansi」 : Ansi(0x81 0x45)

    AppleDeveloperには今回登録しました。
    証明書などはこれから登録して、取得すれば実機でのデバッグが可能になります。この辺りの最近の情報は少ないので調べながら行っています。
    動作確認用に最初は手元にあるMacBookPro2012(Memory16GB)を使用してみましたが遅くて使えませんでした。
    ストレスなので思い切ってMacBookPro2020M2(Memory24GB)を購入しました(快適ですね)。
    公開まで行ったら、ブログにFMX関係の開発情報を掲載します。

    よろしくお願いします。

     |  大石剛司  |  返信
  8. 開発お疲れ様です。さっそく最新版を試させていただきました。

    もはや簡易バイナリエディタとしての確認もできる、プロ向けの仕上がりですね。

    > 画面上の文字コードのみで良いかなと考えてロジックを作成していましたが、Kuroさんの発言を読んで使う側が知りたい情報となるように以下のように変更しました。先ほど最新版をアップロードしました。

    ご対応ありがとうございます。意図がとても分かりやすくなっていて、使う側としても安心感があります。

    UTF 系の場合はやや情報量が多くなるため、Mery の標準機能としては U+XXXX のみの表示にしようかと考えていますが、詳細な情報を確認したい場合には、MeryRowCol の「全部見える安心感」はとても良い方向性だと思います。

    Mery では、UTF 系以外の場合はエンコードに応じたバイト列を表示する方向で考えていますが、「シフト JIS」や「EUC」は問題ないものの、「JIS」がやっかいですね。

    「JIS」は、特殊なバイト列で ASCII モードと JIS 漢字モードを切り替える仕様のため、エスケープシーケンスを考慮しつつ、実際の文字に対応するバイト列を切り出す必要があり、なかなか手強いところです。

    > AppleDeveloperには今回登録しました。

    Apple Developer の登録も進められているとのことで、いよいよ実機デバッグですね。

    私も Mac 用のアプリを作ったことはあるのですが、Apple Developer Program の年会費がネックで、公開までは至っていません…。

    MacBook Pro の買い替えも含めて、本格的に進められていてすごいです!やはり新しい環境だと、開発体験も大きく変わりますよね。

    FMX 関連の情報は少ないので、ブログでの公開も楽しみにしています。

     |  Kuro  |  返信
  9. Kuroさんの発言を読んで変更しました。「JIS」の場合は現状のステータスバーの幅では表示が出来ないような長さになりますね。最新版をアップロードしました。

    ## Ver9.00 2026-03-28
    - プロパティ画面の内容で、文字コードを追加しました。
    「UTF16BE」から「EUCJP」以外の文字コードの場合は Others で表示されます。
    画面上の文字が「・」の場合
    「UTF16BE」: UTF16BE(0x30 0xFB)
    「UTF16LE」: UTF16LE(0xFB 0x30)
    「UTF8」 : UTF8(0xE3 0x83 0xBB)
    「UTF7」 : UTF7(0x2B 0x4D 0x50 0x73 0x2D)
    「SJIS」 : SJIS(0x81 0x45)
    「JIS」 : JIS(0x1B 0x24 0x42 0x21 0x26 0x1B 0x28 0x42)
    「EUCJP」 : EUCJP(0xA1 0xA6)
    「Others」 : Others(0x81 0x45)

    今回、Meryのバイナリー表示を初めて使ってみました。バイナリー画面のカーソル位置がエディタ上のカーソル位置に移動してくれるとありがたいですがサポート外だと思いますので、以下は読み流してもらって結構です。

    カーソル位置の移動までのロジックですが以下しか思いつきません。
    1:カーソル位置の前2行と後2行をバイナリに変換(同じ内容がある場合を避けるため)
    2:バイナリ配列で上記の位置を検索
    3:該当位置で該当行の位置を再度検索
    4:該当行の位置でカーソル位置を検索して移動

    もっと良いロジックはありそうでしょうか?

    既に公開しているバイナリ表示のアプリでは以下の操作を実装しています。
    1:検索文字を入力(大石)
    2:該当の文字コードのバイナリに変換(SJISでは(91 E5 90 CE))
    3:先頭から一致した場所に移動
    4:次検索で次の位置に移動

    よろしくお願いします。

     |  大石剛司  |  返信
  10. 開発お疲れ様です。

    > Kuroさんの発言を読んで変更しました。「JIS」の場合は現状のステータスバーの幅では表示が出来ないような長さになりますね。最新版をアップロードしました。

    最新版、さっそく試させていただきました。

    おっしゃるとおり、JIS はエスケープシーケンスが入る分、どうしても長くなってしまいますね。

    私も「JIS」の扱いには困っているところです。

    JIS の仕様としては、 の場合は

    0x1B 0x24 0x42 0x21 0x26 0x1B 0x28 0x42
    

    となりますが、この中で実際の文字データは 0x21 0x26 の部分だけなんですよね。

    • 先頭の 3 バイト 0x1B 0x24 0x42 は「漢字モードへ切り替え」
    • 真ん中の 2 バイトが「1 文字分のデータ」
    • 末尾の 3 バイト 0x1B 0x28 0x42 は「ASCII に戻る」

    たとえば ・・・ のように中黒が続く場合は、

    0x1B 0x24 0x42 0x21 0x26 0x21 0x26 0x21 0x26 0x1B 0x28 0x42
    

    のようになり、前後の切り替えはそれぞれ 1 回ずつしか現れません。

    そのため、1 文字ずつ切り出して JIS に変換すると、そのたびに前後にスイッチが付いてしまい、実際のバイナリとはズレてしまうのが悩ましいところです。

    ちなみに、秀丸エディタさんは JIS の場合でも SJIS のバイト列 0x81 0x45 を表示しているようです。

    一方で、EmEditor さんやサクラエディタさんは、エスケープ部分を除いた 0x21 0x26 のみを表示しているようですね。

    Mery としては、EmEditor さんやサクラエディタさんの方式に寄せるのが良さそうかな、と考えています。

    > 今回、Meryのバイナリー表示を初めて使ってみました。バイナリー画面のカーソル位置がエディタ上のカーソル位置に移動してくれるとありがたいですがサポート外だと思いますので、以下は読み流してもらって結構です。
    >
    > カーソル位置の移動までのロジックですが以下しか思いつきません。

    イメージとしては、Mery 側でカーソルを移動すると、バイナリ表示側のカーソルも連動して動く、という感じですよね。

    ご提案いただいたロジックはとても堅実で、「前後数行を含めて一意性を高める」という点も、衝突回避として理にかなっていると思います。

    ただ、JIS の場合に限っては前述のとおり、切り出す位置によってエスケープシーケンスの影響を受けるため、意図したバイト列と一致しないケースが出てくる可能性はあるかもしれません。

    > もっと良いロジックはありそうでしょうか?

    Mery から取得できるのは Delphi の string 型になるので、そこからバイナリ表示側で任意のエンコードに変換している前提になりますよね。

    そう考えると、少し力技にはなりますが、

    1. 先頭からカーソル位置までの文字列を取得
    2. バイナリ表示に合わせた文字コードでエンコードしてバイト数を数える
    3. そのバイト数をそのままカーソル位置として扱う

    ただし、エンコードロジックの違いや改行コードの扱いによっては、完全に一致しないケースもありそうです。

    また、毎回先頭からエンコードするかたちになるため、リアルタイムでカーソル移動に追従するには少し重そうですね。

    タイマーで一定時間停止後に同期する、あるいはショートカットキーで同期する、といった使い方であれば現実的かもしれません。

    なかなか悩ましいテーマですが、考えるのは楽しいですね。

     |  Kuro  |  返信
スポンサーリンク