en30の投稿 - Crieit

LINE Messaging APIの使い始めで混乱した概念色々

2018-10-25T18:31:17+09:00

LINEのMessaging APIを使い始めるにあたって、プログラミング以前の管理関係の概念で混乱したのでまとめます。

ボットを作る前に

概要

主な登場人物は

プロバイダ
チャネル
LINE@アカウント

で、それぞれの役割と関係は

開発者は複数のプロバイダを持つことができる
1プロバイダは複数ボットを管理するチームや会社のような単位。複数チャネルを持つことができる。
1ボットは1チャネルと1LINE@アカウントのセット
- Messaging API等技術的な部分に関わる情報はチャネル
- アカウント周りやMessaging APIを利用しない手作業でのメッセージ送信等に関わる情報はLINE@アカウント

となっているようです。

僕はMessaging APIを使う上でLINE@アカウントという概念の必要性がわからず混乱したのですが、元々店舗用等手動で管理するLINEアカウントとしてLINE@アカウントがあり、そこにMessaging APIが建て増しされたのかな？と想定すると理解し易くなった気がします。

管理

プロバイダとチャネルの管理はLINE developersのコンソール
LINE@アカウントの管理はLINE@ MANAGER

で管理します。

複数管理者がいる場合の権限周りも、プロバイダ、チャネル、LINE@アカウントそれぞれ独立しています。例えば、プロバイダの権限を与えても属するチャネルの権限は与えられらない、チャネルの権限を与えてもLINE@アカウントの権限は与えられない、という形です。

実際にボットを作るまで

Messaging APIを利用したボットを作成するには2ルートあるようです。

ルート1

アカウントの作成フォームからLINE@アカウントを作る
https://admin-official.line.me/{id}/bot-api/setting からAPI利用の設定をする
- プロバイダの設定/作成
- チャネルの作成

こちらは既にLINE@アカウントを持っていた人用に作られた道なのではないかなと想定しています。なので、新たに作る場合は以下のルート2が良いと思います。

ルート2（オススメ）

LINE developersのコンソール上で

プロバイダを作る
チャネルを作る

チャネルを作ると自動でLINE@アカウントができます。

僕はドキュメントの

Messaging APIを利用するには、LINE@アカウントが必要です。LINE@アカウントとは、LINEボットのためのLINEアカウントです。

というのを読んで勘違いしてしまったのですが、こちらの場合LINE@アカウントを事前に作成する必要はありません。

その他注意点

一度Developer Trialプランで作ると他のプランへは変更できない

よく見るとプランの説明にも書いてありました。

LINE developersのチャネル管理ページ上にはプランの「変更はこちら」というリンクがあるのですが、LINE@ MANAGERに飛ばされて「ログイン中のLINEアカウントでは購入できません。」と表示されてどうしたらいいのかわかりませんでした。

チャネル作成時にはDeveloper Trialsかフリーしか選べませんが、フリーを選んだ場合には作成後にLINE@ MANAGERでプロ（API）プラン等に変更することができます。

名前は7日間変更できないのでDeveloper Trialsでテスト用のチャネルを作る場合には名前に"（テスト）"などを入れておくと、本番用のチャネルを作ったときに一覧で区別しやすいと思います。

認証済みアカウントの申請はLINE@ MANAGERからでもできる

Messaging APIでグループやトークルーム関係のAPIを使うには認証済みアカウントである必要があるので、そういった機能を使いたい場合には認証済みアカウントの申請をしたくなるでしょう。

よくある質問では

※すでにご利用中の一般アカウントを認証済みアカウントへ申請する場合は、LINE@アプリからのみ可能です

とあるのでLINE@アプリを入れてみたのですが、チャネル作成時にできたLINE@アカウントを管理することができませんでした。作り直しかと思ったのですが、LINE@ MANAGERのアカウント設定から申請できました。

おわりに

以上です。
LINE Messaging APIはコストが低く開発できながら、面白い使い方が色々できそうです。
この記事がスムーズに開発に入る助けになったら幸いです。

HTMLの文字コード決定プロセス

2018-09-27T15:16:50+09:00

スクレイピングしていたら文字化けしているものがあったので、HTTPでやりとりされるHTMLの文字コード判定が、どのようなプロセスを経て行われているのか調べてみました。

HTTPでやりとりするHTMLでの文字コード

基本的には以下の情報を見ていくようです。

BOM
HTTPのContent-Typeヘッダ
HTMLのmetaタグ
- charset属性
- http-equiv="Content-Type"なもののcontent属性

参考: https://www.w3.org/International/questions/qa-html-encoding-declarations.ja

axiosの場合

元々はnodeでaxiosを使っていて困った部分だったので、axiosで文字コードを考慮してどう処理するかをTypeScriptで書いていきます。

axiosはデフォルトでは上の情報はどれも利用されずにutf-8決め打ちでデコードされてしまいます。なのでoptionにresponseType: 'arraybuffer'を渡しresponse.dataをBufferとして受け取って処理していきます。

最終目標は

import axios from 'axios';
import iconv = require('iconv-lite');
import * as charset from './charset';

(async () => {
    const response = await axios.get(url, { responseType: 'arraybuffer' });
    const body = iconv.decode(response.data, charset.detect(response));
})()

のように使えるcharset.detectを実装することです。

各判定処理ごとに関数にして、決定できなかった場合にはutf-8にフォールバックするようにします。

import { AxiosResponse } from 'axios';

type Charset = string;
type IntermediateResult = Charset | null;

export const detect = (res: AxiosResponse): Charset =>
    fromBOM(res.data) ||
    fromHeader(res.headers["content-type"]) ||
    fromMetaTag(res.data) ||
    Charset.UTF8;

Charsetはきちんとやるなら https://www.iana.org/assignments/character-sets/character-sets.xhtml にあるもののunion typeとかstring enumsとかの方が良いのかもしれません。

BOM

BOMはByte Order Markで先頭数バイトを特定のパターンにすることで、ユニコードであることとそのエンコーディング、エンディアンを示すものです。
https://en.wikipedia.org/wiki/Byte_order_mark#Byte_order_marks_by_encoding から持ってきています。

// to assert elements as tuple (inferred Array)
const bomify = ([c, bytes]) => ([c, Buffer.from(bytes)] as [Charset, Buffer]);
const BOMS: ReadonlyMap = new Map([
    ['utf-8',      [0xEF, 0xBB, 0xBF]],
    ['utf-16be',   [0xFE, 0xFF]],
    ['utf-16le',   [0xFF, 0xFE]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x38]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x39]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x2B]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x3F]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x38, 0x2D]],
    ['utf-1',      [0xF7, 0x64, 0x4C]],
    ['utf-ebcdic', [0xDD, 0x73, 0x66, 0x73]],
    ['scsu',       [0x0E, 0xFE, 0xFF]],
    ['bocu-1',     [0xFB, 0xEE, 0x28]],
    ['gb-18030',   [0x84, 0x31, 0x95, 0x33]],
].map(bomify));

export const fromBOM = (buf): IntermediateResult => {
    const startsWith = (bom) =>
        buf.slice(0, bom.length).equals(bom)
    for (let [charset, bom] of BOMS) {
        if (startsWith(bom)) return charset;
    }
    return null;
}

Content-Type Header

Content-TypeヘッダのフォーマットはRFC 7231のSection 3.1.1.5で決められています。
それに基づいて実装されているjshttp/content-typeを利用します。

import contentType = require('content-type');
export const fromHeader = (ctype): IntermediateResult => {
    const res = contentType.parse(ctype);
    return res.parameters.charset || null;
}

metaタグ

Bufferをasciiにデコードして

metaタグのcharset属性
http-equiv="Content-Type"なmetaタグのcontent属性

をcheerioを使って探します。

import cheerio = require('cheerio');
export const fromMetaTag = (buf): DetectionResult => {
    const $ = cheerio.load(buf.toString('ascii'));
    let res = $('meta[charset]').attr('charset');
    if (res) return res;
    res = $('meta[http-equiv="Content-Type"]').attr('content');
    if (res) return fromHeader(res);
    return null;
}

まとめ

以上です。全体像を貼っておきます。

import { AxiosResponse } from 'axios';
import contentType = require('content-type');
import cheerio = require('cheerio');

type Charset = string;
type IntermediateResult = Charset | null;

// to assert elements as tuple (inferred Array)
const bomify = ([c, bytes]) => ([c, Buffer.from(bytes)] as [Charset, Buffer]);
const BOMS: ReadonlyMap = new Map([
    ['utf-8', [0xEF, 0xBB, 0xBF]],
    ['utf-16be', [0xFE, 0xFF]],
    ['utf-16le', [0xFF, 0xFE]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x38]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x39]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x2B]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x3F]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x38, 0x2D]],
    ['utf-1', [0xF7, 0x64, 0x4C]],
    ['utf-ebcdic', [0xDD, 0x73, 0x66, 0x73]],
    ['scsu', [0x0E, 0xFE, 0xFF]],
    ['bocu-1', [0xFB, 0xEE, 0x28]],
    ['gb-18030', [0x84, 0x31, 0x95, 0x33]],
].map(bomify));

export const fromBOM = (buf): IntermediateResult => {
    const startsWith = (bom) =>
        buf.slice(0, bom.length).equals(bom)
    for (let [charset, bom] of BOMS) {
        if (startsWith(bom)) return charset;
    }
    return null;
}

export const fromHeader = (ctype): IntermediateResult => {
    const res = contentType.parse(ctype);
    return res.parameters.charset || null;
}

export const fromMetaTag = (buf): IntermediateResult => {
    const $ = cheerio.load(buf.toString('ascii'));
    let res = $('meta[charset]').attr('charset');
    if (res) return res;
    res = $('meta[http-equiv="Content-Type"]').attr('content');
    if (res) return fromHeader(res);
    return null;
}

export const detect = (res: AxiosResponse): Charset =>
    fromBOM(res.data) ||
    fromHeader(res.headers["content-type"]) ||
    fromMetaTag(res.data) ||
    'utf-8';

最後に

僕は普段主にRubyを使っているので、Rubyの場合どうなのかも気になって少し調べてみたのですが、標準ライブラリのNet::HTTPでContent-TypeをハンドルすべきかについてのIssueがありました。

現実的には複数の方法で違う文字コードとして指定されていたり、実際使われているものと違ったりということもあるようで、絶対に信用できるメタデータというわけではないようです。

頻度から分類するアプローチもあるようで、現実的にはこちらの方がうまく動くかもしれません。
runk/node-chardet
データがあれば機械学習の実験課題としてちょうど良さそうですね。

最初は雑な正規表現で書いていたのですが、記事を書いているうちに正しいフォーマットはどうなのか気になってRFCを見にいったりして結構勉強になりました。全部utf-8だと嬉しいですね。