nDiki : URL

URL - Uniform Resource Locator

URI escape (Perl)

によると 

 $str =~ s/(\W)/'%' . unpack('H2', $1)/eg;

と 

 $str =~ s/%([0-9A-Fa-f][0-9A-Fa-f])/pack('H2', $1)/eg;

がはやいそうです。

application/x-www-form-urlencoded でのエンコード (Perl)

同じく

によれば、 

 $str =~ s/([^\w ])/'%' . unpack('H2', $1)/eg;
 $str =~ tr/ /+/;

 $str =~ tr/+/ /;
 $str =~ s/%([0-9A-Fa-f][0-9A-Fa-f])/pack('H2', $1)/eg;

がはやいそうです。

RFC

  • RFC1738 - Uniform Resource Locators (URL).
  • RFC1808 - Relative Uniform Resource Locators.
  • RFC2368 - The mailto URL scheme.
  • RFC2396 - Uniform Resource Identifiers (URI): Generic Syntax.

記事

web

関連情報

スポンサード リンク

2018年2月12日 (月)

今日のさえずり: Google アプリのフィード上のカードを共有すると専用の Google URL Shortener で短縮された URL が渡される

2018年02月12日

[ permalink ]
[ 2月12日全て ]

2018年2月18日 (日)

ようやく nDiki に Twitterカードを実装した

書いた日記を Twitter でシェアした際に Twitter 上でグレーの地味なリンクサムネイル付きSummaryカードが出るのちょっと嫌だなぁと思ったので、そのうちと思っていた Twitterカードを対応をようやくすることにしました。

記事中の最初の画像を自動的にTwitterカードの画像に指定する案も考えたのですが、過去記事にも自動的に画像がつけられるという利点はあるものの、小さい画像など適切でないものが設定されてしまうこともあるかなと思ってそれはやめにしました。

なので記事中に [[ogpimage:URL]]と書いてあればそれを 

 <meta name="twitter:image" content="URL">

とするようにしました。あとは twitter:card と twitter:site と twitter:title もヘッダに合わせて埋め込むようにして完成。

ついでに設定した画像 URL は Open Graph protocol (OGP) の og:image にも指定して Facebook でも認識できるようにしました。

これで日記に写真を載せるモチベーションもアップしそうです。

[ permalink ]
[ 2月18日全て ]

2018年2月28日 (水)

GitHub Flavored Markdown ファイルの Web ブラウザでのプレビューに Grip を使う

「Markdown で書いているノートを Web ブラウザで見るのに MkDocs を使う」とつぶやいたら @bsdhack 氏が Grip を紹介してくれました。

さっそく試してみました。 

 $pip2 install grip

でインストールしたら Markdown ファイルを指定して Grip を起動します。 

 grip index.md

Grip が http://localhost:6419/ で Web サーバとして立ち上がるので Web ブラウザでアクセスすると index.md の HTML 変換されたものを見ることができます。なお 

 grip -b index.md

とすれば起動と同時に Web ブラウザで開いてくれます。URL でパスを指定すればそのまま同じ/サブディレクトリにある Markdown ファイルもプレビューできるので、ハイパーリンク付けをしておくことでドキュメント群をブラウジングすることもできます。なるほどお手軽で便利。 GitHub 上とほぼ同様の見慣れたデザインになるのがいいですね。

そもそも Grip は「GitHub Readme Instant Preview」で GitHub 上での表示確認のためのツールで、 GitHub の REST API を使ってレンダリング結果を生成しているので当然といえば当然だったりはします。

ただそのかわり GitHub の API を使うので

と場合によっては不便な部分があります。なお後者については GitHub Enterprise があるなら Grip でそちらを指定するとう手もあります。

GitHub に push する前にチェックしたい時はもちろん、それ以外でさっと Web ブラウザで見てみたい時にも便利なツールですね。

[ permalink ]
[ 2月28日全て ]

2018年5月10日 (木)

今日のさえずり: 「和風カツ弁当」を「和風とは?」と思いつつ食べた

2018年05月10日

[ permalink ]
[ 5月10日全て ]

2018年5月13日 (日)

妻と Google マップの場所のリストを共有

今週は妻と鎌倉にデートに行く予定。まわりたいところの共有に、今回は Google マップの場所のリストを使うことにしました。

今までこういう場合は Google マイマップを作っていました。でもメモを書いておけたりするのはいいのですが、編集が結構面倒でスマートフォン版で編集できないところが不便。Google マップの場所のリストが共有できるうようになってからまだ一度も共有していなかったので、今回はそれを利用してみることにしたという訳です。

共有用 URL を知っている人は誰でも見られるというタイプの共有形式なので、念のためリストにはプライベートな名前をつけたりしない方が安心かな。

スターをつける感覚で気になる場所をリストに追加していけるのが気軽でいいですね。

[ permalink ]
[ 5月13日全て ]

2018年8月22日 (水)

帰省 2018 で旅のしおりなどに使ったツール

今回の旅行・帰省で情報をまとめたり共有したりするのに使ったツールは以下。

nNote (ノート用の Web 日記)

今回はオープンにしても問題ないもの(タイムテーブルやスポット情報など)は、認証・共有設定無しで見てもらえる nNote に書いた。同行者に URL を伝えるだけで見てもらえるので共有が簡単。

各種サイトや Google マップ上のスポットへハイパーリンクを貼っておけば、スマートフォンからさっと確認してもらえるので便利。

Google マップの場所のリスト

5月に鎌倉に行く時 にGoogle マップの場所のリストを作って共有したら便利だったので、今回も仙台のスポット共有に。

巡る場所の候補を順番に見てもらったり、位置関係を知ってもらったり、現地で場所を確認したりするのに便利。

Evernote

えきねっとのメモなど、公開しないノート用にちょっとだけ使った。

Day One

現地での行動記録用。

まとめ

  • URL を共有するだけで見てもらえるものが一番気軽。
  • Google マップの場所の URL へのハイパーリンクをつけておくと、スマートフォンで Google Chrome から Google マップアプリを一発で開けるのが便利。
[ permalink ]
[ 8月22日全て ]

2018年8月25日 (土)

Buffer Pro Plan のサブスクリプションをキャンセル

Twitter の予約投稿で使っている Buffer を 2月11日に Awesome Plan (1,200円)にアップグレード(現 Pro Plan)して使っていたのだけれど来月は更新しないことにした。

予約投稿が10件をほとんど超えない

Pro Plan では 1ソーシャルアカウント当たり予約投稿しておける数が10件から100件に増える。写真投稿など週末にまとめて予約投稿とかできて便利だなと思っていたけれど、最近はあまり予約していないので10件でも十分。

Content Inbox は使わなくなった

Content Inbox という RSS フィードのアイテムを投稿候補としてチェックする機能も当初試してみたけれども、だんだん使わなくなった。

その他

カレンダービュー・投稿レポートは無くても困らない。 Pro Plan にしないと短縮 URL サービスを Bitly にできないけれど、これは事前に短縮してから予約投稿すれば大丈夫。

現行の Pro Plan が月15ドル(1,700円)のところを Awesome Plan の時に登録したということで月10ドル(1,200円)で使えているというのはあるのだけれども、それでもメリットが少ないのでキャンセルした方がお得だなと。

[ サブスクリプションサービス ]

[ permalink ]
[ 8月25日全て ]

2018年10月13日 (土)

Ulysses で TextBundle を使うのどうなのか調べてみた

Markdown 形式ファイルと、そこから参照されている画像ファイルを1つにまとめて管理する形式として TextBundle がある。ライティングアプリ Ulysses が対応しているのでちょっといじってみた。

TextBundle は package format と compressed format がある。 package format は macOS のパッケージの形になっていて、 textbundle という拡張子をつけたディレクトリの中に info.json と text.* (Markdown なら text.md)、それからテキストファイルから参照しているファイルを asserts/ サブディレクトリに置くという仕様である。macOS の Finder からは1つのファイルのように表示される。

TextBundle を使うメリット

メリットは以下。

  • テキストファイルと参照されている画像ファイルを一緒に管理できる(ばらけないで移動したりできる)。
  • TextBundle に対応していないテキストエディタでも text.md を簡単に開いて編集できる。

TextBundle を使うデメリット

非対応アプリケーションから使う場合にデメリットを感じる。

  • 非対応アプリからみると TextBundle 毎にディレクトリがあることになるので、ディレクトリだらけな感じになる。ドキュメント毎にディレクトリを開いて中のテキストファイルにアクセスする必要がある。
  • Markdown ファイル名が text.md 固定なので、ファイル名だけでは区別できなくなる。

Ulysses for Mac の場合

Ulysses は TextBundle に対応しているので通常の Markdown ファイルと同様1つのシートとして自然に扱える。

普段 Ulysses for Mac では Dropbox の中のディレクトリを外部フォルダとして指定して使っているので以下、外部フォルダの時の話し。

Ulysses の外部フォルダ上の Markdown ファイルに貼った画像をエディタ上でプレビューできるのは現状 TextBundle だけ。エクスポート時も TextBundle 内の画像ファイルは書き出されれるけれど、(相対パス・絶対パス問わず)ファイル名で参照しているものは書き出されない(http/https な URL で指定した画像は HTML でエクスポートする際は画像が貼られる形になるが PDF ではだめ)。Ulysses だけを使って画像を扱いたいなら TextBundle を使う以外選択がない感じだ。

Ulysses 上で TextBundle なシートを保存するたびに参照されている画像ファイルを残して他は assets/ から消されてしまう。なので assets/ の下に画像作成に使ったソース・ファイル(マインドマップファイル)を一緒に置いておくおような管理はできない。そもそもテキスト編集で間違えて画像参照を消して保存実行してしまうと、画像ファイルだって消えてしまうので、画像ファイルだってオリジナルを別で保存しておく必要がある。

TextBundle は使うのは控えた方が良さそうだ。

[ permalink ]
[ 10月13日全て ]

2018年10月14日 (日)

Marked 2 で Markdown プレビュー時に自動的に画像を探すようにした

image:/nDiki/2018/10/14/Marked-2-1200x900.png

ライティングアプリ Ulysses for Mac では画像ファイルのプレビューがいい感じじゃなかったので、 Markdown プレビューアの Marked 2 を使うことにした。

Marked 2 は相対パス指定・絶対パス指定のローカルの画像ファイルや URL で指定したネットワーク上の画像もきちんと扱ってくれるので便利だ。

画像ファイルをどこにおいておくか

さて Markdown ファイルから参照している画像ファイルをどこに置いておくか。Markedown ファイルと同じディレクトリに置くのが素朴だが以下の点で却下。

  • Markdown ファイルを別のディレクトリに移動する時に参照している画像ファイルを一緒に動かすのが面倒。
  • Markdown で書いた日別のノートファイルがたくさんあるようなディレクトリでは画像ファイルが邪魔。

別のところにまとめて置いておくのがよさそうだけれど、そうするとパス指定の問題が出てくる。ファイル移動時の参照書き換えをするは面倒なので嫌。

どうしようかなと思っていたら、 Marked 2 のプリプロセッサ機能で画像のパスを書き換える例を発見。その記事ではローカルホストでのプレビュー時とサイト公開時とでパスが違うことの解決に利用していたんだけれど、ローカルホスト上でも応用できるな。

パス指定はプリプロセッサにやらせてしまえばいいじゃない。画像のファイル名をユニークにしておき(もともとそうしている) Markdown ファイル上ではそのファイル名だけで画像参照として書く。プレビュー時に画像ファイルをローカルホスト上で検索して見つかったパスで書き換えてやれば良いなと。

さっそく Perl プログラムとしてプリプロセッサを作成。 Markdown ファイル中の画像参照があったら、Markdown ファイルのあるディレクトリレクトリ以下および指定したパス以下のディレクトリから File:Find::find で探し、見つかればそのパスに書き換えるようにしてみた。

あ、これ便利。

画像ファイルをいちいち Markdown ファイルの近くにエクスポートするとか、一緒に移動させるとかする必要なくてめちゃくちゃいいわ。

[ permalink ]
[ 10月14日全て ]

2018年10月27日 (土)

今日のさえずり: MoYu Weilong GTS2 回したらデカッてなった

2018年10月27日

[ permalink ]
[ 10月27日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.087864s / load averages: 0.56, 0.66, 0.64
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker