まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:javascript

2022 年最初のブログエントリとなります。遅ればせながら本年もよろしくお願いいたします。

今年最初のエントリは React や Angular といったフロントエンドフレームワークにまつわるネタです。最近流行りのこれらのフロントエンドフレームワークを使うことで、比較的簡単に SPA(Single Page Application) を作ることができます。SPA 化のメリット/デメリットを理解した上で作る必要があるとは思いますが、SPA 化することによる大きなメリットの1つに「Amazon S3 などのオブジェクトストレージや Github ページといった、安価かつ滅多にサービスダウンしない環境でフロントエンドのウェブホスティングができる」ことがあると思っています。

この点を少し補足しておきます。「自分が作って管理しているサービスやアプリケーションを安定運用したい」というのは誰でも思うことだと思っています。ただ現実にはこれは簡単なことではありません。サービスやアプリケーションは利用者が直接参照するフロントエンド部分に加えて、データベースなどのバックエンド部分、そしてこれらを繋ぐ API サーバーなどから成り立っていて、これら全てを安定運用するのは簡単なことではありません。特にフロントエンドや API サーバーについては最近よく耳にするコンテナオーケストレーションなどによって比較的安価に安定運用することもできるようになりました。ただフロントエンド部がアプリケーションサーバーを持たないシンプルな静的ウェブコンテンツであれば、上述したような Amazon S3 のウェブコンテンツ機能を使ったり、Github ページ機能を使うことで、滅多にサービスダウンしないウェブページとして公開するという方法もあります。現実問題として、この方法だとフロントエンドページの公開は簡単ですが、API サーバーなどのバックエンドとの通信時に CORS を考慮する必要が生じたりして、これはこれで面倒な設定も必要になるのですが、一方で「ほぼ無料」レベルの安価で利用できるウェブサーバーにしてはかなり安定しているのも事実で、用途によっては(「面倒な設定」の面倒レベルがあまり高くならないケースであれば)運用方法の考慮に含めてもいいのではないかと思っています。補足は以上。


一方、最近のウェブアプリケーション開発において IDaaS の利用ケースもよくあります(個人的にも業務で多く使っている印象です)。ログインや認証、ユーザー管理といった ID 周りの機能がマネージドサービスとして提供されていて、自分で面倒な開発をしなくても API や SDK から利用可能になる、というものです。具体的なサービスとしては AWS CognitoAuth0 などが有名どころでしょうか。IBM Cloud からも AppID という IDaaS が提供されています。

そしてフロントエンドアプリケーションと IDaaS の組み合わせというのが実は相性が悪かったりします(苦笑)。多くの IDaaS では OAuth と呼ばれるプロトコルでの認証/認可が主流となっているのですが、アプリケーションサーバーを持たない静的なフロントエンドアプリケーションでは OAuth のコールバックの仕組みとの相性が悪く、実装が非常に難しいという事情があります。その結果として、各 IDaaS ベンダーから認証専用の JavaScript SDK が提供され、それらを使って認証機能を実装することになります。IBM Cloud の AppID も専用の JavaScript SDK が用意され、React などで作ったフロントエンドに組み込むことで AppID へのログインや認証を実現できます(この SDK では PKCE と呼ばれる方法を使ってログインを実現しています)。

で、ここまでのアプリ開発方法に関する内容についてはこちらのページでも紹介されているのですが、問題はこの先にありました。この方法で作った React のフロントエンドアプリを Github ページにホスティングして運用しようとすると・・・結論としては少し特殊なリダイレクト URI の設定が必要でした。これを知らないと Github ページでの運用時にトラブルが起こりそうだと思ったので、将来の自分への備忘録の意味も含めてブログに設定内容を記載しておくことにしました。

前段部分の長いブログですが、といった背景の中で「IBM AppID の JavaScript SDK を使って作った SPA アプリを Github ページで動かす」ためのアプリ開発手順と設定内容について、順に紹介します。


【React で SPA アプリを作成する】
この部分は上述ページでも紹介されている内容ではありますが、一般的な内容でもあるので、特にコメントに色をつけずに紹介します。以下のコマンドで react-appid というフォルダに React のサンプルアプリを作成します:
$ npx create-react-app react-appid

$ cd react-appid

ここまでは普通の React アプリと同じです。ここから下で AppID の認証に対応したり、Github ページで運用する場合特有の設定を加えていきます。


【IBM AppID サービスインスタンスの準備を行う】
ここは上述ページでも触れられてはいるのですが、あまり詳しくは紹介されていないので、ここで改めて手順を紹介します。

IBM Cloud にログインして AppID サービスを作成後にインスタンスを開き、「アプリケーション」タブから「アプリケーションの追加」ボタンで対象アプリケーションを追加します。その際にアプリケーションのタイプを「単一ページ・アプリケーション」(SPA) として追加するようにしてください:
2022011301


追加したアプリケーションを選択して、内容を確認します。type の値が "singlepageapp" となっていることを確認してください。確認できたらこの中の "clientId" 値と "discoveryEndpoint" 値を後で使うことになるのでメモしておきます:
2022011303


まだ AppID にユーザーを登録していない場合はここでユーザーも登録しておきましょう。メニューの「クラウド・ディレクトリー」から「ユーザー」を選択し、「ユーザーの追加」からログイン可能なユーザー(の ID とパスワード)を登録しておきます:
2022011302


またリダイレクト URL を登録しておきましょう。「認証の管理」から「認証設定」を選択して、リダイレクト URL に http://localhost:3000/ を追加しておきます:
2022011303



IBM AppID 側で準備する内容は以上です。取得した情報を使ってアプリ開発を続けます。


【React アプリに IBM AppID モジュールを追加して、AppID のログイン機能を追加する】
ここは上述ページでも詳しく記載されている内容です。まずは IBM AppID を利用するためのライブラリを追加します:
$ npm install ibmcloud-appid-js

そしてソースコードの src/App.js をテキストエディタで開き、以下の内容に書き換えます(詳しい内容は上述ページを参照してください)。この時に太字で示している clientId の値と discoveryEndpoint の値には先程 AppID の画面で確認した clientId 値と discoveryEndpoint 値をコピペして指定してください:
import React from 'react';
import logo from './logo.svg';
import './App.css';
import AppID from 'ibmcloud-appid-js';
function App() {
  const appID = React.useMemo(() => {
    return new AppID()
  }, []);
  const [errorState, setErrorState] = React.useState(false);
  const [errorMessage, setErrorMessage] = React.useState('');
  (async () => {
    try {
      await appID.init({
        clientId: 'AppID の clientID の値',
        discoveryEndpoint: 'AppID の discoveryEndpoint の値'
      });
    } catch (e) {
      setErrorState(true);
      setErrorMessage(e.message);
    }
  })();
  const [welcomeDisplayState, setWelcomeDisplayState] = React.useState(false);
  const [loginButtonDisplayState, setLoginButtonDisplayState] = React.useState(true);
  const [userName, setUserName] = React.useState('');
  const loginAction = async () => {
    try {
      const tokens = await appID.signin();
      setErrorState(false);
      setLoginButtonDisplayState(false);
      setWelcomeDisplayState(true);
      setUserName(tokens.idTokenPayload.name);
    } catch (e) {
      setErrorState(true);
      setErrorMessage(e.message);
    }
  };
  return (
    <div  classname="App">
    <header  classname="App-header">
      <img  alt="logo" classname="App-logo" src="{logo}">
        {welcomeDisplayState && <div> Welcome {userName}! You are now authenticated.</div>}
        {loginButtonDisplayState && <button  onclick="{loginAction}" id="login" style="{{fontSize:">Login</button>}
        {errorState && <div  style="{{color:">{errorMessage}</div>}
    </header>
    </div>
  );
}
export default App;

この状態で一度動作確認します:
$ npm start

ウェブブラウザが起動して http://localhost:3000/ が開き、以下のような画面が表示されます:
2022011301


"Login" と書かれた箇所をクリックするとログイン画面がポップアップ表示されます。ここで AppID に登録済みのユーザー ID とパスワードを指定してサインインします:
2022011304


正しくログインできると先程の画面に戻り、登録したユーザーの氏名が表示とともに "You are now authenticated." と表示され、ログインが成功したことが明示されます:
2022011305


【React アプリをビルドして、SPA アプリでもログインできることを確認する】
今作成した React アプリをビルドして index.html にまとめた SPA アプリにしたあとでも AppID でログインできることを確認します。nginx などの HTTP サーバーがあればそれを使ってもいいのですが、ここでは Node.js のシンプルなウェブサーバーを使って動作確認します。以下のような内容で app.js を作成し、react-appid フォルダ直下(README.md などと同じ階層)に保存します:
var express = require( 'express' ),
    app = express();

app.use( express.static( __dirname + '/build' ) );

var port = process.env.PORT || 3000;
app.listen( port );
console.log( "server starting on " + port + " ..." );

↑ build/ フォルダをコンテキストルートにして 3000 番ポートで HTTP リクエストを待ち受けるだけのシンプルなコードです。

app.js が準備できたら、まずは一度 React コードをビルドして SPA アプリ化します:
$ npm run build

ビルドが完了すると React アプリが SPA 化されて圧縮されて build/ フォルダにまとめられますので、これを app.js を使って起動します:
$ node app

改めてウェブブラウザで http://localhost:3000/ にアクセスして同じアプリが起動していることを確認し、Login から AppID アカウントでログインできることを確認します。アプリケーション・サーバーを持たない SPA アプリでも IBM AppID を使って認証できることが確認できました:
2022011305


【React アプリをビルドした SPA アプリを Github ページでも動くように調整する】
ここまでできれば後は build/ フォルダを Github ページで公開するだけで動くんじゃないか? と思うかもしれませんが、実は期待通りに動くようになるまではいくつかの落とし穴があります。1つずつ解いていきましょう。

(1)絶対パス→相対パスへの書き換え

React の SPA アプリをただビルドしただけだと、コンテキストルート直下で動く想定のアプリになってしまいます。どういうことかというと、例えば http://localhost:3000/ とか https://xxx.xxxxxxx.com/ といったサブディレクトリを持たない GET / というリクエストに対して動くアプリになります(要はビルドで作成される index.html 内で参照される外部 CSS や JavaScript は "/" ではじまる絶対パスになっています)。一方、Github ページで動かす際は https://dotnsf.github.io/react-appid/ のようなサブディレクトリ上で動くことになります。ここがコンフリクトになってしまい、絶対パスで指定された CSS や JavaScript のロードエラーが発生してしまうのでした。これを回避するために index.html 内の該当箇所を絶対パス指定から相対パス指定に変更する必要があるのでした。

具体的にはこの下の(3)までの作業後に改めて $ npm run build を実行してから、build/index.html の以下の <head> 部分で頭に . を付けて、絶対パス指定から相対パス指定に書き換えてください:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<link rel="icon" href="./favicon.ico"/>
<meta name="viewport" content="width=device-width,initial-scale=1"/>
<meta name="theme-color" content="#000000"/>
<meta name="description" content="Web site created using create-react-app"/>
<link rel="apple-touch-icon" href="./logo192.png"/>
<link rel="manifest" href="./manifest.json"/>
<title>React App</title>
<script defer="defer" src="./static/js/main.85d3d620.js"></script>
<link href="./static/css/main.073c9b0a.css" rel="stylesheet">
</head>
<body>
<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div>
</body>
</html>



(2)回転する画像の URL を絶対指定

(1)と似た内容ですが、SPA アプリ内で表示される画像も絶対パスのままだと正しく表示されません。ただこちらは JavaScript 内で {logo} と指定されている画像なので単純に絶対パスを相対パスにすればよいという対処が使えないのでした。 まあアプリケーションとしては必須ではないので単純に画像ごと削除してしまってもいいのですが、残したい場合は Git リポジトリ上の画像 URL を直接指定する、などの方法で対処する必要があります。よくわからない人は以下の例でそのまま書き換えてください:
    :
  return (
    <div className='App'>
    <header className='App-header'>
      <img src="https://raw.githubusercontent.com/dotnsf/react-appid/main/src/logo.svg" className='App-logo' alt='logo' />
        {welcomeDisplayState && <div> Welcome {userName}! You are now authenticated.</div>}
        {loginButtonDisplayState && <button style={{fontSize: '24px', backgroundColor: 'skyblue', 
          border: 'none', cursor: 'pointer'}} id='login' onClick={loginAction}>Login</button>}
        {errorState && <div style={{color: 'red'}}>{errorMessage}</div>}
    </header>
    </div>
  );
    :


(3)デフォルトの .gitignore を変更

$ npx create-react-app コマンドで作成した React プロジェクトにははじめから .gitignore ファイルが含まれています。が、この .gitignore では /build フォルダを除外するよう記述されています。今回は build/ フォルダを Github ページで運用することが目的なので、/build フォルダが除外されてしまっては意味がありません。.gitignore ファイルを編集して、/build フォルダを含めるよう(コメントアウトするなど)してください:
  :
  :
#/build
  :
  :

(1)でも紹介しましたが、ここまでの変更を行ったら再度 SPA アプリケーションをビルドし、その後に build/index.html ファイルに対して(1)の変更を行ってください。


(4)AppID のリダイレクト URL の設定が特殊

これまではアプリケーションを http://localhost:3000/ という開発時専用の URL で実行していたので、AppID のリダイレクト URL も http://localhost:3000 だけを登録して動作確認できました。では実際に Github ページでアプリケーションを動かす際にはどのようなリダイレクト URL を指定すればいいのでしょうか? 実はここがくせ者でした。

例えば私(Github ID は dotnsf )が react-appid という github リポジトリを作って、このリポジトリを Github ページとして公開して運用しようとすると、アプリケーションの URL は以下のようになります:
 https://dotnsf.github.io/react-appid

2022011306


ということは AppID に設定するリダイレクト URL にもこの値を指定するべき・・・だと思っていたのですが、なんとリポジトリ名部分が不要で、 https://dotnsf.github.io/ を指定するのが正しい設定内容のようでした:
2022011308


この URL がリダイレクト URL として設定されていれば AppID SDK が正しく動作して、認証も正しく実行できるようになりました(自分は実はここで結構つまずきました):
2022011307


(5)build フォルダを Github ページとして公開する方法
最後に作成したプロジェクトを Github に登録して、build フォルダを Github ページで公開する方法についてです。root フォルダや docs フォルダを Github ページで公開する場合は選択肢から選ぶだけなんですが、任意のフォルダを Github ページで公開するのは少しコツが必要です。

例えば react-appid というリポジトリを使う場合は、まず Github 上でこのリポジトリを公開設定で作成します。そして普通に main リポジトリに登録します:
$ git init

$ git add .

$ git commit -m 'first commit'

$ git branch -M main

$ git remote add origin https://github.com/dotnsf/react-appid.git

$ git push -u origin main

その後、build フォルダを Github ページで公開するには以下のコマンドを実行します:
$ git subtree push --prefix build origin gh-pages

これで該当フォルダが Github ページとして公開されます。実際に以下のページはこの設定を使って公開しています:

https://dotnsf.github.io/react-appid/

2022011306


ID: username1@test.com, パスワード: password1 でログインできるので、よければ試してみてください:
2022011307


React で作成した SPA アプリケーションの認証をどうするか、という問題を IBM AppID (と SDK)で解決する方法と、ビルドした SPA アプリを Github ページで運用する場合の特殊な設定やコマンドについて紹介しました。




JavaScript でクリップボードを操作することは過去に何度かやっていたのですが、これまでは全てテキスト型の情報を扱っていて、バイナリ情報を扱ったことがありませんでした。

JavaScript でバイナリ情報をクリックボードにコピーすることができないのか? というと、そういうことはなく、とりあえず実現できそうだったので共有目的でブログを書きました。

具体的には以下のようなコードを実行することでクリップボードに画像がコピーされた状態を作ることができます。PNG 画像の情報が buffer 変数に入っている状態で、以下のコードを実行します:
  //. Canvas
  var canvas = document.getElementById( 'mycanvas' );
  if( !canvas || !canvas.getContext ){
    return false;
  }

  //. Canvas の内容を PNG 画像として取得
  var png = canvas.toDataURL( 'image/png' );
  png = png.replace( /^.*,/, '' );

  //. バイナリ変換
  var bin = atob( png );
  var buffer = new Uint8Array( bin.length );
  for( var i = 0; i < bin.length; i ++ ){
    buffer[i] = bin.charCodeAt( i );
  }
  var blob = new Blob( [buffer], { type: 'image/png' } ); //. イメージバッファから Blob を生成

  :

 try{
    navigator.clipboard.write([
      new ClipboardItem({
        'image/png': blob
      })
    ]);
  }catch( err ){
    console.log( err );
  }

最初にバイナリデータを Blob 型変数に変換して、ClipboardItem 型変数にしてから navigator.clipboard.write() を実行する、という流れです。最初のバイナリデータは HTML であれば Canvas などから取得したものを想定しています。


このコードを拙作のお絵描きアプリ MyDoodles ※にも実装してみました:
https://mydoodles.herokuapp.com/

※初回はサインアップしてアカウントを作成する必要があります。作成したアカウントでログインすることで PC やスマホでお絵描きが可能になりますが、今回はクリップボードを使う前提で紹介するので、この機能を試す場合は PC のブラウザからログインして、マウスやタッチパネルでお絵描きしてください。


線の色や太さを変えながら、適当なお絵描きをして、最後に「保存」します。保存処理の一部として、上述のクリップボードコピーが実行されます:
2021100701


保存できました。同時に画像がクリップボードにコピーされているはずです:
2021100702


そのまま画像をペーストできるアプリを開いてペースト(CTRL+V など)を実行すると、クリップボードにコピーされたお絵描き画像がペーストされます。画像は特に背景色を指定しない限りは背景が透明な状態でコピーされているので、ペーストすると透過背景の画像として表示されます:
2021100703



JavaScript でもバイナリデータをクリップボードにコピーできることが確認できました。

タイトルそのままです。なんらかの画像をコピーしてクリップボードに格納された状態から、ブラウザ画面内の <canvas> 要素内に画像データをペーストして表示する、という処理が実現できないか試してみました。

結論としてはなんとなく実現できていると思います。サンプルを公開しているのでまずは挙動を試してみてください。


PC でもスマホでも、まず対象の画像をコピーします。今回は「いらすとや」さまのこの画像を使って試してみることにします:
https://www.irasutoya.com/2021/04/blog-post_12.html

2021041402


まずは画像をコピーします。PC の場合は右クリックから「コピー」、スマホの場合は対象画像を長押しするとコピーできると思います:
2021041403


その後、こちらのページを開きます:
https://dotnsf.github.io/web_image_paste/

2021041401



表示された画面内の「ペースト」と書かれた箇所にカーソルを移動した上でペースト(貼り付け)してください(スマホの場合は「ペースト」と書かれた箇所を長押ししてペーストを選択してください):
2021041404


うまくいくと最初にコピーした画像がブラウザ画面内の矩形部分(<canvas>)のサイズに合わせてペーストされます:
2021041405


このサンプルのソースコードはこちらで公開しています:
https://github.com/dotnsf/web_image_paste

このソースコードの中で特に該当の機能を実現しているファイルが index.html です。以下、解説を加えながらこのファイルの内容を紹介します。

まず該当部分の HTML は以下のようになっています:
<div class="container">
  <div id="canvas_div">
    <div id="cdiv">
      <div id="box" contenteditable="true">
        ペースト
      </div>
      <canvas width="80%" height="60%" id="mycanvas"></canvas>
    </div>
  </div>
</div>

画面内の「ペースト」と書かれている部分の <div id="box"> 要素に contenteditable="true" という属性がついています。これによって、この要素部分はペースト可能(Ctrl+V や右クリックメニューでペーストできる)として扱うことができるようになります。単にこの部分に画像をペーストして表示できるようにするだけであれば、この HTML だけで実現できます。

問題はここでペースト処理された画像を、この <div id="box"> 内に表示するのではなく(そのままだと <div id="box"> 内に画像がペーストされて表示されてしまうので、表示しないような処理を加えた上で)代わりにすぐ下の <canvas> 要素内に表示したい、という点です。

今回のサンプルではそういった処理は JavaScript で実現しています。まず「ペースト」と書かれた <div id="box"> 要素にペースト処理が実行されたイベントをフックして、imagePaste() 関数(後述)を実行するように指示しています。加えて false を返すことでフックしたイベントをキャンセルし、通常処理(この場合は <div id="box"> へのペースト処理)が実行されないようにしています(false を返さないと、<canvas> に画像をペーストした後でも <div id="box"> 内にも画像が残ってしまうので、それを避けるための処理です):
$(function(){
  $('#box').on( "paste", function( e ){
    imagePaste( e );
    return false;
  });

  :
  :

そして imagePaste() 関数の実装がこちらです:
function imagePaste( event ){
  var blobimg = null;
  var items = ( event.clipboardData || event.originalEvent.clipboardData ).items;
  for( var i = 0; i < items.length; i ++ ){
    if( items[i].type.indexOf( "image" ) == 0 ){
      blobimg = items[i].getAsFile();
    }
  }

  if( blobimg != null ){
    var bloburl = URL.createObjectURL( blobimg );

    var canvas = document.getElementById( "mycanvas" );
    var ctx = canvas.getContext( '2d' );

    var img = new Image();
    img.src = bloburl;
    img.onload = function(){
      var sw = img.naturalWidth;
      var sh = img.naturalHeight;
      var dw = canvas.width;
      var dh = canvas.height;
      ctx.drawImage( img, 0, 0, sw, sh, 0, 0, dw, dh );
    };
  }
}

まずクリップボード内に登録されているデータを配列で取得し、その中に画像("image")が含まれているかどうかを調べます。存在している場合はそのバイナリデータを取得します。

このバイナリデータが見つかった場合は URL.createObjectURL で画像データの URL を生成して画像化し、<canvas> 内に drawImage() 関数を使って描画します。その際に画像全体の高さや幅を <canvas> 全体の高さや幅に調整して表示するので、それらの情報を取得した上でパラメータ指定しています。

これによって「ペースト」のエリアにペーストした画像データを <canvas> 内に描画し、もとの「ペースト」のエリアには描画しない、という処理が実現できました。


本当は「ペースト」のためのエリアを使わずに <canvas> だけでここに画像を直接ペーストできるようになるのが理想なんですが、実現の可否含めてその方法がわかっていません。実現方法のヒントがありましたら教えていただけると嬉しいです。

 

バックエンドの技術を使わずにウェブのフロントエンドだけで、つまり HTML と JavaScript だけで QR コードリーダーを作ることに挑戦してみました:
smartphone_qr_code


まずは完成品で実際の挙動を確認ください。PC またはスマホで(できればスマホで)こちらの URL にアクセスしてください:
https://dotnsf.github.io/web_qrcode/

2021012501



↑Github Pages で公開しているページなので、フロントエンドだけで作られていることがわかると思います。クロスオリジンな AJAX なども使ってないので、興味ある方はソースコードも確認してください。

「ファイルを選択」ボタンをクリックします。スマホの場合はカメラが起動するので QR コードを撮影してください。また PC の場合は画像選択ボックスが表示されるので、QR コードが撮影された画像を選択してください。

すると画面下部に画像が表示され、同時に画面内の QR コードが(存在していれば)解析され、解析結果の文字列データが表示されます:
2021012502


フロントエンドだけでここまでできるので、後は例えばこの結果が URL 文字列になっていれば、そのアドレスのページを開くこともできますし、テキストデータだけを読み取った上でバックエンドサーバーにデータを送信する、といったサーバーとの連携処理も容易に可能です。


【ソースコードの解説】
ソースコードはこちらで MIT ライセンスで公開しています(GitHub のウェブホスティングである Github Pages を使ってそのままサービスも公開しています):
https://github.com/dotnsf/web_qrcode

特にサービスの肝である index.html ファイルはこちらから参照いただけます。実質的にこの1ファイルだけでカメラ起動から撮影、QR コード解析まで実現しています:
https://github.com/dotnsf/web_qrcode/blob/main/index.html


まずスマホでカメラを起動するボタンの部分は以下の HTML コードで実現しています(PC ブラウザでこのボタンをクリックすると、保存済みの画像ファイルを選択するダイアログが表示されます):
<input type="file" accept="image/*" capture="camera" name="file" id="file-image"/>

type="file" で accept="image/*" capture="camera" 属性のついた <input> タグをクリックすると、カメラ内蔵機種の場合はそのカメラが起動し、撮影した画像を選択したことになります。(PCのなど)カメラ内蔵機種でない場合は普通にファイル選択画面になりますが、accept 属性により画像ファイルしか選択できません(要するにここで QR コードを撮影するか、QR コードが撮影された画像を選択することを想定しています)。

また jQuery を使った JavaScript によって以下の処理が画面ロード直後に実行されています:
var canvas = null;
var ctx = null;
$(function(){
  canvas = document.getElementById( 'mycanvas' );
  ctx = canvas.getContext( '2d' );

  var file_image = document.getElementById( 'file-image' );
  file_image.addEventListener( 'change', selectReadFile, false );
});


HTML 内下部に設置された <canvas> と、そのコンテキストを取得します(この <canvas> に画像が描画されることになりますが、その処理は後述します)。また上述の <input> タグの値が変化した時(=カメラで撮影するか、画像ファイルが選択された時)に selectReadFile() 関数が実行されるよう定義されています:
<div>
  <canvas id="mycanvas"></canvas>
</div>

したがってカメラで撮影するか画像ファイルを選択すると、以下の JavaScript コードが実行されます:
function selectReadFile( e ){
  var file = e.target.files;
  var reader = new FileReader();
  reader.onload = function(){
    readDrawImg( reader, canvas, 0, 0 );
  }
  reader.readAsDataURL( file[0] );
}

HTML5 の Filesystem API を使って撮影された画像ファイルを読み込み、その内容を上述で取得した <canvas> に描画するための関数 readDrawImg() が実行されます。つまり撮影した画像が画面内にも表示されるようになります。

readDrawImg() 関数および、この中で実行される多くの関数の中身は以下のようになっています:
function readDrawImg( reader, canvas, x, y ){
  var img = readImg( reader );
  img.onload = function(){
    var w = img.width;
    var h = img.height;
    printWidthHeight( 'src-width-height', true, w, h );

    // resize
    var resize = resizeWidthHeight( 1024, w, h );
    printWidthHeight( 'dst-width-height', resize.flag, resize.w, resize.h );
    drawImgOnCav( canvas, img, x, y, resize.w, resize.h );
  }
}

function readImg( reader ){
  var result_dataURL = reader.result;
  var img = new Image();
  img.src = result_dataURL;

  return img;
}

function drawImgOnCav( canvas, img, x, y, w, h ){
  canvas.width = w;
  canvas.height = h;
  ctx.drawImage( img, x, y, w, h );

  checkQRCode();
}

function resizeWidthHeight( target_length_px, w0, h0 ){
  var length = Math.max( w0, h0 );
  if( length <= target_length_px ){
    return({
      flag: false,
      w: w0,
      h: h0
    });
  }

  var w1;
  var h1;
  if( w0 >= h0 ){
    w1 = target_length_px;
    h1 = h0 * target_length_px / w0;
  }else{
    w1 = w0 * target_length_px / h0;
    h1 = target_length_px;
  }

  return({
    flag: true,
    w: parseInt( w1 ),
    h: parseInt( h1 )
  });
}

function printWidthHeight( width_height_id, flag, w, h ){
  var wh = document.getElementById( width_height_id );
  wh.innerHTML = '幅: ' + w + ', 高さ: ' + h;
}

まず readImg() 関数の中で Filesystem API を用いて画像ファイルを読み込み、その結果を Image オブジェクトの src 属性に代入します(これで Image オブジェクトを drawImgOnCav() 関数で <canvas> に表示すると読み込んだ画像が表示されます)。またこの結果から画像の幅および高さを取得して、画面内に元画像のサイズとして表示されます。

drawImgOnCav() 関数の最後に checkQRCode() 関数が実行されています。画像の <canvas> への描画終了後にこの関数が実行され、画像に QR コードが写っていたらその内容を解析して、データを取り出します:
function checkQRCode(){
  var imageData = ctx.getImageData( 0, 0, canvas.width, canvas.height );
  var code = jsQR( imageData.data, canvas.width, canvas.height );
  if( code ){
    //console.log( code );
    alert( code.data );
  }else{
    alert( "No QR Code found." );
  }
}

具体的にはコンテキスト変数(ctx)から getImageData() 関数でイメージデータを取得し、その結果を jsQR を使って解析します。ややこしそうな QR コードの解析部分は実はライブラリによって一瞬で実現できてしまっています。jSQR バンザイ!

正しく QR コードが解析できた場合は解析結果の文字列(code.data)を alert() 関数で画面に表示し、解析できなかった場合は "No QR Code found." と表示される、という一連の処理が定義されています。


今回の処理では QR コードが正しく解析でした場合はそのまま表示しているだけですが、これが URL であればロケーションに指定してジャンプしてもよし、テキストなどのデータであればバックエンドの API にポストしてもよし、というわけで取り出したデータの使いみちは alert() の代わりに記述することで、自由に応用できると思います。


というわけで、Filesystem API と jsQR と <input> タグのカメラ拡張を使うことで、ウェブのフロントエンド技術だけで QR コードリーダーが実現できました。


JavaScript である程度プログラムを書いていると1度はハマることになるタイムゾーンの扱いについての自分メモです。
travel_world_jisa



【タイムゾーンとは?】
地球は丸くて、1日は24時間です。ある地点で朝を迎えた時、別のある地点では昼になっていて、更に別のある地点では夜だったりします。同じ瞬間でも時間や日付が異なるわけです。普通はあまり気にしなくていいのですが、「いま何時?」の質問に答えるには「どの地点での話か?」を明確にする必要があります。

この「どの地点での日付の話か?」を地域ごとに定義したものが「タイムゾーン」です。世界標準では GMT と呼ばれる、イギリスのグリニッジ天文台を通過する経線を使います。日本にはタイムゾーンは1つしか存在せず、兵庫県の明石市を通過する東経 135 度の経線のもの(世界標準時よりも9時間早いもの)を「日本標準時」として使います。つまり厳密には日本の東と西では日没時間などは異なりますが、全て「時計は明石市を基準に計測されるものを使う」ことになっています。横に広い国の場合はタイムゾーンが複数存在します。例えばアメリカの場合は「アメリカ東部標準時」、「アメリカ中部標準時」、「アメリカ山地標準時」、「アメリカ太平洋標準時」、「アラスカ標準時」、「ハワイ・アリューシャン標準時」と6つの標準時が存在します(国によってサマータイムとかもありますが、話が更にややこしくなるのでここでは無視します)。例えばあるイベントなども「東部標準時だと午後8時から、太平洋標準時だと午後5時からスタート」のようになります。


【タイムスタンプとは?】
タイムゾーンと少し似た言葉ですが、時間に関係するという以外は全く意味の異なる用語です。タイムスタンプ(UNIX タイムスタンプ)は「ある瞬間を整数で表したもの」です。より正確にはある瞬間が「世界標準時 1970 年 1 月 1 日午前零時から何ミリ秒経過しているか、を整数で表したもの」です。ちなみに日本時間での 2021 年 1 月 22 日午前10時40分40秒ごろに一度計測してみたところ、タイムスタンプの値は 1611279640693 という数値でした。単位はミリ秒なので、ここから1秒経過するごとに 1000 ずつ増えて、1秒さかのぼるごとに 1000 ずつ減っていくことになります。

このタイムスタンプ自体はタイムゾーンの影響を受けません。つまり上述の 1611279640693 という数字は「日本では 2021 年 1 月 22 日午前10時40分40秒(と 0.693 秒)」を示す値であって、別のタイムゾーンだと別の日時(例えばロンドンだと 2021 年 1 月 22 日午前1時40分40秒ごろ)になります。

ソフトウェア・アプリケーションを開発する際に、データの入力日時や更新日時を記録することがありますが、一般的には '2021-01-22 10:40:40' のような日時の文字列では記録せず、タイムスタンプ値を使って記録することが多いです(特にこのシステムが世界中で使われる場合、日時は日本時間として扱われない可能性があるので、後からどのタイムゾーンにでも変換できるようタイムスタンプとして保存するのがよい、とされています)。


【タイムスタンプのタイムゾーン問題】
さて、このようにシステム上において日時はタイムスタンプとして記録されることが多いのですが、一方で画面に表示する際にはタイムスタンプを日時に変換した上で表示されることがほとんどです( 1611279640693 という数字だけを見ても、何年何月何日の何時何分何秒なのか全くわからないので)。

このタイムスタンプから日時文字列への変換を JavaScript で行う場合、何通りかの方法がありますが、例えば以下のような方法が考えられます:
var timestamp = 1611279640693;      //. タイムスタンプ値
var dt = new Date( timestamp );     //. Date オブジェクトに変換
var h = dt.getHours();              //. 時
var m = dt.getMinutes();            //. 分
var s = dt.getSeconds();            //. 秒

var hms = h + ':' + m + ':' + s;    //. 時刻を H:M:S 形式の文字列に変換
   :

タイムスタンプの値を指定して Date オブジェクトを作成し、Date オブジェクトのメソッドを使って時、分、秒の情報をそれぞれ取り出してから H:M:S とコロン区切りの文字列に変換する、という方法です。この例でのタイムスタンプ値は上述のものなので、この結果 hms 変数には 10:40:40 という文字列が代入される、、、 と思われます。

ところが実際に実行してみると、そのようになる場合とならない場合があります。実行環境によって結果が異なってしまうのでした。このならない場合の原因こそがタイムゾーンの問題です。

上述のように 1611279640693 は日本時間で「2021 年 1 月 22 日午前10時40分40秒ごろ」を示すタイムスタンプでした。なので日本時間で動くシステムであれば、この JavaScript の実行結果は "10:40:40" という文字列になるはずです。問題はそのシステムが日本時間で動いているとは限らないことにあります。つまり「日本から使う」想定はできたとしても、そのシステムそのものが「日本にある」とは限らず、日本時間とは別のタイムゾーンが設定されて動いている可能性があるのです。例えばロンドンにあるサーバーで、ロンドンのタイムゾーンが設定されて動いている場合のこの処理結果は "01:40:40" と表示されてしまうことになります(ロンドンタイムゾーンの時間になってしまうので)。同じ日であればともかく、条件によっては別の日に入力されたデータとして扱われる可能性もあります。特に昨今はクラウドサーバーを利用する機会が多く、そのサーバーは日本にはないどころか、「サーバーインスタンスがどこで動いているのかよく分からない」状態で使っていることもあるでしょう。PaaS やコンテナ環境によっては(アプリケーション側からは)サーバーのタイムゾーン設定を変えることができないことも考えられます。


【JavaScript でのタイムゾーン問題】
ここまでは JavaScript に限らず、タイムスタンプを記録している以上はどのプログラミング言語でも起こりうる問題です。JavaScript だと話がもう少しややこしくなります。

アプリケーションが動いているサーバーのタイムゾーン設定が日本とは限らないとわかったとして、ではどのようにして日付時刻を日本時間で表示すればよいでしょうか?

例えばプログラム内でサーバーのタイムゾーン設定を異なる設定(例えば「日本」)に変更することができるのであれば、システム内のタイムスタンプ値を Date オブジェクトに変更し、「日本時間での」日時を取得することができるようになります。また現在のサーバーのタイムゾーン設定を調べることができれば、その値から日本との時差を計算できるので、タイムスタンプ値に時差時間ぶんの数値を加えたり、引いたりすることで、関数実行結果が日本時間のものになるよう調整することもできます。

一般的には前者の方法が使われます。例えばタイムゾーン設定を変更するための setTimezoneOffset() のような関数を使って強制的に日本時間で計算できるようにできればいいのです。が、JavaScript にはこのような関数が用意されていません。つまり JavaScript では前者の方法は使えないのです。

したがって JavaScript では後者の方法を使う必要があります。JavaScript には setTimezoneOffset() 関数は存在していないのですが、設定値を取得するための getTimezoneOffset() 関数は存在しています。例えばこのような感じで使います:
var timestamp = 1611279640693;      //. タイムスタンプ値
var dt = new Date();                //. Date オブジェクトを作成

var tz = dt.getTimezoneOffset();    //. サーバーで設定されているタイムゾーンの世界標準時からの時差(分)
tz = ( tz + 540 ) * 60 * 1000;      //. 日本時間との時差(9時間=540分)を計算し、ミリ秒単位に変換

dt = new Date( timestamp + tz );    //. 時差を調整した上でタイムスタンプ値を Date オブジェクトに変換

var h = dt.getHours();              //. 時
var m = dt.getMinutes();            //. 分
var s = dt.getSeconds();            //. 秒

var hms = h + ':' + m + ':' + s;    //. 時刻を H:M:S 形式の文字列に変換
   :


これでサーバーがどこでどのようなタイムゾーン設定で動いていても、常に日本時間での文字列に変換することができるようになります。


もちろん、このような不便で面倒な方法を使わなければならないというわけではなく、moment などの外部ライブラリを使うことでもう少し楽に扱うことができるようになります。

とはいえ、この事情を理解してないと原因調査も回避するのも難しいと思ってます。というわけでの自分メモでした。


このページのトップヘ