![[PukiWiki]](/MuseWiki/wiki_baner.png "[PukiWiki]")
この記事の記述は、わかりやすさを正確さより優先している。より正確な記述はUnicode のウィキペディア記事、Unicode コンソーシアムの規格ページ (英語)、ISO/IEC 10646 のウィキペディア記事、ISO/IEC 10646 規格書 (英語 PDF; ZIP) など*1を参照されたい。
Muse は、V6.60 で
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 を付ける必要がある。
主要なエディタのあまり古くないバージョンなら、編集するときに BOM 付 Unicode のどれかを指定したり、シフト JIS を読込んで BOM 付 Unicode のどれかで書込むことが可能だろう。→手順
Unicode は、シフト JIS に比べて文字が増えた分、同じテキストを表現するデータサイズが一般に大きくなる。大抵の Muse データのように半角英数字が大半を占める場合、Unicode の中では UTF-8 のデータサイズが最も小さくなる。
あなたのパソコンでキーボードから入力できない文字は、Unicode 一覧のウィキペディア記事などから探してコピー & ペーストで入力することができる。このとき、ブラウザ上やエディタ上では正しく表示されない文字でも、目的の文字のコードはファイルに書き込まれるので、適当なフォントを選べば Muse のテキストエリアには正しく表示される場合がある。逆に、同じ名前のフォントで表示しても Windows 7 では正しく表示されるが Windows XP では正しく表示されない場合もある。
Unicode 対応で Muse は内部処理の文字コードを全面的に UTF-16 に置換えた。これに伴って V6.60 以降の Muse は初期設定ファイル (muse.ini) と履歴ファイル (muse.log) は UTF-16 (BOM 付リトルエンディアン) で生成するようになった。muse.exe と同一のフォルダにあるそれらのファイルが UTF-16 (BOM 付リトルエンディアン) 以外の場合、読込みも上書きもせず、別名で生成もしない。従ってこの場合、設定情報や履歴情報は起動時に反映せず、終了時にも保存されない。
文字のコンピュータ内での表現。コンピュータ内ではすべてが数で表現されていて、文字も例外ではない。しかし、漢字や記号などには決まった順序があるわけではなく、文字と数字の間にはいろいろな対応関係がある。この対応関係の決め事のことを文字コードという。
たとえば、シフト JIS という文字コードでは ‘A’ という文字は 65 (10 進、以下同じ) に、‘あ’ は 130 160 に対応すると決められている。UTF-16 (リトルエンディアン) では、‘A’ は 65 0、‘あ’ は 66 48 である。テキストファイルは、0 から 255 までの 256 (= 2⁸) の数 (バイト) を並べて作るので、257 個以上の文字をもつ文字コードでは、1 つの文字に 2 バイト以上の数の並びを割当てる必要がある。
言うまでもなく、文字コードを間違えて、たとえばシフト JIS のファイルを 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*3 はファイルの先頭でそのファイルの文字コードを示す 1 文字である。Unicode に対応した主要なエディタは、文字コードに応じて BOM を自動的に挿入 (そのための設定が必要なものもある) し、通常は画面に表示しない。
Unicode のどの文字コードでも、BOM の先頭のバイトはシフト JIS で先頭に現れることがないため、Unicode のファイルの先頭に BOM を置いておけば、そこを見るだけでシフト JIS と区別できる。さらに Unicode では BOM のバイト順を逆にした文字を定義しないことによって、BOM だけでバイト順序も区別できるようにしている。Muse もデータの文字コードの判別に BOM を利用している (このため、Unicode の Muse データには BOM が必要なのである)。
