souichirou のすべての投稿

[iPhoneXS] Suicaの残高情報が更新されない・・・

普段は鉄道もバスも乗らないのでICカード乗車券を持ち歩くこともなかったのだが、たまに利用する際に小銭を用意しないといけなくなるので、1枚だけICカード乗車券を買ったことがる。

とりあえず1,000円だけ入れておいて必要なときにはそのカードを使う。
そして残高が減ってきたらチャージする。
仕事の日と休みの日では財布が違うので、カードを移してないときは現金で払う。
カードを使うことに面倒を感じていた頃にiPhone7が出てSuicaでの対応が可能になった。待ってたよ。

スマホは常に持ちあるいているので、急にバスを利用することになっても大丈夫だし残高が減ってきてもApplePay経由でチャージできる素晴らしく便利。
財布要らずでコンビニにちょっと買い物いけるし。

昨日久しぶりにコンビニでSuicaを使った際に、2,336円の表示があって『シャリーン』と音がして店員さんも「はい大丈夫です」と言われたのに金額表示が変わってないことに気がついた。

使った直後は通知が表示されるのにそれも表示されない。
利用履歴は直ぐに反映されないので後ではっきりするかと思ったけど気になってSuicaアプリの明細を見てみると2週間前に使ったときから残高が反映されていないことが分かった。
昨日コンビニで使おうとした時点での残高は 2,336円 ではなく 2,076円 が正解だった

Walletの方のSuicaの情報を確認しても同じ状態

アプリを立ち上げなおしても、iPhoneを再起動しても変わらなかった。

色々といじっていると
ApplePayでSuicaの情報を表示させて『ヘルプモードをオンにする』を押したあとにSuicaアプリを立ち上げると金額が更新されることが分かった。


そしたら、通知もやってきた

真ん中の960円は昼間に使ったときの分
最後の260円は10日前に使ったときの分

やっぱり通知も残高更新も止まっていたことが分かる。

まあ、更新されたしよかったよかったと安心したけど、Suicaを使うとやはり同じ現象が起こってしまっている。
Suicaアプリは更新されていないのに・・・
iOS12.1にはまだ更新してないから影響ないけど更新してないせいで影響でてるのかな

[CentOs7]composerのアップデートでエラーがでてアップデートできないときの対処法

CentOS

先の投稿でcomposerのアップデートでコマンドが通らないときの対処法を書きましたが、今度は更新途中でこけてしまう場合の対処法です。

エラーをよく見てみると
Update failed (The zip extension and unzip command are both missing, skipping.
とあります。

zipとunzipコマンドが通らないよ。と言われています。

これも、いくつかサーバを管理していると入れていないパッケージがあるときに起きてしまいます。
なので入れてしまいましょう

インストールが終わったら再度composerの更新コマンドを叩きます。

今度こそ正常に更新が流れます。

[CentOs7]composerのアップデートでコマンドが見つからないとエラーが出た場合の対処法

CentOS

いくつかサーバを管理していると、予期せぬタイミングでコマンドが通らないサーバが出て「???」と迷ってしまいます。

今日はcomposerのアップデートでコマンドが通りませんでした。

Composer入ってる?っていうのが最初の確認ポイントです
いくつかサーバを管理してると入れてるつもりのものが入っていないということはよくある事です

composerとだけ叩いて色々出てくればcomposerはインストールされています。

ということは、アップデートコマンドが通らないのは単純にパスが通っていないためです。
Composer入れたときは何かしら作業しているので、その時にコマンド叩いているはずなのに何故今になって通らないだろうという疑問は捨てます。動かないものは動かないのです。

composer.pharをパスが通る位置に配置すればOKです。
配置すればOKと言われてもどこにあるのか・・・という方はlocateコマンドで探しましょう

composer.pharをパスが通る位置に移動します

はい終了!

composer.jsonがある位置に移動して更新コマンドを叩けば正常に動作するはずです

FFmpeg(エフエフエムペグ)を使って4Kサイズで撮った動画を一気にリサイズする

カメラの性能も上がり、4Kサイズで撮影できるビデオも普及し始めました。
しかし、4Kサイズで撮るメリットってあんまりない気はするんですよね

サイズの比較
・4K   ・・・ 3840 * 2160
・フルHD ・・・ 1920 * 1080
・HD   ・・・ 1280 * 720

スマホやタブレットで見るならHDサイズでも十分耐えうる解像度です。
ブルーレイに焼いて綺麗に見たいという人もいるでしょうが、大多数の人が望んでるのかなと
強いて言えば、動画編集(フルHDサイズ)する際に4Kサイズだからこそ部分的な拡大をしても画質が荒れないというメリットは大きいです。

でも、動画編集をする際に4Kサイズのメリットに助かる場面などほぼなく、無駄に容量が大きく編集作業も時間が掛かるというデメリットの方が大きくなってしまいます。
それでも撮影時は4Kサイズで撮っておきたいですよね。

AdobeのCreative Cloudに入っていれば、Media Encoderを使って一括で動画のサイズを小さくできますが、なんたって高価です。
そこで、FFmpegを使ってバッチ処理で一括でリサイズしてしまいましょう。

FFmpegのインストールは前回の記事を参照してください。
FFmpeg(エフエフエムペグ)を使って普通に撮った動画ファイルをタイムラプス風に変換する

【フォルダに対象ファイルを入れる】

今回もデスクトップ上に『movie』というフォルダを作って、その中で動かします。
デスクトップ上に『movie』というフォルダを作って、その中に変換したいファイルを設置します

2.19GBのファイルもありますね。
このファイルの記録時間って5分程度なんです。
30分回し続けると15GBぐらいいってしまいます。

次はシェルスクリプトファイルを作ります。
ターミナルを立ち上げて、

処理の中身は
・対象フォルダ内のMP4ファイルを全て検索
・元のファイル名を取得
・FFmpegを使ってサイズをフルHD(1920)サイズへリサイズ
・リサイズしたファイル名は末尾に _sizedown を付ける

FFmpegのコマンドで -vf scale=1920:-1 とあるのがサイズ変更のコマンドです。
横幅や高さに合わせてアスペクト比キープできるで、サイズ変更には便利なコマンドです。
今回は横を1920と指定して、高さはアスペクト比キープで調整されています。

気をつけないといけないのが、幅が1920以下のファイルが存在しているとサイズを拡大することになってしまいます。
画質が粗くなることになりますのでファイルの設置時には気をつけてください。

シェルスクリプトファイルを保存したら実行です

ファイル分だけ処理がループします。

完了したフォルダを見ると

1920サイズへ変換

ファイルの容量がかなり少なくなったのが分かりますね。

もう1つ小さく1280サイズに変換した場合は
1280サイズへ変換

2.19GB が 95MBになています!

驚異的な容量削減です。
画質は落ちますが、編集時にはこのファイルを使うとエンコード時間が減るので助かります。
4Kサイズでないとダメな部分には4Kサイズを使用して、その他は書き出しサイズに落としたファイルを使うほうがよさそうです。

FFmpeg(エフエフエムペグ)を使って普通に撮った動画ファイルをタイムラプス風に変換する

「この間○○が撮った動画を編集して」と言われ、とりあえず素材をもらって軽く編集

「この部分はタイムラプスの分と入れ替えて」と要望が入り、「タイムラプスで撮った分あったっけ?」となる。
カメラのタイムラプスモードで撮っていなければ、その動画はもちろん普通の動画である。

再生速度を上げて変換すれば30分を2分以内にすることなど容易いが、所詮早送り状態なのでタイムラプスにはほど遠い。

そこでFFmpeg(エフエフエムペグ)の登場
ここではMacを元に説明するが、コマンドはWindows版でも同じです。

【MacにHomebrewをインストール】

MacBookProにFFmpegをインストールしますが、先にHomebrewをインストールします。
HomebrewとはMacOS用のパッケージ管理システムで、コマンドを打つだけでMacOSに様々なソフトウェアやライブラリをインストールでき、更新もコマンドで簡単にできるようになるものです。

「なんだか難しそう」と私も初めは思いましたが、入れてみるとすっごく簡単で便利に使えるようになります。

・Homebrew ・・・ https://brew.sh/index_ja

HomebrewをインストールするにはXcodeがMacにインストールされていなければいけません。
Xcodeをインストールするのはかなり重いですがここは頑張るしかありません。

Xcodeのインストールが終わったらMacのターミナルを起動します。
起動したら下記のコマンドを流します。

少し時間が掛かるので画面が固まったように感じますが、じっと待っているとパスワードを聞かれます。
このパスワードはMacにログインしているユーザーのパスワードを入れます。

インストールが終わったら、下記のコマンドを打って確認します。

バージョンの確認は

【MacにFFmpegをインストール】

Homebrewのインストールが終わったらFFmpegをインストールします。

これだけでインストール完了です。
確認のために下記のコマンドを打ってみます。
ヘルプがずらっと表示されますが一番上を見てみるとバージョンが表記されています。

これでFFmpegの準備はできました。
普通に撮った動画をタイムラプス風に変換してみましょう。

【FFmpegで動画を変換】

FFmpegはマンドラインで操作する必要がありますが、基本を覚えれば難しくありません。
が、初めての方は難しく感じられると思うので、基本形をお伝えすることにします。

・Macのデスクトップに『movie』というフォルダを作成しましょう。
・『movie』フォルダに変換したいファイルを置きます。上書きしてしまうと元のファイルが消えてしまうので元のファイルは別の場所に保存しておきましょう。

ターミナルを再度立ち上げて、下記のコマンドを打つと対象のフォルダまで移動できます。

ここまでくれば、後はタイムラプス風にしたいようにコマンドを微調整していくだけです

例)16倍速で、フレームレートを10/sに

例)32倍速で、フレームレートを10/sに

例)64倍速で、フレームレートを10/sに

音のテンポを倍速に合わせて変更しています。
atempoは2.0までしか設定できないので、繋げた分だけ掛け算となります。

災害情報を確認できるサイト一覧

大規模な災害が発生した場合に、どの場所でどのような状況なのか確認できるページを集めてみました。

【全般】

・内閣府
 http://www.bousai.go.jp/

・国土交通省(道路等)
 http://www.mlit.go.jp/

・総務省(電話回線等)
 http://www.soumu.go.jp/

・総務省消防庁
 http://www.fdma.go.jp/

・防衛省自衛隊
 給水や入浴などの支援情報の発信あり
 http://www.mod.go.jp/

・気象庁(大雨・台風・地震・火山等)
 http://www.jma.go.jp/jma/index.html

・日本道路交通情報センター
 http://www.jartic.or.jp/

【災害救助法適用】

・内閣府
 http://www.bousai.go.jp/taisaku/kyuujo/kyuujo_tekiyou.html

【避難指示・避難勧告等】

・Yahoo!
 https://crisis.yahoo.co.jp/evacuation/

【緊急・被害状況】

・Yahoo!
 https://typhoon.yahoo.co.jp/weather/jp/emergency/

【インフラ】

・NTT Docomo
 https://www.nttdocomo.co.jp/

・au
 https://www.au.com/

・ソフトバンク
 https://www.softbank.jp/mobile/

【安否情報】

・NTT & NHK提供
 https://anpi.jp/top

【都道府県サイト】

・北海道
 http://www.pref.hokkaido.lg.jp/

・青森県
 https://www.pref.aomori.lg.jp/

・岩手県
 http://www.pref.iwate.jp/

・宮城県
 http://www.pref.miyagi.jp/

・秋田県
 http://www.pref.akita.lg.jp/

・山形県
 https://www.pref.yamagata.jp/

・福島県
 http://www.pref.fukushima.lg.jp/

・茨城県
 http://www.pref.ibaraki.jp/

・栃木県
 http://www.pref.tochigi.lg.jp/

・群馬県
 http://www.pref.gunma.jp/

・埼玉県
 https://www.pref.saitama.lg.jp/

・千葉県
 https://www.pref.chiba.lg.jp/

・東京都
 http://www.metro.tokyo.jp/

・神奈川県
 http://www.pref.kanagawa.jp/

・新潟県
 http://www.pref.niigata.lg.jp/

・富山県
 http://www.pref.toyama.jp/

・石川県
 http://www.pref.ishikawa.lg.jp/

・福井県
 http://www.pref.fukui.jp/

・山梨県
 http://www.pref.yamanashi.jp/

・長野県
 https://www.pref.nagano.lg.jp/

・岐阜県
 http://www.pref.gifu.lg.jp/

・静岡県
 https://www.pref.shizuoka.jp/

・愛知県
 http://www.pref.aichi.jp/

・三重県
 http://www.pref.mie.lg.jp/

・滋賀県
 http://www.pref.shiga.lg.jp/

・京都府
 http://www.pref.kyoto.jp/

・大阪府
 http://www.pref.osaka.lg.jp/

・兵庫県
 https://web.pref.hyogo.lg.jp/

・奈良県
 http://www.pref.nara.jp/

・和歌山県
 https://www.pref.wakayama.lg.jp/

・鳥取県
 http://www.pref.tottori.lg.jp/

・島根県
 http://www.pref.shimane.lg.jp/

・岡山県
 http://www.pref.okayama.jp/

・広島県
 https://www.pref.hiroshima.lg.jp/

・山口県
 http://www.pref.yamaguchi.lg.jp/

・徳島県
 https://www.pref.tokushima.lg.jp/

・香川県
 http://www.pref.kagawa.jp/

・愛媛県
 https://www.pref.ehime.jp/

・高知県
 http://www.pref.kochi.lg.jp/

・福岡県
 http://www.pref.fukuoka.lg.jp/

・佐賀県
 https://www.pref.saga.lg.jp/

・長崎県
 https://www.pref.nagasaki.jp/

・熊本県
 http://www.pref.kumamoto.jp/

・大分県
 http://www.pref.oita.jp/

・宮崎県
 https://www.pref.miyazaki.lg.jp/

・鹿児島県
 https://www.pref.kagoshima.jp/

・沖縄県
 http://www.pref.okinawa.jp/

【鉄道】

・Yahoo!
 https://transit.yahoo.co.jp/traininfo/top

・JR北海道
 https://www.jrhokkaido.co.jp/

・JR東日本
 ○関東 http://traininfo.jreast.co.jp/train_info/kanto.aspx
 ○東北 http://traininfo.jreast.co.jp/train_info/tohoku.aspx
 ○信越 http://traininfo.jreast.co.jp/train_info/shinetsu.aspx

・JR東海
 http://jr-central.co.jp/

・JR西日本
 http://trafficinfo.westjr.co.jp/list.html

・JR四国
 http://www.jr-shikoku.co.jp/info/

・JR九州
 http://www.jrkyushu.co.jp/trains/unkou.php

・九州のりものinfo
 九州内のバスやフェリーも確認できる
 http://www.norimono-info.com/

[PHP]重要な文字列を暗号化して保管し、利用するときは復元する方法(OpenSSL使用)

PHP

mcrypt関数はPHP7.1.x系より非推奨、PHP7.2.x系より廃止となりましたので現在推奨となっている『OpenSSL関数』で文字列の暗号化と復元をする方法を紹介します。

重要な個人情報をフォーム等から受取り、データベースへ保存する際には気をつけなければいけません
社内のシステムであってもダンプデータを持ち出されれば個人情報が丸見えの状態で取り出すことができてしまいます

パスワードなんかは確認の際に利用するだけなのでハッシュ化して、保存されている値とPOSTされた値を比べればいいので復元する必要はありませんが、顧客の住所などを保存したい場合は後で再利用するので復元できる形で保存する必要がでてきます

PHPを使ってMySQLなどのデータベースに保存する方法をご紹介します

使用する関数は OpenSSL

まずは暗号化する処理です

ここで暗号化は完了ですが、復元させるためにデータベースに保存する項目はIVキーと暗号化されたデータとなります
IVキーとは『単に暗号化ルーチンに異なる初期値を与えるためだけのもの』ということで、一緒に保存して構いません
重要なのはパスフレーズの方です。パスフレーズまで漏れると誰でも復元できてしまうようになります

今回はPHPの内部にパスフレーズを記述していますが、FTPサーバから不正侵入された場合にはファイルを直接参照されてしまいますので、サーバ内の外部からアクセスできない場所に文字列を保存したファイルを置いておき、includeなどで呼び出した方がセキュリティとしては高まります
例)
/var/etc/security/hoge など

データベースに保存するのはIVキーと暗号化されたデータになりますが、この2つの値はどちらともバイナリデータです
保存するにはカラムのデータ形式をバイナリに指定していてもいいですが、バイナリデータとして保存するとSQLで抽出した際の視認性が好きじゃないということでBase64でエンコードした値を保存するようにしています

バイナリーだとこんな感じに見えるのが
M�(���z��53�a

Bace64でエンコードすると
TaB/KMTUA/Z66scGNTMWsGE8RdrSgPwraNRtcWRLmCQ=

みたいになります

Base64でエンコードしたデータはデコードでそのまま復元できますし、カラムの形式もVARCHAR型で構いませんので難しいことを考えなくてもよくなります

Base64にエンコードするには

この値をデータベースに保存すれば暗号化処理の完成です

続いては復元の方法です

パスフレーズの設定を細かくするかどうかにもよりますが、そんなに複雑な処理もなく重要な情報を復元できる形で暗号化できますので、万が一に備えて暗号化を進めていくのもいいかもしれません

【JavaScript】メールアドレスが収集されるのを防ぐ

WEBサイトにメールアドレスを素のままで記載するとSPAMメールのアドレス収集ロボットに集められてしまうので色々と工夫しますよね。
迷惑メールが増えてしまうと大事なメールを見落としていまう確率があがってしまいます。

対策してよくあるのは
・@マークを全角にする
・@マークをHTMLエンティティ化(【@】にする)
・メールアドレス自体を画像にして表示する

どれも利用者に不便をかけたり、煩わしかったりします。
画像以外はクローラーが対策をすれば収集するのは簡単ですしね。

『クリックしたときにメールソフトを起動させてすぐにメールが送れるようにしたい。しかも、あんまり複雑にしたくない。』

そんな場合にJavaScriptを使ってサイトソースにメールアドレスを残さない方法です。

【用意するもの】

・jQuery
 普通にJavaScriptだけでもできますが、他の部分の処理をjQuery使っているのにここだけ記述が違うのもメンテナンスが悪いので
・メールアドレスをbase64に変換
 今回の仕組みはbase64にした値を元にメールアドレスを戻して表示します

【記述】

メールアドレス例:(わざと大文字化と半角スペースを空けています)
test-info @ exsample.com

base64形式にエンコード後:
dGVzdC1pbmZvIEAgZXhzYW1wbGUuY29t

[HTML]

[JavaScript]

メールアドレスを表示させるアンカータグの記述にあるdata属性(data-obfuscatekey)にbase64形式にエンコードしたアドレスを入れます。
JavaScriptで該当の要素にあるdata属性(data-obfuscatekey)の値を取得して、atob関数でbase64形式でエンコードされたデータの文字列をデコードします。

”bWFpbHRvOg==”という文字列をデコードすると”mailto:”となっているので、アンカータグ内のリンク先がattr関数で”mailto:test-info @ exsample.com”と置き換えられます。

最後にリンクテキストにデコードしたメールアドレスを書き換えています。

ソースコードを見てもbase64形式にエンコードされた文字列しか残っていませんのでクローラーもメールアドレスとは判別するのは難しいでしょう。

data属性の値をデコードしてメールアドレス形式だったら収集するクローラーが出てくる可能性もあります。
より複雑にしたい場合はメールアドレスを分割し、data属性を複数持たせておいてデコードしたものを繋ぎ合わせればいいだけです。

PHPで手軽にWEBサービスの死活監視&エラー時にChatWorkにメッセージを投稿する

htaccess

WEBサーバの死活監視の1つとして有効的なのがURLチェックです。

PINGコマンドでドメイン名を指定してもサーバ側(FWなども含む)でPINGに応答しないように設定していると稼動しているのに応答がないといった状況になります。

1番正確に判定しやすいのが、実際にURLにアクセスして目視する。
ですけど、1日に何度も目視なんてしてられませんから自動で監視してくれるサービスもあります。

大きな企業になれば自動で監視してくれるサービスにも費用を出して万全の体制がとれますが、あまりお金を掛けられない会社では担当者が毎日WEBサイトにアクセスして死活監視を目視しているということがあります。

また、監視サービスを利用していても、エラーが発生した場合に複数人にEメールメッセージは送信されているが「誰か対応するだろう」といった対応漏れが発生してしまうことも起こります。

Eメールだと他のメールに埋もれて見落としてしまったり、自動メール配信なので迷惑メールとして判定されてしまったりとリスクがあります。

そこで、お金をかけずに複数人でも進捗が把握できるようにチャットワーク(https://go.chatwork.com/ja/)を利用する仕組みを考えました。

【用意するもの】

・常時稼動しているサーバ(インターネット疎通あり)
・PHP7.x系
・Cron
・チャットワークのアカウント(API専用で用意した方がいいです)
 ※チャットワークについてはこちら(https://go.chatwork.com/ja/)

【確認できること】

ブラウザからHTTP(S)接続してページが見えるかどうか

HTTPアクセスを強制リダイレクトでHTTPSにしているなどアクセス左記がリダイレクトされていてもHTTPステータスコード302が返ってきますので正常稼動していると判定します。

SSL証明書の失効、設定ミスの場合はアクセスが拒否されますのでエラーとして判定されます。

ログイン画面が表示されるものは正常稼動と判定されますが、Basic認証の場合はエラーとして判定されます。

グローバルIPでHTTP接続が可能ならば正常として判定されます。

サーバの応答が異常に遅い場合(応答の状態にもよりけり)もエラー判定されます。

【スクリプト】

注意点
・監視したいサービス名称を決める際は2バイト文字・半角カナ・記号等は避けてください。サーバ側の設定によっては文字化けファイル名が生成されて全体にエラーを及ぼす可能性があります
・エラーが発生した日時を記録するファイルを生成しますので、ファイルの設置場所には書き込み権限が必要です
・Cronを利用する場合はサーバに余分な負荷をかけないように間隔を調整してください
・チャットワークのAPIは5分間に1000回までですでの余分な動作の実行はしないように調整してください
・チャットワークのルームIDとは対象チャットルームURL(www.chatwork.com/#!rid0000000)の /#!rid 以降の数字です
・.htaccessで404Not Foundを正常なページへ強制リダイレクトさせている場合は正規に存在するファイル(テキストファイルなど)を指定しましょう

必ず書き換えが必要なのは最初の項目の $target と $cwRoomId と $cwTokenCode の部分です。
サーバは稼動しているけども負荷が高くて応答に時間がかかっている場合も分かるように応答時間をシビアに設定しています。
応答時間をゆるくしたい場合は $curlOptions の項目を変更してください。
エラーが発生して対応するまでには時間が必要ですので、何度もお知らせがくるのが嫌な場合は $compTime の値を変更して下さい。

任意のファイル名でスクリプトを設置したらブラウザからアクセスしてみてください。
://example.com/hoge.php

全てが正常であれば架空のサブドメインを追加してみてください。
エラーがでてチャットワークで指定したチャットルームにメッセージが届けば成功です。

【cronの設定】

あまり頻繁にすると監視先のサーバに負担をかけてしまうので環境に合わせて調整しましょう

JavaScriptで数値の取り扱いに気をつける

JavaScript

TwitterのAPIを使ってデータ取得し、JavaScript経由で処理をしているときにはまった話です。

特例の文字列に関するTwitterユーザーをユーザー検索APIで叩いて数名の候補を一覧表示して、その中から目的にあった1人のユーザーをリスト化していくという作業をしていました。

使用API:GET users/search
詳細:https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-users-search

Twitterユーザーを一意にする情報としては”screen_name”もしくは”id”
本来の目的からいくと”screen_name”が欲しかったので、この時点で取得した”screen_name”を保存していこうかと考えていましたが、Twitterのアカウントは使われていなければ自由に取得することが可能なため、悪意のある取得であったり、偶然のバッティングが発生することもあります。

これから将来的には、必要性の高い”screen_name”は入替の可能性も出てくるかもしれません。
そこで、書き換えの可能性があり得る”screen_name”だけを取得するよりもユーザー”id”を基準として取得しようと考えたわけです。

やっぱりデータの一意性はID(数値)だね。ということで

JavaScript経由でデータベースに保存しようとしていたので、文字列である”screen_name”にエスケープが必要な文字が入っていると面倒だなとも考えたのも1つです。
(DBに保存するまでデコード、エンコードが繰り返されるので)

ユーザーIDだけ取得してJavaScript経由でPHPスクリプトに渡し、DBに保存する手前で再度API(GET users/lookup)を叩いて”screen_name”を取得するといった流れで作りこみました。

送信ボタンにセットした値はこんな感じです。

すいすいと処理を進めていっていると、DB保存前の段階で”screen_name”が取得できなかった場合のエラー処理コードが表示されました。
とりあえず1件飛ばして進めていると、また同じエラーコードが表示されました。

IDが取得できていなければ先に進めないようにしていたし、ソース表示してもちゃんとIDがデータとして渡されるようになっている。
エラーがでている対象をよく見てみると「IDの桁が多い」ということが分かりました。

JavaScriptは『IEEE754』という規格に従って内部的に数値を『64ビット倍精度』で保管しています。
うまい表現が見つからないですが、処理できる値に限界があるって感じです。

まさかTwitterのIDがそこを超えちゃってるだなんて・・・
数値だけでIDが構成されているので桁数が増えていっているのでしょう。

限界を超えてしまったものをどうするかというと、toFixed(0)を使えばうまく処理できました。

getID.toFixed(0);

こうすれば数値としてPHPスクリプトに渡して再度APIを叩けば正確な”screen_name”を取得することができます。

しかし、IDの構成が数値だけから英数字の組み合わせに変わってしまうと思わぬ落とし穴にまたはまってしまうので、
送信ボタン自体に埋め込む時点で文字列に変更しました。

文字列として最初から処理してしまえばTwitter側の仕様が変わっても問題ありません。
これで解決

JavaScriptで演算するときは数値の変化に気をつけていましたが、受け渡しでも気をつけておかなければならないことを見落としていました。

結論
JavaScriptを使うときの数値は本当に面倒だ