第1水準、第2水準、第3水準、第4水準は、JIS 漢字における区分である。
更に言えば、JIS X 0208 と JIS X 0213 における区分である。JIS X 0208 は、1978年に制定され、その後何度か改正され、2000年には、JIS X 0213 が制定された。
JIS X 0213 で規定される漢字は、JIS X 0208 で規定される漢字をそのまま含み、それが、第1水準・第2水準漢字である。JIS X 0213 で新たに規定された漢字、つまり JIS X 0213 には含まれるが JIS X 0208 には含まれない漢字が第3水準・第4水準漢字である。第1から第4に進むにつれて、出現頻度の低い（難しい）漢字ということになっている。
ここで、JIS X 0212 は、この第1～第4水準の区分において蚊帳の外である。
シフトJIS では、第3水準・第4水準の漢字を扱えないのか？
例えば、「嚬」という字である。これを秀丸エディタでエンコードの種類を「日本語(Shift-JIS)」で保存しようとしても出来ない。
Microsoft IME で調べてみると、Unicode: U+56AC だが、Shift JIS の欄には該当するコード無しである。
秀丸エディタの［表示］->［文字コード表示］で見てみても、Unicode: U+56AC で Shift-JIS は該当するコード無しである。因みに、EUC: 0x8FB6E4 で Unicode(UTF-8): E5 9A AC である。
この「嚬」という字、『増補改訂 JIS 漢字字典』芝野耕司編著、日本規格協会発行（現在は絶版）で調べてみると、第3水準漢字であり、面区点は 1-15-29 、CJK は 56AC 、S-JIS は 885C である。『増補改訂 JIS 漢字字典』の「この字典の利用法」を読むと、S-JIS は「一般には、シフトJIS と呼ばれ」、CJK は「一般には、ユニコード(Unicode)と呼ばれる」と書いてある。
どういうことか？ CJK の方は、秀丸エディタや Microsoft IME と一致するが、シフトJIS に関しては、秀丸エディタや Microsoft IME では該当無しなのに、『増補改訂 JIS 漢字字典』では、コードがある。
この話は、改めて調べてみると、けっこう奥が深かったので、何回かに分けて書いていきたいと思う。
HTML5 と HTML Living Standard または W3C と WHATWG
XHTML から HTML5 で、大きめな思想的転換のあった HTML であるが、2019年5月28日の W3C と WHATWG の合意によって、これ以降は WHATWG の策定する HTML が唯一の現行版であることが決定した。
そして、この WHATWG の策定する HTML は、継続的にメンテナンスされて、Living Standard と呼ばれる。
現在、Web で「HTML5」と検索すると、「HTML5 廃止」という候補が出て来ることがあるが、WHATWG の HTML Living Standard を読んでみると、1.2章 Is this HTML5? では、"In short: Yes" と言っている（2023年1月11日版の情報）。
私は、W3C と WHATWG の歴史に特段詳しかった訳ではないので、この際、自分にとって必要な範囲で調べてみた。
W3C は、World Wide Web の生みの親 Tim Berners-Lee 本人が創立した団体である。HTML だけでなく、XML など Web に関する標準化を行っている。
HTML4 の標準化を行ったのも W3C だが、その後、W3C は、XHTML という HTML の XML 化を敢行する。
それに対して、Apple、Mozilla、Opera というベンダー達は、HTML は HTML として発展させる方向で、WHATWG を結成した。
更にその後、W3C は XHTML から方向転換して、HTML5 を勧告した。この辺りの経緯は、W3C 、WHATWG 双方の発表に微妙な相違があるように感じられる。W3C としては、WHATWG 側に妥協したという気持ちもあるだろうし、WHATWG としては、自分達の方向性に W3C が後から乗っかって来たという気持ちがあるのだろう。
一旦は、W3C と WHATWG の協調というか妥協の産物として成立した HTML5 だったが、両者の溝は埋まらず、遂に HTML の主導権は WHATWG に移ったというのが真相のようである。
だから、HTML Living Standard は、HTML5 から思想的転換があったというよりは、HTML5 の精神を推進して来たのはむしろ WHATWG であって、"Living Standard"という名称には、現場で使われている HTML が標準なのだという意味合いが込められているように思われる。
この流れ、どこかで見覚えがあるのだ。リレーショナルデータベースの世界である。
リレーショナルデータベースを発明した Edgar F. Codd と共にリレーショナル理論の普及に努めた Chris Date は、SQL が現場の声を取り入れて肥大化し、もはや、リレーショナルモデルとは似ても似つかぬものになって行くのを嘆き続けた。ベンダーとしては、純粋なリレーショナルモデルであることが目的なのではなく、ユーザーの求める機能を提供するのが仕事なのだという言い分もあるだろうが、Date や Berners-Lee のような「思想強め」な技術者も私は好きである。
英語版 Wikipedia の"Null(SQL)"の項目の盛り上がりを見ても、「純粋なリレーショナルデータベースの実装を」というムーブメントが、多数でないにせよ熱心な信奉者に支えられていることが垣間見える。
さて、HTML はどこへ向かうのか？ その昔、MathML も SVG もレンダリングできる Amaya というブラウザもあったし（現在は開発はストップしている）、XML を XSL-FO で変換するApache FOP というプロジェクトもある（こちらは、開発が継続しているらしい）。
食塩水問題
食塩水問題とは、次のようなものである。
例題(1) 5％の食塩水600g に10％の食塩水を混ぜて、7％の食塩水を作りたい。10％の食塩水を何g 混ぜればよいか。
このような問題は、いまだに中学入試の算数や中学校に入ってからの数学で出題されているらしいのだが、ここでは、問題の解き方ではなくて、「何々％の食塩水」（上の例では「5％の食塩水」や「10％の食塩水」、「7％の食塩水」）とは何かについて検証してみたい。
出題者の意図としては、「5％の食塩水600g」と言えば、(水＋食塩)600g で、600g の5％すなわち30g が食塩、残りの570g が水である。
そんなこと決まってるじゃないか？ そうだろうか？
次のような問題を作ってみた。
例題(2) 水に20％の食塩水を混ぜて、食塩水600g を作った。この食塩水の塩分濃度は3％だということがわかったとする。元の食塩水の塩分濃度は何％か。
この場合、「20％の食塩水」は、水に対する食塩水の割合と読めないだろうか？ もし、元の水の20％の質量（小学生向けだったら重さでもよい）の食塩水を水と混ぜるのであれば、水500g に食塩水100g で合計600g の食塩水を作る。この食塩水に含まれている食塩は、600×0.03で18g である。この食塩は、元の100g の食塩水に含まれていたものであるから、18/100で塩分濃度は18％である。
だから、「10％の食塩水を混ぜて、云々…」のような問題を前にしてフリーズしているように見える子供がいた場合、この子は「文章題が苦手だ」とか「割合の計算が出来ない」とか「国語力がない」とか決めつけないでほしいのである。「何々％の食塩水」とは何の何に対する割合を言っているのか、という真っ当な疑問を抱いているかもしれないからだ。私から見れば、国語力がないのは出題者のほうである。
例題(3) 消費税8％の商品540円と消費税10％の商品330円を買って、合計870円支払った。この内、消費税はいくらになるか。
答えは、70円である。消費税の場合、税抜き価格に税率を掛けたものが税金で、それに税抜き価格を足したものが、支払総額だからだ。
食塩水問題の出題者は、一部の生徒が（食塩／水）で濃度を計算するという間違いをすることを想定している（嫌な言い方をすれば、期待している）。しかし、消費税の場合は（税金／税込み価格）ではなくて（税金／税抜き価格）が税率で、食塩水の場合は、（食塩／（水＋食塩））が濃度だというのは、知識の問題であって、算数や数学の問題ではない。
例題(4) アルコール度数30の泡盛50ml を水150ml で割った。出来上がった泡盛の水割りのアルコール度数はいくらか。
この問題には、いくつかの論点がある。先ず、アルコール飲料のアルコール度数は、体積で計ったアルコールの割合なんだそうである。よって、アルコール度数30の泡盛50ml に含まれるアルコールは、0.3×50で15ml。そして、泡盛50ml と水150ml を混ぜた時の体積は、正確には50ml と150ml を足した200ml にはならない。アルコールを水に溶かした場合、元のアルコールと水の体積を足したものよりも少し小さくなる。どれだけ小さくなるかの情報が与えられないと、この問題は解けないので、このような問題が算数や数学の問題として出題されることはないだろう。
翻って、出題者は答えが出るように問題を作成しているはずだということを鑑みれば、例題(1)のような問題では、食塩水の単位はグラム[g]で出題されているのだし、食塩を水に溶かした時の体積も食塩の体積と水の体積を足したものにならないのだから、食塩水の濃度は質量（小学生だったら重さ）で計算するのだなということが推察できる。
しかし、そのような訓練を子供にさせることは、出題者の意図を忖度する小賢しい受験生 → この教授にはこういうレポートを書けば単位が来る＆就活ではこういうキャラを演じれば内定がもらえる、という傾向と対策で世渡りする大学生 → 課長「みんな遅くまで頑張ってるんだよ」、新人〈サービス残業しろってことだな〉と自主的に会社に服従してしまう典型的な日本のサラリーマン、を養成しているに等しいと私は思う。
いずれにしても、以上の例から、「何々％の食塩水」の意味するところは自明でないことが納得できたと思う。私の提言は、以下の通りである。
例題(1)を次のように書きかえる。
例題(1-改) 塩分濃度5％の食塩水溶液600g に塩分濃度10％の食塩水溶液を混ぜて、塩分濃度7％の食塩水溶液を作りたい。塩分濃度10％の食塩水溶液を何g 混ぜればよいか。（ただし、塩分濃度とは、食塩水溶液における食塩の割合を質量で計算したものである。）
それに、割合の計算が出来るかを試したいのであれば、食塩水である必要は全然ない。次のような問題は、どうだろうか？
例題(5) 昨年度の本校の入学試験の出願者は1000人、受験者は900人、合格者は360人、入学者は240人だった。受験率（受験者／出願者）、合格倍率（受験者／合格者）、入学辞退率（（合格者－入学者）／合格者）を求めよ。
InDesign と XML（9）－名前空間を使ったスタイルの適用－
InDesign と XML の9回目。
これは、"Adobe InDesign CS3 and XML: A Technical Reference"という資料に書いてあった方法である。
XML では、要素や属性に名前空間を利用することが出来る。具体的には、名前空間を使いたい要素や属性に名前空間接頭辞（プレフィックス）を付ける。名前空間は、XML 文書の中で宣言しておく。
Adobe が用意している名前空間のうち、ここでは、aid（段落スタイルと文字スタイルのため）について説明する。
XML 文書の中で、スタイルを適用したい箇所に、それぞれ以下の属性を記述する。
aid:pstyle（段落スタイル）
aid:cstyle（文字スタイル）
そして、属性値にスタイル名を指定する。
例えば、
<myParagraph aid:pstyle="mystyle">ここに段落</myParagraph>
名前空間の有効範囲は、名前空間を宣言した要素およびその下位の要素なので、文書全体で名前空間を利用したい場合は、ルート要素で宣言すればよい。具体的には、次のように。
<myRoot xmlns:aid="http://ns.adobe.com/AdobeInDesign/4.0/">
スタイルを適用したくない所では、属性を記述しなければよいだけである。
InDesign と XML（8）－「タグをスタイルにマップ」と「スタイルをタグにマップ」－
InDesign と XML の8回目。
タグパネルメニューまたは構造ウィンドウメニューには、「タグをスタイルにマップ」と「スタイルをタグにマップ」の両方が存在する。似ているようだが、この二つには違いがある。
「タグをスタイルにマップ」は、既に XML のタグ付けがされたテキストに対して、InDesign の段落スタイルや文字スタイルを対応させるものである。段落スタイルや文字スタイルは、InDesign で作っておく。そして、タグ付けされた XML 文書を InDesign に読み込む。その上で、タグパネルメニューまたは構造ウィンドウメニューから「タグをスタイルにマップ」を開き、タグに対応させたいスタイルを選ぶと、 InDesign 上で、スタイルが適用される。
「スタイルをタグにマップ」は、タグ付けされていないがスタイルの適用されている InDesign 上のテキストに XML のタグを付与するものである。実際、「スタイルをタグにマップ」した InDesign のテキストを XML で書き出してみると、対応させたタグが付いているのが確認できる。「スタイルをタグにマップ」で注意しなければならないのは、既にタグ付けされてスタイルも適用されているテキストに新たに「スタイルをタグにマップ」を行うと、タグが新たに適用される、つまり XML 文書の側が塗り替えられるということである。
XHTML と HTML5－空要素と空白の扱い－
XHTML と HTML5 の違いは、端的に言えば XHTML は XML なので XML の文法に従わなければならないということである。細かく見ていけばいろいろあるが、今回の記事では、重要だが忘れがちな点に絞って述べたいと思う。
空要素のタグ
XML の場合、開始タグと終了タグの間に何もない要素は、終了タグを省略して、開始タグの末尾に「/」を入れて書くことが出来る。よって、XHTML では、<br></br> も <br/> も文法的に正しい。
HTML5 の場合、Void に分類される要素はコンテンツが存在せず、終了タグも存在しない。ただし、開始タグの末尾に「/」を入れる書き方も可。br 要素は Void に分類されるので、<br> または <br/> と書くのが正しく、<br></br> は不可。
空白、改行文字の扱い
先ず、テキストコンテンツの中の空白や改行文字については、ブラウザでの表示を確認した限りでは、改行文字は半角スペース相当、半角スペースは、2個以上続けても1個相当というのは、XHTML と HTML5 で共通していた。もちろん、「<pre></pre>」などを使って表示をコントロールすることは出来る。
そして、テキストコンテンツの外の空白や改行文字、例えば<p>タグや<div>タグをインデントした場合についても、ブラウザでの表示を確認した限りでは、XHTML と HTML5 で違いはなかった。
注意しなければならないのは、XHTML は XML であるので、アプリケーションに渡された空白や改行文字の扱いは、アプリケーション次第だということである。具体的には、XHTML 文書を （XML として）InDesign に読み込んだ時、テキストコンテンツの中の空白や改行文字だけでなく、タグとタグの間の改行などで、HTML に慣れていると「意外」だと思う挙動をすることがある。
