WEBサイトのValidator偏執狂
WEBサイトを制作したりするんで、HTMLやCSS、javascriptの必要最低限のエラーや警告のチェックはしている、つもり。
「W3C Markup Validation Service」https://validator.w3.org
というサイトもあるし、HTMLやCSSの構文チェックをするツールは各種いろいろある。
…なんてこと言いつつ。
エラーも警告も出ない・出さない、いってみれば100点満点のWEBサイトの必要はあるんだろうか。
たとえば、webサイトでアマゾンECSやgoogleアドセンス、あるいはtwitterやfacebookのシェアなど、よそさまのサービスを自分のサイトに組みこむことなどよくある。そして、それらのコードがすでに警告やエラーの対象となってたりする。
そのせいで、100点満点のWEBサイトにならない、だからこれらのコードは使わない、よそのサービスを組込まない、とか言いだしたら本末転倒だろう。
何のためのWEBサイトかと。
Validatorで警告もエラーもない100点満点のWEBサイトのために、本来やりたいこと見せたいものを制限してどうする、てことだ。
ふた昔前は、Validatorでエラーや警告のあるサイトはSEO的に不利だと言われていたけど、今どきはどうなんだろう。googleさまは日進月歩。metaタグのdescriptionよりbodyの文章を「解析、判断して」表示するようになったのはもう何年前のことか。あれ？昨日までmetaタグのキーワード大事じゃなかったっけ？とか、コンテンツの見出しタグ、altタグはどうだっけ？とか。
だいたい、SEOのために100点満点のきれいなHTMLあるいはCSSを頑張るより、googleさまがユーザー視点から解析の精度をあげて検索結果に適切なものを表示するようになることの方が期待できる。
必死になって100点満点を目指してる・警告もエラーもないことをセールストークにしているのを見かけることがあるんだけど、W3Cにお墨付き・認められたからといってユーザーに認められることにはならない。それで作ったサイトはユーザーにとって使いやすいのか・見やすいのか。
HTMLやCSSのエラーは確実に潰すことができるし、それで100点満点に近づくのは充実感・自己肯定感が得られるので面白いんだけど。
ユーザー視点の欠如だ。あるいはただの自己満足。
最低限、ブラウザでの表示で致命的なエラーとなるHTMLのタグの不整合のチェックはするにしても、Validatorで少しでもエラーがないようにするにしても。
そこにこだわってるヒマがあったら、コンテンツの充実や情報設計というか動線やラベリングについて検討すべきだろうと思う。
もちろん、エラーや警告が許されないものもある。上記はWEBサイトについて(念のため)
たとえば電子書籍(EPUB)の納品はシビアで、エラーはひとつでもあったらアウトだ
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» web(156)
paypalを使って電子書籍のダウンロード販売
電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。
また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。
「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
http://writing-san.blog.jp/archives/32017213.html
また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。
「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
http://netaone.com/wp/easy-digital-downloads/
集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。
ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。
てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売（その１）」
http://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売（その２）」
http://t2aki.doncha.net/?id=1277130006
今回の雑記では自サバ側のこともメモしておく。
【じぶんちでの設定】
コンテンツをサーバーの所定のフォルダにアップロード。
サーバーのデータベースにコンテンツの商品登録。ここで商品にIDを付ける。
以下3つのスクリプトを用意
・ご購入ありがとうございますページのスクリプト
・IPN受信&データベース登録用のスクリプト
・ダウンロード用スクリプト
【PayPalでの購入ボタン作成・各種設定】
「トップ」→「販売ツール」のメニューにある「売り手の設定」から
→「PayPalボタン」
[今すぐ購入]サンプルボタンあたりを雛形に「ボタンの編集」で商品名や値段などを入れる。ここではオプションの商品ID（＝データベースで決められたID）を入れるのを忘れずに。
ボタンを作ったら「コードをコピー」して自分のサイトの購入ボタンを設置したいところにコードをペーストする。
→「ウェブサイトの設定」(ウェブペイメントの設定)
・ウェブペイメントの自動復帰「オン」
・復帰URL：ご購入ありがとうございますページのURLを記入
・支払いデータ転送「オン」※IDトークンをコピーしておく
・暗号化されていないウェブペイメントの受領拒否「オフ」
・PayPalアカウントオプションサービス「オン」
・連絡先電話番号「オフ」
・エクスプレスチェックアウトの設定「いいえ」
→「即時支払い通知」(IPN)
・通知URL：IPNを受信するスクリプトのURL
・メッセージの配布：有効
→「PayPalボタンの言語コード化」
・「詳細オプション」→「UTF-8」
【PayPalとのやりとり】
ユーザーの動きは以下の3つ。
1)ユーザーがオレオレサーバーの購入ボタンをクリックすると
2)PayPalの決済ページに飛んでそこでお支払い
3)お支払いが終わるとオレオレサーバーの購入ありがとうございましたページに戻ってくる。
ユーザーのお支払い終了と同時にPayPalからオレオレサーバーに購入データが飛んでくる。
購入データは以下の2種類。
データを取得して解析するためのサンプルコードがPayPalに用意されていて、そのまんま利用させてもらう。
3)PDT(Payment Data Transfer)
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・ユーザーが購入ありがとうございますページにリダイレクトされてくる時に、トランザクションを持ってアクセスしてくる
→オレオレサーバーからPayPalへ
・トランザクションと管理ページの「支払いデータ転送」の項目に記載されているIDトークン、コマンドをPOSTでPayPalにリクエスト
→PayPalからオレオレサーバーへ
・POSTした内容が正しければ一行目に「SUCCESS」と書かれたデータを返してくる
このPDTデータは
SUCCESS
first_nameJane+Doe
lst_name=Smith
payment_status=Completed
など、1行にひとつ「ネーム＝バリュー」形式、NVP形式のデータとなっている。
※ユーザーが支払いを終えて待たずにすぐブラウザを落としたりするとデータ取得できない。購入ありがとうございますページにリダイレクトされてやってきて初めてデータのやり取りが生じる。
PDTデータ取得＆解析のサブルーチン
※HTMLデコードと文字コードをutf8にしているところ以外はサンプルコードのまんま。
PDTデータのpayer_emailやitem_nameなどを「ご購入ありがとうございます」ページの「～様」や「～をご購入いただきありがとうございました」などの個別の表示に使う。
PDTデータのitem_number(商品ID)でダウンロード商品なのか、別の商品なのかを判定して、ダウンロード商品の場合はダウンロードURLを表示する。ダウンロードURLはユーザーのemailやtransactionidなど一意のものから作成している。
4)IPN(Instant Payment Notification)
ユーザーから見える言わば表側のPDTと違って、こちらは裏側。
ユーザーがお支払いを終えると管理ページで指定したURLにデータが飛んでくるので取りこぼしがない。
PDTはユーザーに見せるご購入ありがとうございますページに使う程度で、オレオレサーバーのデータベースに購入の記録を残すためにはこちら、IPNを使う。
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・購入データが送られてくる。いわゆるWEBのフォームデータで「&」で繋がれた「ネーム＝バリュー」形式
→オレオレサーバーからPayPalへ
・送られてきた購入データにコマンドをひとつつけてPayPalにPOSTする
→PayPalからオレオレサーバーへ
・「VERIFIED」か「INVALID」か一行返ってくる。これ以外は調べる必要があるらしいが滅多になさそうだし、PayPalの管理画面で確認すれば良い。
IPNデータ取得＆解析のサブルーチン
エラーはIPNのデータをつけてメールするように。
VIRIFIED(データが正しい)場合でも以下の4点を確認する。
・支払いのステータス「payment_status」が完了「Completed」であることを確認
・すでに完了した取引の悪用防止のために「txn_id」が過去のものと重複していないことを確認
・不正アカウントに支払いされないように「receiver_email」がPayPalアカウントに登録したメールアドレスであることを確認
・価格が変更されていないか確認(商品IDなども)
確認できたらオレオレサーバーのデータベースに必要情報を登録して、ユーザーにお礼とダウンロードURLを書いたメールを送信する(自分にも同じものを送信)
※データ確認の部分やメールの部分以外はサンプルコードのまんま。
【ダウンロードについて】
ダウンロードはダウンロード用のスクリプトがファイルを返すようにしてある。
たとえば、わたしが自分だけで作ったコンテンツなんかはどうでもいいんだけど、表紙が依頼原稿だったり、アンソロジーでほかの人の原稿が入っていたりするとそうもいかない。回数や期間を無制限にするわけにはいかない。
なので、ファイルの置き場所＝URLをそのままユーザーにお知らせできない。
ダウンロード用のスクリプトを噛ませて
・ダウンロードのURLは購入者ごとに違うものを作る
・ダウンロード回数を制御する
・ダウンロード期間を制御する
といったことを仕込んだ。
また、ダウンロードごとにIPやUserAgentを記録すれば、不正なアクセスやダウンロードできない事故などの問題解決にも役立つ。
以前の雑記にも書いたように、PayPalは管理ページに記録が残ってるし取引が生じたらいちいちメールも飛んでくるので、致命的な問題にはならないはず。サポートもびっくりするというか恐縮するぐらいに厚い。
残念なことに(法律的に？)日本では単純にクレジットカードだけで支払いはできなくなった(ペイパルへのアカウント・会員登録が必須となった)けど、個人での少額決済に手軽に使えるので助かるなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
なろうをタテにしてEPUB3電子書籍でヨム
カクヨムをEPUB3の電子書籍に変換してダウンロードするスクリプトを書いたんだけど、カクヨムはR18禁止なのでR18がOKのなろうに退避するケースもあるとかないとか。
カドカワもTL(ティーンズラブ)小説があったような気がするけど、エロではない、ということかな。
てことで、なろうに上がっている小説をEPUB3に変換してダウンロードするスクリプトをでっち上げた。
ttp://ncode.syosetu.com/XXXXXXX
↑小説トップページ(?)目次ページのURLを入力すると電子書籍としてダウンロードできます。
とはいえ、なんだかなろうは商標についてのページや利用規約やガイドラインなんかを見るとどうもややこしいところのようなので(印象)、ダメっぽかったら取り下げます。悪しからずご了承くださいませ。
http://t2aki.doncha.net/tmp/narou2epub.pl
↑例によって直リンクできないフォルダなのでこちらのリンクからどうぞ。
ちなみに。
なろうを電子書籍化するサービスやアプリはすでにあるので、ニーズにあったものを探して利用してみましょう。ウチのより高機能。
「なろうを電子書籍化」WEBサービス
http://narou.nyanpass.jp/
「Narou.rb」rubyアプリ
https://github.com/whiteleaf7/narou/wiki
「AozoraEpub3」javaアプリ
http://www18.atwiki.jp/hmdev/pages/21.html
カクヨムを電子書籍に変換してダウンロードするページはこちら
http://t2aki.doncha.net/?id=1457873699
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(101) » 電子書籍(278) » perl(100) » web(156)
カクヨムをタテにしてEPUB3電子書籍でヨム
時事ネタ。
カクヨムの作品URLを入力したらEPUB3の電子書籍としてダウンロードできるようにしてみた。
カクヨムに上がっているWEB小説をEPUB3ファイルにすることで、KindleやiBooks、Kobo、Knoppy(紀伊国屋)、hontoなどの電子書籍リーダーやアプリで読むことができる。
サイトをクロールしてEPUB3にパッケージするスクリプト程度なら手元の部品の継ぎ接ぎでそれっぽいのができるので作った。
（カクヨムのHTMLの構造が変わったらそれまでだし、たぶんカドカワのことなのでそのうちEPUB3変換のクチも別メニューで出てきそうで、メンテするのも不毛なのでこれっきりの一発ネタだろう）
http://t2aki.doncha.net/tmp/kakuyomu2epub.pl
↑カクヨムを電子書籍にしてダウンロード
※直リンクできないフォルダなので、ご利用の場合はこのリンクからよろしく。
アンドロイドのスマホでダウンロードできないことがあるけど、アンドロイドアプリのFirefox（https://play.google.com/store/apps/details?id=org.mozilla.firefox&hl=ja）ならダウンロードできます。それ以外、PCやMac、iphoneなどは問題なくダウンロードできます。
カクヨムは横書きのサイトなので半角の英数字などは縦書きにしても寝転がったまま…うーん、こりゃしょうがあるまい。
(かなりテキトーなでっちあげ)
[2016/03/15 16:15:01] 追記。
連続する半角数字以外に、半角の「!?」「?!」「!!」に縦中横のスタイルを当てるようにした。
[2016/03/19 10:59:01] 追記。
それっぽい奥付生成。
完結したストーリーの本文を取りこぼすバグ修正。
なろうを電子書籍に変換してダウンロードするページはこちら
http://t2aki.doncha.net/?id=1460978141
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(101) » 電子書籍(278) » perl(100) » web(156)
ブログの立ち読みサンプルを縦書き段組にする
Kindleの無料サンプルを縦書き段組にして表示するというのをやってみて、ついでに、「はてな」などのブログ記事掲載のサンプルを縦書き段組にしてみた。
CSS3のマルチカラムは縦書きの段組には(現状)使えないので、段組の一カラムずつの塊を返す（レイアウトデザインを崩さずコントロールするためにはこの方法しかなさそうだ）
百聞は一見に如かず。
「はてな」
http://t2akii.hatenablog.com/entry/2016/02/15/182240
「HTML直書きのサンプルページ」
http://sandbox.doncha.net/sample-tategumi.html
「はてな」を例にしてみると。
その1。
ブログ記事を「編集 見たまま」で作成する。
その2。
表示させたい立ち読みサンプルを、テキストエディタ(sakuraやxyzzy、秀丸、miやcoteditorなどなど)で開いて、コピー。
その3。
「編集 見たまま」で、立ち読みサンプルをペーストする。
そうしたら「HTML編集」に切り替える。
赤い部分がコピペした立ち読みサンプル部分。
その4。
このコピペした立ち読みサンプルの冒頭の「＜p＞ 神さまに会いに行く」の「＜ｐ＞」の部分に「HTML編集」の状態で以下を記入する
赤い部分
<p id="sample-tategumi" data-cols="28" data-lines="20">
のように編集。
・data-colsは一行の字数
・data-linesは一カラムの行数
その5。
以下のコードを立ち読みサンプルの下あたりに貼り付け。
HTMLに書きこまれたテキストを縦書きにするだけなので、立ち読みテキストがグーグルさまなどの検索エンジンにちゃんと拾われるのもお得な感じになった、かも。
HTML的なことをいうと。
idがsample-tategumiの要素の中のテキストを縦書き段組にするので、pタグだけじゃなくてdivタグなんかでもOK。
…にしても、wordpressもはてなも、CMSってのは余計なお世話が多いなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
【改良版】kindleの小説無料サンプルを縦書きでブログに貼り付け
Kindleの無料サンプル、試し読みを縦書きにしてブログに貼り付けるというのを、先日やってみたんだけど。
現状のCSS3のマルチカラムは縦書きがまともじゃない。
カラムの高さが取得できなくて2段目以降がオーバーフローしてしまうことがある。親要素に高さが伝わらないので、たとえばページの最下部にありがちなフッターを乗り越えて表示したりしてしまうのだ。
またそのせいか、一段の高さと表示段数の計算がわけわかめ状態。CSSで指定した高さになっていなかったりしてうまくコントロールできない。ブラウザごとで解釈がバラバラ。
つまり、現状のCSS3のマルチカラムを使って縦書きにすると。
ページのレイアウトデザインが意図どおりコントロールできない。ブラウザが違うと一段の字数・行数が違ってくる。ということになる。
ありえなかった。
たぶん、時間が解決してくれる。そのうちCSS3のマルチカラムでも縦書きがちゃんと意図通りに表示される時代がやってくる。
でも、いったいいつになるのか、初老フリーターに残された時間は短い。
てことで、段組表示用に、字数x行数でテキストを区切ってひと塊ずつdiv要素でくるんだものを返すようにした。
CSS3のマルチカラムで起こっていた問題はこれで解決（禁足なんかの判定がバギーだけど…）
意図通りに縦書きで段組されて（＝マルチカラムで）表示されるようになった。
↑28字x20行のカラムごとに表示している。
でもこれは、CSSのマルチカラムではないので、レスポンシブというか画面の幅に合わせて柔軟に広がったりしない。N字xN行の塊が表示されるだけ。
今どきはスマホファーストでもあるので、それだとなんかアレな感じ。その場しのぎというかスマホでのアクセスの場合、表示する行数をPCの半分にするようにした。
各々一段10行表示となる。
Android
iPhone4S
http://sandbox.doncha.net/sample-kindle.html
↑表示のサンプルページはこちら
（ちなみに、無料サンプルについてくる「目次」toc は削除）
以下のコードを、縦書きでサンプルを表示させたいところに貼り付け。
1行目。
・「ASIN」の部分にサンプルを表示させたい本のASINコードを記入。
・「data-cols」が一行の字数。デフォルト28字
・「data-lines」が一段の行数。デフォルト20行
※「はてな」や「fc2」などのブログサービスでは「HTML編集」で上記のコードを貼り付ける。
現状、電子書籍をブラウザで読む・体験するのには 「BiB/i」 が最適最強。
ただ、WEBはクリックのコスト・ハードルがかなり高い。
サンプルをさらっと読んでもらいたいと思っても、クリックしなきゃ読めないのはツライものがある。前にも書いたけど、楽天のフンドシのような長いページはそれなりの意図意味がある。
ページに着地したら余計なアクション不要でサンプルが目の前に表示されている状態にしたい。
ということでごそごそいじってみた。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» Kindle(109) » KDP(62) » 電子書籍(278) » web(156) » javascript(36)
