オコゲのご飯はあまり好きではない、ユゲタです。
なんだか、歯にこびりついてニチャッとするあの感じが、あんまりいい感じじゃないんですよね。
同じ理由で、焦げ目の強い、焼きおにぎりも、好んで食べないです。
さて、今回私が紹介するITのちょこっとテクニック(略してチョコテク)は、
#(シャープ)付きのファイルの取り扱いです。
問題の発見
自宅の書籍は全てnasサーバーにスキャンして入れているため、それを読むのに、スマホアプリか、自分で作ったwebブラウザでの読書アプリを使っていますが、スキャンした書籍は、PDFファイルなんですが、ネットなどで個人で配布されている書籍ファイルでzipやrarファイルのモノも1ページずつ読めるように対応させています。
簡単に説明すると、PHPで、1ページずつ画像データを取り出して、ブラウザで表示するまあまあシンプルな構造なんですが、PDFファイルの場合は何の問題もないのですが、zipやrarファイルの場合は、もともとの圧縮されたファイル名で仮想ファイルとして取り出してそのまま使っている仕様にしています。
今回、想定しないファイル名に遭遇して、その対応をしたという話ですが、ファイル名に#(シャープ)が文字列として入っていた時に、そのファイルにURLでアクセスできないという不具合でした。
URLに#(シャープ)はアンカーリンクとして扱われる
もはやお気づきの人もいると思いますが、URLの中に#(シャープ)が含まれていると、それは「
アンカーリンク」として扱われてしまいます。
アンカーリンクとは、知らない人のために説明すると、別名「ページ内リンク」と言って、URLでそのページ内のアンカー(name属性)に対して自動スクロールさせる機能をブラウザが持っています。
なので、下記のように、ファイル名に#(シャープ)が入っていると、
http://example.com/archive/おもろい書籍#001.jpg
#より後ろのURL部分が、アンカーリンクとブラウザが勘違いしてしまうんですね。
解決方法
OS側のファイルとして使う分には問題がないけど、URLとして使えない文字列というのは、いくつかありますが、
予約後の用な感じで、URLとして文字列が使えない場合は、文字列をエンコード文字列に変換して、使ってあげればいいんです。
ちなみに、#(シャープ)のURLで使える文字エンコードは"%32"です。
http://example.com/archive/おもろい書籍%32001.jpg
これで問題なくアクセスすることができました。
同じ理由で、クエリで使う、?や&や=などの文字列も、エンコード文字を使うことでファイル名をわざわざ変更しなくても対応することができます。
まとめ
なんとなく、この手の不具合は想定していたので、実際にそうした事象を発動するデータがあって、システムを修正することができたので、公開システムではなく、自分システムで使って見つけられた事に、ある意味得した気分になりました。
よく考えたら、Googleの検索でも、日本語文字列は全てエンコードされた状態になってますからね。
わざわざ1文字ずつエンコードするんじゃなく、URLエンコードさせたほうが賢明ですね。
javascriptもphpもデフォルトでurlエンコード機能は持っているので、それを使わない手はないという事です。
ちょっとスキルアップした自分に乾杯。
0 件のコメント:
コメントを投稿