sikaku

フルカスタムホームページ　ナノにて、通常だと利用不可能な文字についての見解と、対処方法のまとめです。

サーバーサイド言語にまるで詳しくないド素人の書いた記事なので信頼性に欠けます。　新しい発見があった際や誤りは都度追加,修正していく予定です。

各「対処方法」はこういう認識で組んでるよ(不備があった場合、こういう理由だよ)という参考程度にしてください。　また、「それは違うのでは？」という訂正意見もお待ちしています。

ページ表示後に「置き換え返す」

• 

  ナノで利用不可能な文字をJavaScriptで表示させる

内容

文字から置き換えられた<img>要素が参照する画像URLに、元の文字の文字番号が残っている部分があるので、それを元にJavaScriptで置き換え返す

利点

• とにかく楽

欠点

• ?に置き換わる文字は対応不能
• ナノ提供のガラケー絵文字が表示できなくなる
• JavaScript非実行環境だとリンク切れの画像のまま
• 置き換え返す前の画像(リンク切れ含む)参照先のドメイン(img.mobilerz.net)のSSL証明書が結構な頻度で期限切れになる(JavaScript実行云々関係なしに閲覧時にブラウザから警告が出る可能性有り)

「置き換え対象外の記述」をする

• 

  ナノでの数値文字参照の利用

内容

予めナノ側に余計な置き換えをされないような数値文字参照記述で、利用不可能な文字を代替しておく

利点

• JavaScript版利用での欠点を全てカバーできる

欠点

• 手間(下記ツールでうまく補ってください)

ツール

※これらを使用して変換した数値文字参照記述を表示するのにJavaScriptは不要ですが、ツール自体にはJavaScriptを利用しています。

• 変換ツール

• 

  持ち帰り

そもそも何故使用できないのか

• sample

ナノに書き込まれた(送信した)文字は上記４パターンの変化を遂げて出力されます。

グループA,Dは普通に表示でき、B,Cが意図した表示にならない、本記事の本題対象です。

何故こうなるのかを先んじて雑に述べると下記になります。

B

ユーザー側のShift_JIS文字範囲がナノのそれより広く、ユーザー側がエンコードして送った文字を正しく解釈できなかった

C

ナノが売りにしていた、キャリア毎に仕様がバラバラだったガラケー絵文字を差異なく(画像として)表示できるサービスの余波

ユーザー側の処理

ナノ無関係に、我々(ユーザー)がwebページ上でフォーム送信をした際の処理についてです。

OS,ブラウザ等、利用環境により処理内容に差異がある可能性があります。　こんな記事書いておいて申し訳ないのですが、極力調べましたが情報が得られませんでした。

大抵の環境ではおそらく下記が当てはまる、筈です。

総括

• フォーム内容をShift_JISでエンコードした上でサーバーに送信
• その際、Shift_JIS範外の文字は数値文字参照記述へ置き換えた上でエンコードしている

Shift_JISでエンコード

大抵のブラウザでは、HTML上のフォームを送信した際、フォームデータ(入力内容等)を指定された文字コードでエンコードした上で送信しています。

これはナノの処理云々は全く無関係の、ユーザー側で行われる処理です。

ナノの編集画面での『保存する』等によるフォーム送信も例外ではなく、テキストエリアの内容は指定文字コードでエンコードされて送信されます。

form要素自体に個別で指示がなければ、ページ自体の文字コードに倣う為、ナノ(出力されるHTMLファイルは全てShift_JISでエンコードされている)でのフォーム送信はShift_JISでエンコードされた上で行われます。

数値文字参照へ置き換え

Shift_JISですが率直に言って対応文字範囲は狭いです。
範囲外の文字は当然Shift_JIS上での文字番号が参照できません。
そうした文字は数値文字参照記述に置き換えた上でエンコードされます。

例

ナノ側処理の推測

以下ナノのサーバー側処理について推測です。　結局ユーザーにはブラックボックスでしかない、かつ総当たり的な検証をした訳ではないので信頼性には欠けますがおそらく当たらずも遠からずではないかな……と。

くどくなるので省きますが以下の文は前置で「おそらく」とか「多分」が付くと思って読んでください。

総括

• 特定パターンの記述に当てはまる数値文字参照を絵文字用記述に置き換えている
• Shift_JISエンコードされているが「JIS X 0208+NEC特殊記号」範囲外の文字を?に置き換えている

特定の数値文字参照を絵文字用記述に

ナノに絵文字用HTMLに置き換えられるのは[V:数値]の様な絵文字用独自タグだけでなく、下記条件をそれぞれ満たす数値文字参照記述も対象になるようです。

パターン１

• &#10進数文字番号;
• 文字番号部分が4桁もしくは5桁

パターン２

• &#x16進数文字番号;
• xが小文字
• 文字番号部分が4桁
• 文字番号部分が数字もしくは大文字アルファベット

正規表現で書くなら&#\d{4,5};&#x[\dA-F]{4};とかですかね。

前述、「ユーザー側の処理」でShift_JIS範外の文字は数値文字参照に置き換えた上でエンコードしている、と解説しました。

その上で数値文字参照が上記条件に合致した場合、絵文字用記述に置き換えられるので結果的に利用不可能な文字が出るのだろうなあと考えています。

エンコードされている特定範囲外の文字を?に

一口にShift_JISと言っても「〇〇拡張を含む」や「どこそこが制定〜」等、範囲が異なる場合があります。

ナノ(サーバー側)が参照できるShift_JISはおそらく「JIS X 0208+NEC特殊記号」です。

前述、「ユーザー側の処理」にて、Shift_JISにエンコードした上で送信していると説明しましたが、問題が起こりうるのはユーザー側で参照できるShift_JISの範囲がナノ側より広い場合です。

Shift_JISエンコードされ送られてきた文字をナノ側がデコードする際、参照できる文字範囲は「JIS X 0208+NEC特殊記号」です。　ユーザー側で参照できたからとエンコードされた上で送信された前述範囲外の文字を、ナノは正しく解釈できません。

文字番号が参照できない場合?に置き換えるサーバーサイド言語が結構あるようなので、それが原因ではないでしょうか。

全角チルダ、波ダッシュについて

• Noto Sans JP Gothic A1

見た目がほぼ同じ(表示フォントに依る)で全く異なる文字の全角チルダ、波ダッシュ(波線)があります。

「以前は問題なかった"〜"が表示できなくなった」という方は、キーボードアプリなりOSなりのアップデートで、以前と異なる記号を入力しているのではないでしょうか。

一例として、これを書いている人間の使っているスマートフォンのキーボードアプリは「チルダ」「波ダッシュ」「から」「ー」等々の、変換候補に波ダッシュしか出してくれません。
「チルダ」に至っては〜(選択すると波ダッシュが出力される)が変換候補に出ます。　わざわざ記載してくれる[全]チルダは何。

双方記号の意味が違うので確認の上で、まあ全角チルダで良いなら全角チルダを優先採用しておくと楽でいいのではないでしょうか。　表の名称項をwikipediaへのリンクにしています。

リゼ、エムペ、エムブロ対応

ファインシードがガラケー向けに開始したサービスは文字コードの扱い及びガラケー絵文字関係の仕様が概ね同一なので、だいたい同じ方法で対策できるかと。

差分を下記に記しておきます。

「置き換え対象外の記述」

ナノの独自仕様(推定)の「♯が独自タグ」というのを利用しているので、他サービスで代替手段が無い場合再編集時ものすごくダルいことになると思います。

「置き換え返す」

リゼのみJavaScriptソース中で下記変更が必要です。
mobilerz.net/img/→//lyze.jp/img/material/

サポート対象外

これを書いている人間が他サービスの仕様に全く詳しくない(「さっき3秒触った」レベル)のと、これから仕様把握する事に利を感じられないので当サイトとしてはサポート対象外にさせていただきます。

各あれそれの再配布、説明文引用も許可しているので「リゼならこうした方が便利」的な事を思いつく詳しい人は同サービス利用者さんにシェアしてあげてください。

この記事について補足

2021-12-14に改題、及び記事内容の大幅な再編を行っています。

以前当記事では対処方法として「jQueryを用いてページ表示後に置き換え返す」ソースコードと、利用不可能な文字についての見解を述べていました。

対処方法について、本件の為だけにjQuery本体を読み込ませるのも無駄が多い、かつ処理速度も高速化が見込めるJavaScriptのみでほぼ同内容の処理をさせる方法を掲載後、使用非推奨として扱っていました。

いつまでも使用非推奨のソースコードを掲載し続けるのも考えものであった点、利用不可能な文字についての見解も掲載当時より詳細な説明が可能である点を踏まえ、記事内容を大幅に書き直しています。