自分の使いたいツールを自分で作って自分で使うを遂行している、下駄です。
最近自宅の本棚を全てスキャンして、デジタルブック化できたんですが、それを読むリーダーにいちいちコピーして、読むのがめんどくさくて、いっそのことそのデータが入っているNASをブックリーダーサーバーにしてしまうことを思いついたんですが、
それをwanで公開して（もちろんセキュリティは対処しますよ）しまえば、スマホやタブレット端末で、いつでもどこでも自宅の書斎にアクセスできて、読むことも探すことも可能になるので、自分だけの図書館を手に入れた感じです。
そんな便利なツールを作っている時に、macでwebサービス開発をしているんですが、ファイルシステムに大きな不具合（というか、思いも寄らない仕様）を見つけてしまったので、ブログに書き綴っておきます。
本日のIT謎掛け
「Bookリーダー」と、かけまして・・・
「出川哲朗のトーク」と、ときます。
そのココロは・・・
無駄な「リアル」はいらない。
「プログラム」フォルダー検索のトラブル
書籍一覧をジャンル別、作者別などでフォルダ分けして、サーバーに保存する場合に、
「プログラミング」カテゴリーの書籍を「プログラム」というフォルダを作って、スキャンしたpdfファイルを放り込んでいたんですが、その階層をwebシステムで読み取って、ファイルパスを取得するという検索システムを作っていた時の事です。
何の問題もなく、フォルダ検索、ファイル（書籍）検索ができたと思って、色々と検索ワードチェックをしていた時に、どうしても、「プログラム」というフォルダ検索が引っかからないことに気が付きました。
英語文字のものや、漢字、ひらがな、カタカナ・・・どれも問題ないし、コピペしてみても、違いが全くわかりません。
挙動としては、そのフォルダの「プログラム」という文字を直接コピペすると、検索にヒットします。
まったくもって、意味が分からず、モニタ画面とにらめっこ状態をしばらく続けていて、ひとつの仮説が浮かんできました・・・
原因は文字コード
同じ文字で、入力するとNGで、コピペすると、OKになるという現象は、どこかのタイミングで文字コードが変換されているのではないか？
という疑惑です。
そこで、直接キーボードから、文字入力をした場合の文字コードを調べてみると以下のような感じです。
[ プ : 12503] [ ロ : 12525] [ グ : 12464] [ ラ : 12521] [ ム : 12512]
１０進数のキャラクターコードを取得してみました。
次に、フォルダ名の文字列の文字コードを調べてみると・・・
[ フ : 12501] [ ゚ : 12442] [ ロ : 12525] [ ク : 12463] [ ゙ : 12441] [ ラ : 12521] [ ム : 12512]
なんと、「プ」と「グ」の文字が、濁点、半濁点が分離されている事に気が付きます。
半角カタカナでよく見るこの構成ですが、全角カタカナで見るのは初めてでした。
そして、「プログラム」という文字自体は、人の目で見て違いが分からない状態です。
気になったので、ひらがなも調べてみました。
# 直接入力「ぷろぐらむ」
-----
[ ぷ : 12407] [ ろ : 12429] [ ぐ : 12368] [ ら : 12425] [ む : 12416]
# フォルダ名に入力「ぷろぐらむ」
-----
[ ふ : 12405] [ ゚ : 12442] [ ろ : 12429] [ く : 12367] [ ゙ : 12441] [ ら : 12425] [ む : 12416]
が〜〜〜〜〜ん！！！
衝撃！！！
濁点、半濁点が、キレイに分離されています。
犯人はMacOS!!!
この文字が切り替わるタイミングが判明しました。
それは、開発で使っているノートPCのmacで、フォルダを作ったタイミングでした。
「プログラム」とキーボードで入力して、フォルダを作ったあと、すぐにその文字列のアスキーコードを調べてみると、濁点・半濁点が分離されてしまっています。
おそらくOS側の何かしらの仕様なんだと思いますが、キーボード入力せずに、「プログラム」という文字をコピペしてフォルダを作っても勝手に変換されてしまいます。
ただし、webサーバー(linux)などから、ファイル、フォルダをダウンロードしてきた場合は、入力したままの文字コードを保ってくれているようです。
ようするに、macOSのfinderが犯人だったんです！！！
注意点
macosもサーバーバージョンがありますが、おそらく同じ事が発生するでしょうね。
それを考えると、macOSサーバーを使うと、本番の公開サーバーでこうした不具合が出ることはほぼ間違いないでしょう。
本番をlinuxで統一すると、問題はなさそうなので、開発環境だけと割り切っておけば問題ないし、そもそも、日本語文字列のファイルやフォルダをシステムで使うというのが確かに抵抗があるんですが、
実際の書籍ファイルは、日本語で管理するのが一番効率的だという事も考えると、致し方ない仕様なのですが、おかげで今回の事象を見つけることができたので、ネットでググってもこの現象を見つけることができなかった事を考えると、もしかしたら、他にも困っている人がいるかもしれないな〜と感じました。
調べてませんが、windowsは問題なさそうです。
この書籍ファイルはwindowsでスキャンしたファイルで、プログラミング.pdfは、ちゃんと検索でヒットしていたので、仮設ですがmacだけの仕様というのは間違いないでしょう。
昔からこの仕様だったのかな〜？？？詳細はわかりませんが、もしかしたら、バージョンアップで知らないうちに修正されてしまうかもしれませんね。
このブログをappleのmacOS開発部門の人に見てissueとして受け取ってもらえるといいなあ・・・
0 件のコメント:
コメントを投稿