先日から1台のPCでGoogle Chromeを使ってサイトの表示をすると、一部のサイトで文字化けをするようになった。
リモートで入って見せて貰うと、化けているのは数字やアルファベットの半角の文字だけに見えた（全角の数字やアルファベットは問題無く表示される）。
最初はエンコードの問題と思い変更してみたが効果無し（というか自動判別以外にすると全てが化けて読めなくなる）。
部下がいろいろ弄っている内に気付いたのが、”化けた部分をコピーしてメモ帳に貼りつけると正しく表示される”ということ。
ということは、化けているのはフォントのせいということになるので、フォントの設定を見ると標準フォントが”Marlett”になっていた。
これを”Meiryo”（メイリオ）に変更したところ全て正しく表示されるようになった。
何故”Marlett”になっていたかは不明だけど、とりあえずは良かったよ。
More from: 文字化け
←クリックしてくれると嬉しいです。
apacheでシンボリックリンクが見えない場合の対処
仕事場のサーバーの一部が動かなくなったorz。
古い仮想化基盤のサーバーがHDDの不調のためかまともに動作しなくなってしまい、その上で動かしていた複数台のサーバーがどうにも動かなくなってしまった。
仕方が無いので新しい仮想化基盤に用意してあった同機能のサーバーに機能を移してサービスを再開したが、細かいトラブルがいくつか発生。
その中の一つにhttpdアクセスが出来ないというのがあった。
元々、ごく一部のユーザー向けにいくつかのディレクトリをブラウザで参照可能にするためにhttpdサーバー（apache）を動作させていたんだけど、ユーザーの指摘でそのことに気付くという体たらく（汗）。
最初に気付いたユーザー向けのサービスはhttd.confを弄ってDocmentRootを変更するだけで参照可能になったが、別のユーザーから指摘されたディレクトリにアクセスすると403エラー（Forbidden）で参照できない。
ファイルやディレクトリのパーミッションを見ても644（ディレクトリは755）で参照可能なはずなんだけど、何故か403になる。
問題のディレクトリはシンボリックリンクなので、リンク先のディレクトリも確認したがパーミッションの設定に問題は無い。
そこで調べてみると、apacheはデフォルトでシンボリックリンクの参照が可能なのは所有者ユーザーのみで他のユーザーがアクセスすると403になるらしい。
これを回避するにはhttpd.confで
Options Indexes SymLinksIfOwnerMatch
となっているのを
Options Indexes FollowSymLinks
に変更すると良いとのことだったので、問題のディレクトリのその部分を修正してhttpdをリスタートすると無事に参照可能になった。
ところが、問題はこれだけではなく、ディレクトリ名やファイル名に日本語（2byteコード）が使われており、そのままでは文字化けして読めない。
これは旧サーバーではEUCだったのが新サーバーではutf-8が標準のためデフォルトの設定ではヘッダーが、
Content-Type: text/html; charset=utf-8
となりブラウザ側はEUCの文字コードをutf-8として解釈しようとしたため。
これを直すにはhttpd.confの
IndexOptions charset=utf-8
を
IndexOptions charset=euc_JP
とすることで無事に日本語の文字が表示されるようになった。
←クリックしてくれると嬉しいです。
エクセルのPDF出力で日本語文字が表示されない
最近Windows11のPCに入れ替えたユーザーから「PCを替えてからエクセルでPDF出力をすると文字化けして読めない」と連絡が来た。
そのPDFファイルを見せて貰ったら本来漢字や仮名が表示されるところが悉く□になっている（ご丁寧に小文字”ゅ（等）”は小さい□になっていた）。
半角の数字やアルファベットは問題無く表示されているので、これは日本語フォントの埋め込みに失敗しているのが原因だろうという見当はついたが対処方法が判らない。
PCに入れ替えと同時にエクセル（を含むマイクロソフトオフィス）のバージョンも2016から2021に変わっているのでその影響もあるのかと思い調べてみた。
いくつか見つけた情報に中にはフォントが特定のフォントの場合に文字化けするというのもあって、ユーザーのPCにあったエクセルのファイルを見ると確かにそのフォントが使われていた。
そこでフォントを別なもの（MSPゴシック等）に替えてみたものの改善しない。
他にもファイルの保存ダイヤログのツールの中のWEBオプションに”フォント”タブと言うのがあるので、そこを見ると何故か”多言語/Unicode/その他の言語”になっていたので、ここを”日本語”に変更したら無事にPDFファイルに正しいフォントが埋め込まれて表示されるようになった。
これで一件落着かと思ったが、数時間後にまた同じユーザーから直っていないとの連絡がorz。
今度は別のファイルで発生していたので、原因は同じだろうと考えて先の保存時のフォントの変更を行おうとしたが、今度は正しく”日本語”となっていた。
試しに一度別のフォント（多言語）に変更して一度PDF出力をしてから再度日本語に戻して見たが効果無しorz。
その場では解決しそうになかったので”印刷”メニューから”Print to PDF”でPDFに変換する方法を教えてそれで運用して貰うことにした。
ところが翌日になって同じユーザーから連絡があり「直った！」とのこと。
どのようにしたのかを訊いたところ、もともとプリンタドライバ（CanonのLBP-8610及び8710の2台分）が正しく入っていなかったので、それらを一度削除してからインストールしたところ直ったとのこと。
原因も直った理由も良く判らないがとにかく使えるようになったので、そのまま使うとのことだけど、どんなところに影響が出てくるか判ったもんじゃないなぁ（汗）。
←クリックしてくれると嬉しいです。
文字化け・・・
某商用サイトでアニメ「Fate/Grand Order -絶対魔獣戦線バビロニア-」のあらすじを読んでいて”アレ？”と首を傾げてしまった。
そこには”ティアマト”のことを”ビースト（監）”と書いてあった。
私はすぐに「ははぁ、”ビーストII”と書いたのが文字化けしたな」と判ったんだけど、ゲームやアニメ本編を見ていない人なら”？？？”となることだろう。
ローマ数字の”II”はShift_JIS”には含まれておらず、MS-DOS/WindowsとMacOSでは異なるコードを割り当てていて、MS-DOS/Windowsで”II”と表記したのをMacOSで読むと”（監）”と読めてしまうのだ。
今回のはWindows10の環境で（監）と見えていて、件のサイトのページのソースを見ると文字コードはUTF-8となっていたので、Windows環境でShift_JISで”II”と入力したのをMacOS環境でhtml化する際に文字化けしたまま文字コードをUTF-8に変換したのでは無いだろうか？
このページには複数の（監）の文字が散見されるので、もしかすると変換は一括で行っていてチェックもしていないのかな？
←クリックしてくれると嬉しいです。
メールの文字化け・・・
ユーザーが使っているPCの一台でメールの文字化けが発生した。
文字が化けるのは特定のシステムから自動送信されてくるメールで、他のメールは問題無く読めるという。
化けたメールの内容を送って貰ったところ、charset=”UTF-8″の指定があるので、これが原因かと思いメールを送信しているシステムの管理者に連絡してここを”IS-2202-JP”にして貰った。
”特定のシステム”というのは、自分たちで運用しているシステムなので結構自由に試験が出来るのが有り難いんだけど、この変更では文字化けは改善されなかった。
試験で送って貰ったメールの内容をヘッダごとテキストファイルにして送って貰ったが、消した筈の”UTF-8”の文字列が残っていた。
変だな？と思って同じシステムから私の管理している試験用のアドレスに送って貰ってユーザーと同じメーラーで受信してみると全く問題無く表示され、”UTF-8”の文字列も入っていない。
ということはどこでこの文字列が付加されているのだろう？
メーラーの設定を見てもそれらしい設定はないので、今のところ対処方法は不明。
これは実機を見てチェックしないと駄目そうだなぁ・・・
←クリックしてくれると嬉しいです。