ぼくたちのかんがえたさいきょうのi18n国家
本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一瞬で滅びそう — Masaki Hara (@qnighy) 2018年8月6日 長い前置き ソフトウェアのi18nは難しい。自文化では当たり前と思っていてハードコードしてしまった仮定が崩れて、大幅な再設計を余儀なくされるからだ。気づいて再設計できればまだ良
キャッシュサーバの効率を改善するHTTP Variantsという提案仕様 - ASnoKaze blog
HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。 この機能は、Fastly VCLの機能の標準化のようです。 少々想定している背景がわかりづらいのですが、自分なりに簡単にまとめてみる。 背景 Webにおいて、サーバはクライアントからのリクエストヘッダを見てコンテンツを出し分けています。 例えば、Accept-Languageリクエストヘッダを見てコンテンツの言語を変更しています。キャッシュサーバももちろんこのAccept-Languageを見て、それぞれ毎にコンテンツをキャッシュする必要があります。 次の例を見てみましょう 1. ブラウザは下記のHTTPリクエストを送信する GET /foo H
実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
漢数字が数字順にソートされない理由を調べてみた - give IT a try
はじめに：「なぜ漢数字は数字順に並ばない！？」 先日、こんなツイートをしたところ、結構たくさんの人にリツイートされました。（執筆時点で50件以上） 「漢数字はソートしても数字順に並ばない」という事実を生まれて初めて知った。まさかのサプライズ。 pic.twitter.com/Eqx3ltIfHs— Junichi Ito (伊藤淳一) (@jnchito) 2014年11月27日 「なぜ漢数字は数字順に並ばないのか」という問いに対して、表面的な回答をするなら「数字順に並ばないのは、数字の大きさではなく文字コード順でソートされているから」ということになります。 いや、もちろんそれはわかってるんです。 問題は「そもそもなんで数字順に文字コードを振らなかったの！？」ということです。 感覚的には「一郎、二郎、三郎」って並んでほしいじゃないですか。でも、プログラム上でソートすると「一郎、三郎、二郎」
「文字列を文字の列とみなす単純化」ってどういうこと？解説編 - 西尾泰和のはてなダイアリー
先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
新しい暗号技術
A compact zero knowledge proof to restrict message space in homomorphic encry...MITSUNARI Shigeo
Masato Kinugawa Security Blog: U+2028/2029とDOM based XSS
ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ
文字コードがEUCのページをnode.jsでスクレイピングする時の問題と解決方法(requestモジュール利用)
node.jsを使ってスクレイピングをしようと思いたってチャンレンジしたのですが、、文字コードがeucのページではまっていたのでその問題と解決方法 環境Mac OSX (Lion)node.js 0.6.15 (nave利用)まず、スクレイピングしようとするとrequestモジュールいいよ。という意見が多数あったので、requestモジュールをnpmでインストール requestモジュール mikeal/request これを使ってサンプル通りに実行するとかなり簡単にページのコンテンツが取得できました。 ただ、それは文字コードがutf-8だけでの話。。。 EUCの文字コードにあたってみると文字化けします(非utf-8ページ) 想像でutf-8で出力されているんだろうから文字コード変換すればいいよねと軽く考えたので変換をまたも検索。。 で、ここで検索するとやはり同じような状況で色々解決策が載
技術/HTTP/URLエンコードで 0x20(スペース) を "+" にすべきか "%20" にすべきか - Glamenv-Septzen.net
id: 1170 所有者: msakamoto-sf 作成日: 2013-03-23 22:18:13 カテゴリ: HTML HTTP ネットワーク [ Prev ] [ Next ] [ 技術 ] ※時間がないとか、だらだらとRFCの解説を読んでる暇が無い方は、末尾のまとめ部分だけ目を通していただければ十分かと。 URLのpath中やquery中、POSTリクエストボディ中で、0x20のスペースを、"+"に変換するのが「正しい」のか、"%20"にするのが「正しい」のか、わからなくなってきたのでちょっと調べてみました。 ただしRFCの全文を熟読してるわけではないので、言い回しや表現はもとより理解そのものが間違ってる可能性もあるので、話半分程度に参考にしてください。 "+"を使うべきか、"%20"を使うべきか、よく迷う箇所： URLのパス中 URLのクエリ中 "application/x-w
javascript - 昨日なに作った？
node.jsでメール送信する際の、エンコーディングにiconvを使用したのだけど、 変換対象文字列にISO-2022-JPに存在しない文字（①とかⅤとか）が存在する場合、 Error: EILSEQ, Illegal character sequence というエラーが出ていた。 try { var Iconv = require('iconv').Iconv; // UTF-8からISO-2022-JPへ変換 var iconv = new Iconv('UTF-8', 'ISO-2022-JP'); return iconv.convert(str).toString(); } catch (e) { console.log(str); console.log(e); throw e; } var iconv = new Iconv('UTF-8', 'ISO-2022-JP');
perl - 最速のUTF-8処理法 : 404 Blog Not Found
2013年03月04日14:45 カテゴリTipsLightweight Languages perl - 最速のUTF-8処理法 Perl Cookbook (English, Kindle Ed.) Christiansen / Torkington [邦訳: Perlクックブック] というわけで解説。 2013/03/04:Unicode::UTF8 がガチ爆速すぎる - bayashi.net encode より decode のが差が大きい感じ。encode だけだと、文字列長くなると Encode の方が速いっぽい。 まずは改めて検証してみましょう。 https://gist.github.com/dankogai/5079930 確かにその通りになっています。Unicode::UTF8はEncodeはおろかPerl組み込みのutf8::decodeより高速なのか(文字列をコピ
PaperBack
Olly, the author of OllyDbg, presents his new open source joke: PAPERBACK v1.10 Updated by Michael Mohr Download PaperBack v1.10 Download sources v1.10 PaperBack version 1.00 does not implement AES encryption properly. Specifically: a) The key used for (en|de)cryption in version 1.00 provides at most an effective key strength of less than 50 bits (and likely far less, perhaps on the order of 15-2
ハフマン符号 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "ハフマン符号" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2011年9月） ハフマン符号（ハフマンふごう、英: Huffman coding）とは、1952年にデビッド・ハフマンによって開発された符号で、文字列をはじめとするデータの可逆圧縮などに使用される[1][2]。 ほかのエントロピー符号と同様、よく出現する文字には短いビット列を、あまり出現しない文字には長いビット列を割り当てることで、メッセージ全体の符号化に使われるデータ量を削減することを狙っている。 コンパクト符号やエントロピー符号の一つ。JPEGやZIP (Deflate)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hacking with Unicode in 2016
本当はこわいエンコーディングの話 // Speaker Deck
東京Node学園#6 文字コードと Node
