Muse の Unicode 対応について     

この記事の記述は、わかりやすさを正確さより優先している。より正確な記述はUnicode のウィキペディア記事、Unicode コンソーシアムの規格ページ (英語)、ISO/IEC 10646 のウィキペディア記事、ISO/IEC 10646 規格書 (英語 PDF; ZIP) など*1を参照されたい。

Muse は、V6.60 で Unicode(ユニコード) に対応した。その意義は、テキスト領域に表示できる文字が大幅に増えたことにある。それより前のバージョンは、Muse データの文字コードがシフト JIS であることを前提としていた。シフト JIS の文字数は 1 万文字強であり、日本での使用を前提とした文字コードのため日本語の文字や日本での使用頻度が高い文字に偏っている。一方 Unicode はその約 10 倍 (ただし、それらの文字すべてを表せるシステムはなかなかない) の文字を持ち、世界中の文字を「単一の(Uni)」コード体系に収めることを目標に規定されている。

Muse で Unicode を使えば、例として以下のようなテキスト表示ができる。

ソース: *HEAD "⎰◕ᴥ◕⎱ 子犬のワルツ ⌒ ◕ᴥ◠⎱"

ソース: *MARK "愛❤のメモリー♡♥"

ソース: *TEXT "☂ あめ あめ ふれ ふれ かあさん が ♩♪"

ソース: *STOP "Skryabin (ﾾ෴ﾾ) Prométhée―Le poème de feu"

なお、これらの表示は、Windows 7 上で「メイリオ」フォント (通常) を指定して得た。Windows の他のバージョンや、他のフォントでは一部の文字が上の通りに表示されないことがある。

また、Muse データに以下のようなコメントを書くこともできる。

◂ ▸ で各楽章の頭出し

Ⓐ

;©2014

これらも、フォント、Windows のバージョン、あるいはテキストエディタによって正しく表示されないことがある。

Unicode には、歴史的な経緯から数種類の文字コードがあるが、V6.60 以降の Muse は、そのうち UTF-8 と UTF-16 で書かれた Muse データを扱うことができる。シフト JIS のデータもそれまで通り扱える。どの文字コードで書かれているかを Muse が判断するために、Unicode の Muse データには BOM を付ける必要がある。

(注) V7.82 にて、文字コードによらず、先頭に文字「¢」(全角セント通貨記号)を置けば BOM は不要になった。

Unicode の Muse ファイルを作るには†

主要なエディタのあまり古くないバージョンなら、編集するときに BOM 付 Unicode のどれかを指定したり、シフト JIS を読込んで BOM 付 Unicode のどれかで書込むことが可能だろう。→手順

Unicode は、シフト JIS に比べて文字が増えた分、同じテキストを表現するデータサイズが一般に大きくなる。大抵の Muse データのように半角英数字が大半を占める場合、Unicode の中では UTF-8 のデータサイズが最も小さくなる。

あなたのパソコンでキーボードから入力できない文字は、Unicode 一覧のウィキペディア記事などから探してコピー & ペーストで入力することができる。このとき、ブラウザ上やエディタ上では正しく表示されない文字でも、目的の文字のコードはファイルに書き込まれるので、適当なフォントを選べば Muse のテキストエリアには正しく表示される場合がある。逆に、同じ名前のフォントで表示しても Windows 7 では正しく表示されるが Windows XP では正しく表示されない場合もある。

初期設定ファイル (muse.ini) と履歴ファイル (muse.log) について†

Unicode 対応で Muse は内部処理の文字コードを全面的に UTF-16 に置換えた。これに伴って V6.60 以降の Muse は初期設定ファイル (muse.ini) と履歴ファイル (muse.log) は UTF-16 (BOM 付リトルエンディアン) で生成するようになった。muse.exe と同一のフォルダにあるそれらのファイルが UTF-16 (BOM 付リトルエンディアン) 以外の場合、読込みも上書きもせず、別名で生成もしない。従ってこの場合、設定情報や履歴情報は起動時に反映せず、終了時にも保存されない。

(注) V7.04 にて、シフト JIS や UTF-8(BOM付) の muse.ini および muse.log の読込みが可能となった。ただし、Muse 終了時の保存は UTF-16 で行われる。

そもそも文字コードとは?†

文字のコンピュータ内での表現。コンピュータ内ではすべてが数で表現されていて、文字も例外ではない。しかし、漢字や記号などには決まった順序があるわけではなく、文字と数字の間にはいろいろな対応関係がある。この対応関係の決め事のことを文字コードという。

たとえば、シフト JIS という文字コードでは ‘A’ という文字は 65 (10 進、以下同じ) に、‘あ’ は 130 160 に対応すると決められている。UTF-16 (リトルエンディアン) では、‘A’ は 65 0、‘あ’ は 66 48 である。テキストファイルは、0 から 255 までの 256 (= 2⁸) の数 (バイト) を並べて作るので、257 個以上の文字をもつ文字コードでは、1 つの文字に 2 バイト以上の数の並びを割当てる必要がある。

言うまでもなく、文字コードを間違えて、たとえばシフト JIS のファイルを UTF-16 と思って読んだりすれば、大抵まともには読めず、いわゆる文字化けが起きる。

UTF-8、UTF-16 の違いは?†

文字の集合は Unicode で決まっているので、UTF-8 でも UTF-16 でも、ほかの Unicode の文字コードでも変わりはない。違いは、UTF-8 が 1 バイトを単位として文字コードを構成しているのに対して、UTF-16 は 2 バイト (2¹⁶) を単位としていることである。UTF-8 は、0 から 127 までの英文文字はシフト JIS とほとんど同じであるが、和文文字は大抵 3 バイトである。シフト JIS は半角カタカナなら 1 バイト、それ以外の和文文字も 2 バイトで表現する。

UTF-16 は、単位としている 2 バイトの並びの順序 (「バイト順序」) を 2 通り取ることができる。たとえば、‘A’ を 65 0 と表すとしてもよいし、0 65 と表すとしてもよいが、後者の場合 ‘あ’ は 66 48 ではなく 48 66 にしなければならない。前者のバイト順序を「リトルエンディアン」、後者のを「ビッグエンディアン」*2と呼ぶ。

文字コードを間違えればまともに読めないということは、バイト順序についても変わりはない。同じ UTF-16 でも、リトルエンディアンのファイルをビッグエンディアン (あるいはその逆) と思って読んだりすれば、やはりまともには読めない。リトルエンディアンで ‘A’ を表す 65 0 は、ビッグエンディアンと思って読むと ‘攀’ という、似ても似つかない文字になってしまう。

BOM とは?†

BOM*3 はファイルの先頭でそのファイルの文字コードを示す 1 文字である。Unicode に対応した主要なエディタは、文字コードに応じて BOM を自動的に挿入 (そのための設定が必要なものもある) し、通常は画面に表示しない。

Unicode のどの文字コードでも、BOM の先頭のバイトはシフト JIS で先頭に現れることがないため、Unicode のファイルの先頭に BOM を置いておけば、そこを見るだけでシフト JIS と区別できる。さらに Unicode では BOM のバイト順を逆にした文字を定義しないことによって、BOM だけでバイト順序も区別できるようにしている。Muse もデータの文字コードの判別に BOM を利用している (このため、Unicode の Muse データには BOM が必要なのである)。

BOM無しUTF-8のMuseデータを作成する方法†

Muse(V7.82)より、Museデータの１行目の１カラム目に全角のセント「¢」を書いておくと、 BOM無しのUTF-8でも正常にロードできる機構が付いた。

「¢」は全角文字なので、Muse演奏時にはコメント文字として扱われる。 なお、S-JISやUTF-16のMuseデータ冒頭に「¢」が存在してもなんら問題はないため、 冒頭に「¢」があれば、最も広範囲なファイルコード種に対応できるMuseデータとなる。

Google日本語入力を使用の場合†

Google日本語入力では「せんと」からの読み変換では半角セント「¢」のみが用意されており、全角セント「¢」に変換が出来ない（MS-IMEであれば出来る）
「せんと」の読みで全角セント「¢」を辞書登録をしておくなどの対処が必要。