ClockRoom

宿敵 0x5C | 運営ノート

宿敵 0x5C

長年、当サイトにおいて円記号はなにも考えずに文字コード「0x5C」を使用しておりました。 Windowsに限ればなんら気になりませんが、Macだとバックスラッシュが表示されます。 そもそも、0x5Cは円記号ではなくバックスラッシュなので、Macのが正しい表示です。 他のOSや外国語のWindowsでも同様でしょう。

最初は特に問題視しておりませんでしたが、Macへ以降後、徐々に読みづらくなり、半年前、全ページの円記号を「¥」へ置換。 特に無問題でしたが、先日、この期に及んで¥と掲示板の相性がよろしくないことが発覚(汗)

掲示板の書き込み処理は¥を「0xA5」へ変換します。 Shift_JISへUnicodeのルールを適用する時点でダメダメなのは自明ですがライブラリの仕業なので・・・

それよりも問題なのは読み込み処理。 0xA5を¥へ変換すべきところ、なにも行なわれず、半角中点へ文字化け。 やはりライブラリの仕業なので・・・

応急処置として読み込み処理へ上記の変換を追加。 これでしばらくは大丈夫と思いつつ「禁則事項」と書き込んだところ早速の文字化け(ノД`) 「則」の2バイト目が0xA5につき誤変換。 いきなり役立たずかよ。 このように、基本中の基本ですが、0x5Cはプログラミングの宿敵なのです。

さてどうする。 大正解は「Shift_JISを使用しない」ですが、今さらすぎるのでそれは考えない。 0x00~0x3Fの1バイト文字は2バイト文字と衝突しないため、代表的な4文字「<>&"」の変換については問題なし。 ということは、やはり、選択すべきは、私の好きな言葉、かつ、最も得意な解決方法 ────

運用回避(爆)

実体参照が必要な文字は使用しない!! これマジ最強。 さておき、書き込み処理における「text/plain」への変換は必要なのか。 一応、汎用性重視の変換ですが、実際の使途は「text/html」な出力のみ。 割り切れば変換不要。 データベースへの移行前に決着すべき最重要課題・・・

コメント

名前
内容
送信

※URLを含むコメントはできません。