外部印刷プログラムに渡すためのQRコードを生成
Opened this issue · 8 comments
例えば、
- 日付：18日に、
- レース番号：第1レースで行われる、
- レース名：「新馬戦 新馬限定 400 丙級 定量」に、
- 馬券式別：単勝で、
- 馬番：1番の、
- 馬名：「デバッグアイシテル」を、
- 金額：「10000Ken」（Kenは通貨単位）
で購入したときに、次のようなCSVデータを格納したQRコードを生成する機能が欲しい。
18,1,新馬戦 新馬限定,４００ 丙級 定量,WIN,1,デバッグアイシテル,10000
現在のところ考えている仕様
- 日付は、18, 19, 20のいずれかです。
- レース番号は99以下の正の整数です。
- レース名は2行ありますので、行ごとにカンマで区切って格納してください。一行は 0文字以上 12文字以下の全角文字です。
- 馬券式別は現在のところ単勝のみで、その場合は"WIN"を格納してください。後ほど他の式別が出てきたら考えます。
- 馬番は99以下の正の整数です。
- 馬名は9文字までの全角カタカナです。
- 金額は1以上999999以下の正の整数です。
何か意見などがあればその旨お願いします。
レース名は必ず2行あるものなのでしょうか。
レース名が2行にならない場合は、どちらかを空にしても大丈夫です。
どちらが空になっても大丈夫な作りにはなっています。
例えば、
- 日付：19日に、
- レース番号：第3レースで行われる、
- レース名：「○○部宣伝特別」に、
- 馬券式別：単勝で、
- 馬番：1番の、
- 馬名：「デバッグアイシテル」を、
- 金額：「10000Ken」（Kenは通貨単位）
で購入したときに、次のようなCSVデータを格納したQRコードを生成すれば大丈夫です。
19,3,○○部宣伝特別,,WIN,1,デバッグアイシテル,10000
レース名をどこで区切るのが適当なのかを考えないといけないのではないかというのがあります。
レース名は必ずしも新馬戦のような接頭辞を持っている訳ではないですし持っていたといてもルールベースで区切るのが面倒そうという懸念があります
購入したときに、次のようなCSVデータを格納したQRコードを生成する機能が欲しい
とありますが、新しい機能にはどのようなリクエストを投げることを想定していますか？
レース名をどこで区切るのが適当なのかを考えないといけないのではないかというのがあります。
ルールベースで区切るのが面倒そう
おっしゃる通りだと考えています。
一応、レース名を区切ることについて、次のようなアルゴリズムを考えています。
- レース名が12文字以下であれば、区切らない。
- レース名が12文字以上で、かつ半角スペースがあれば、半角スペースのところで区切る。
- 半角スペースがなければ、次のようなアルゴリズムを走らせ、区切り位置を探す。
- 最初の全角スペースで区切る。
- 区切ったデータのうち、どちらかが12文字を超えた場合は、その区切り位置に対して、0ポイントとする。
- そうでなければ、区切った、「1行目と2行目の文字数の差」を調べる。
その区切り位置に対して、(12 - 「1行目と2行目の文字数の差」)ポイントを与える。 - 以下、次の全角スペース、その次の全角スペース、…、に対し、上記 ii と iii を行い、一番ポイントが高い区切り位置を採用する。
- 全角スペースがない場合、あるいは 3 ですべて0ポイントとなった場合、12文字で強制的に改行する。
例:
新馬戦 新馬限定 ４００ 丙級 定量 の場合、 3 のアルゴリズムの結果は次のようになります。
| 区切り候補 | 1行目データ | 2行目データ | ポイント |
|---|---|---|---|
| 1 | 新馬戦 |
新馬限定 ４００ 丙級 定量 |
0ポイント(2行目が12文字を超えているから) |
| 2 | 新馬戦 新馬限定 |
４００ 丙級 定量 |
12 - abs(8 - 9) =11ポイント |
| 3 | 新馬戦 新馬限定 ４００ |
丙級 定量 |
12 - abs(12 - 5) =5ポイント |
| 4 | 新馬戦 新馬限定 ４００ 丙級 |
定量 |
0ポイント(1行目が12文字を超えているから) |
→区切り候補2番： 新馬戦 新馬限定 、 ４００ 丙級 定量 を採用
このアルゴリズムをQR発行側で持たせるのか、あるいは印刷プログラム側で持たせるのかは検討中です。意見があれば教えてください。
印刷プログラム側で持たせると、QRに格納するCSVデータが若干変わることになるかと思います。
このアルゴリズムをQR発行側で持たせるのか、あるいは印刷プログラム側で持たせるのかは検討中です。
QRコード生成サービスに対してどのようなリクエストを送るのかによると思います。例えばレースIDとユーザIDを渡したら返答としてレースの色々が含まれたQRコードが返ってくるような仕様ならばアルゴリズムはQR発行側で実装するべきであると考えます。
しかし新規開発するサービスに対し19,3,○○部宣伝特別,,WIN,1,デバッグアイシテル,10000のようなCSVを送るだけであるならば、区切りは印刷サービス側でやっていただくと良いと思います。（このようにするとQRコード生成サービスはQRコードを生成することだけに注力できる。）
今のところどのようなリクエストを送ることを想定していますか。
今のところどのようなリクエストを送ることを想定していますか。
返事が遅くなりすみません。
そちら側のサイト上の、投票内容を確認できる画面で、投票内容一つ一つに対してQRコードを生成できるボタンを押すと、QRコードが生成できる、ということが望ましいです。
回答になっていなかったらすみません。
投票ページにQRコード生成を実装するということですね。
となればバックエンドで生成するというよりはフロントエンドで投票ページ作成時に一緒に作成してもらったほうがよさそうです。
@hutinoatari できそうです？