‘フィーチャーフォン’ タグのついている投稿


すっかり忘れておりました

WEBサイトをガラケーでアクセスした場合、UserAgentで判別して、ガラケー用サイトにリダイレクトするように設定して運用していました。
URLを打ち込んでの動作は問題無いのですが、ツイッターにURLを書き込んだ場合、リンクを踏むとPC用サイトを無理やり表示したような画面になっているという連絡が。
過去にも似た事例あったなあ、ということで小一時間ばかり数年前の記憶を辿っていました。人はすぐに忘れてしまうものです。

Googleの変換なのでGoogleに聞こう

「PC用サイトを無理やり表示したような画面」というのはGoogleの変換サービスだということは、すぐに思い出しました。実際アクセスログを調べてもそのタイミングでのガラケーのUserAgentは見つからないので、直接アクセスが無いのは明白です。
Googleが変換しているんだから、Googleが情報を出しているだろう、ということで調べてみました。

ありました。というか思い出しました

あー、これこれ。というものでした。

携帯端末での表示について
https://support.google.com/webmasters/answer/35312

ページのheader部分に1行記述するものでした。

<link rel="alternate" media="handheld" href="ガラケー用ページ" />

本当に綺麗さっぱり忘れていました。

ノウハウの蓄積も必要とされてこそ

わざわざ今更書くような事柄では無いのかも知れないけれど、実際自分が忘れていて、あれえなんだっけ?という風に思ったりするわけで、必要とされている間は誰かが情報を出し続けないといけないかな、なんてことを考えました。
フィーチャーフォンの新規サービスは先細り、というか、先細りももう無いくらいな現状ですが、それでも定期的にメンテナンスが発生する案件などもあるわけです。

もしこのタイミングで同じ問題にぶつかってここに来た人がいたら、ちょっとだけ嬉しいです。


またもやニッチなノウハウ。

PC用URLを代表にして、mod_rewriteでUserAgent毎にページを振り分ける処理をしていました

RewriteCond %{HTTP_USER_AGENT} "KDDI" [NC,OR]

こういった記述でUserAgentで振り分けしていました。よくやる手法です。.htaccessなんかに書きます。

FacebookにPC用URLでシェア投稿しました

お知らせや宣伝でよくやりますね。スマホで見ても、UserAgentの振り分けでスマホ用ページに行ってくれるだろうという見込みです。

それが予期せぬページが表示されていました

うーん、謎ですね…ということで調査しました。

FacebookのスマホアプリだとUserAgent文字列が違いました

auのiPhone5の場合、こんな感じでした。

"Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 [FBAN/FBIOS;FBAV/14.0.0.25.26;FBBV/4017285;FBDV/iPhone5,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/7.1.2;FBSS/2; FBCR/KDDI;FBID/phone;FBLC/ja_JP;FBOP/5]"

お尻の方に、まんまとKDDIが入っていました。
それが原因でガラケーの判定に引っかかり、結果ガラケーページに飛ばされていました。
他キャリアはどうかなと思い、ログをみたところ、DoCoMoは「NTT DOCOMO」が入っていました。ソフトバンクは入ってない様子。

判定の順番は上からなので、先にスマホの判定をいれるように順番を変えて解決しました。やれやれ。

ガラケーの判定はうしろに

今もガラケーの手当しているサイトはそんなに多くないと考えるのですが、逆に言えばそういう所はガラケーの対応の後にスマホの対応をしてきた経緯がある可能性が高いです。
ということは、記述も先にガラケーの判定があり、その後にスマホの記述したケースが多いかも知れません。その場合は今回のようなトラブルにぶつかる可能性があります。
 

今回もレアケースな対応例でした。


あいかわらずのニッチなネタ。
「いわゆるガラケーのWEBサイトの対応はいつまで続くのか?」という問題は開発の現場でたびたび話題にのぼる。

「ゆるやかに減りつつも完全にゼロになるのは大分先」だろうという結論にだいたい落ち着く

あるあるネタ的な内容であるけれど、おおよそこの結論になる。理由はざっとこんな感じ。

まだユーザーがいる

実際にユーザーがいるのは揺るぎない事実。スマホに乗り換えるケースがどんどん増えているものの、携帯ショップに行けば僅かではあってもガラケーも選択肢として用意されている。
誰もがスマホに移行したいわけではないのも事実だし、スマホを使った結果、ガラケーの方が便利なのでは無いかということを言う人も。
現状の認識として、ガラケーの後継サービスがスマホであるということが決定的な状態では無い雰囲気でもある。

サービスが継続している

ガラケーからWEBにアクセス出来てしまう。今のところ出来なくなるというアナウンスは出ていないし、恐らくしばらくは出ないだろう。
インターネット接続サービスとしてメールとWEBアクセスをまとめて提供している限りは、無くすのは難しいのではないか。

注目がスマホにシフトしただけでは

スマホのサービスがイケイケな状態なので、相対的に地味になってきているだけという説。サービスは継続しているわけで、使っているユーザーがスマホの足を引っ張っていると考えれば目の敵にする傾向だって想像できる。
若干思い込みの部分もあるものの、お金に結びつきにくい存在になっているだけで、現状維持としてありつづけるサービスと考えるのは確かに無茶な話ではない。

でも開発現場が減っていますよね

ガラケープラットフォームがメインとして開発されるプロジェクトは圧倒的に少なくなったようだ。
実際、お手伝いさせてもらっているところでもガラケーもしますけどね…といった感触。切り捨てはしないけれど対応デバイスの一つであり、深追いして開発が手間取るなら機能削りましょう、という言葉が簡単に出る。

その結果

よくあることで、新規の開発者や蓄積されて資料の活用が減ることで、サービスの企画も差し障りの無いものになりやすい。
FlashLiteバリバリのサイトを作ろうという企画を立てるならばスマホのアプリを充実させた方が良いとか。
ガラケー特有の仕様についても深くケアされることが減り、cookieを使えない端末があることや、表示できる容量についての検討などもそこまでキッチリされなくなった印象がある。
大雑把に言えば開発に工数をあまりかけなくなった。

それでもサービスは残る

ということで最初に戻ってしまう。
言ってしまうと日陰の技術になりつつあるガラケー開発だけど、華やかでないにせよ、それでもお仕事としてまだまだありますよね…という部分は間違いない。

新しい技術だけは技術では無いけれど、進化の速度が早い業界の中ではもう恐ろしいほど古い技術になってしまったんだなぁと思うと、不思議な気持ちになったりする。


本当にちょっとした小ネタ。
いまさらながらFlashLite1.1を動的生成するという作業があった。本当にいまさらなんだけど、さてさて…とネットをざっと見た感じ、swfmill0.2系にパッチをあてるインストールの記事が上位にあったので最新情報を書いてみることにした。
情報は常にアップデートされるべきだとは思うけど、追い続けられるわけでも無いから、気づいた誰かが新しい記事を書いていけばいいんじゃないかな。

現時点の最新バージョンは、0.3.2です

swfmillというのは、swfファイルからXMLファイルを作成したり、逆にXMLファイルからswfファイルを作成してくれるツール。

基本的な流れは、AdobeFlashなりで元になるswfファイルを作成。それをswfmillを使ってXMLファイルに変換。そのXMLの中身を変更して再度swfを作成という風。
XML中に、画像はbase64のエンコード文字列で、テキストはそのままテキストで記述出来る。最新版のドキュメントを見ると外部の画像やフォント、swfファイルも指定できるみたい。

0.2系ではパッチがあった

ざっと検索して出てくる日本語の記事は、まだ0.2系だった頃の内容のようだ。FlashLite1.1の内部文字コードはCP932なのだけど、swfmillではUTF-8がデフォルトで文字コードを変更できないので対応パッチをあてましょうという事が書いてある。
最新版の0.3.2でも

#swfmill swf2xml test.swf test.xml
error : xmlEncodeEntitiesReentrant : input not UTF-8

とエラーが出た。これはパッチの登場か?と思いきや

#swfmill -help

swfmill 0.3.2
    XML-based SWF processing tool

usage: swfmill [<options>] <command>

<command> is one of:
    swf2xml <in> [<out>]
        convert from SWF to XML.
        <in> is a single SWF file, or 'stdin'
        <out> is a single XML file, or (by default) 'stdout'

    xml2swf <in> [<out>]
        convert from XML to SWF.
        <in> is a single XML file, or 'stdin'
        <out> is a single SWF file, or (by default) 'stdout'

    simple <in> [<out>]
        convert from a movie definition file to SWF.
        <in> is a single XML file, or 'stdin'
        <out> is a single SWF file, or (by default) 'stdout'
        (for details, see README)

    xslt <xsl> <in> [<out>]
        transform <in> to <out> as described by <xsl>.
        <xsl> is the XSLT stylesheet,
            and can use the swft: extension.
        <in>  must be some XML (depends on <xsl>)
        <out> is either SWF (when it ends in .swf)
            or XML, by default on 'stdout'

<option>s are:
    -h print this help and quit
    --version print the version number and quit
    -v verbose output
    -V extra-verbose debugging output
    -d dump SWF data when loaded (for debugging)
    -e specify text encoding in SWF (for SWF 5 and earlier only;
           default: UTF-8).
    -n deactivate libxml network access

Please report bugs at https://github.com/djcsdy/swfmill/issues

と、ありがたいことにエンコーディングのオプションが実装されていた。

ということで

#swfmill -e cp932 swf2xml test.swf test.xml

で、無事にXMLファイルが作成された。めでたしめでたし。ちなみにXMLファイルのエンコードはUTF-8になる。

まぁこれだけの話です

以上、最新版ではパッチあてなくても平気ですよ、というお話でした。
正直、現時点でFlashLiteやFlashの動的生成に需要がそんなにあるのか?という部分はあるけれど、だからこそ気づいたことを書いて公開しておこうかなと思った次第。ちょっとでも役に立てば嬉しいです。