SSTtechlog 01 Javaと文字コード | SST 株式会社セキュアスカイ・テクノロジー
illustrations by あおい海月 SSTではWebアプリケーションの脆弱性診断サービスを提供しており、診断時には診断対象のWebアプリケーションに対して擬似的な攻撃リクエストを送信し、SQLインジェクションやXSSに代表されるような脆弱性の有無を確認します。 診断時には、多様なパターンの攻撃リクエストを送信するために、Java言語で開発している専用のソフトウェアを使っています。 こうした脆弱性診断に用いるソフトウェアを開発するためにはいくつか注意点があります。 今回はその注意点の一つである、Javaでの文字コードの扱いについて、特に文字コードが不明なデータをJavaのString型として扱うためのテクニックを紹介したいと思います。 ▲一番上に戻る 以上のように、何かしら文字列をファイルや外部システムとやりとりしたい時は、必ず文字コードを意識することになります。 特に脆弱性診断に
Unicode正規化 用語の混乱について 第4.2版 – ものかの
初版 2010/4/5 第2版 2013/5/10 誤解を修正。全面的に書き直し。 第3版 2014/7/13 なるべく分かりやすく全面的に書き直し。 第4版 2015/5/20 さらに分かりやすく全面的に書き直し。 第4.1版 2015/5/27 まだ分かりにくいと不評なので書き直し。 第4.2版 2015/5/27 さらに分かりやすく調整。 Unicode正規化の考え方自体はとてもシンプルです。でも、よく知ろうとしていろいろ調べると、用語がハイコンテキストすぎて、混乱してワケがわからなくなります。日本で一般的に見られる用語を図にしてみましょう。 混乱するのはどこだと思いますか？ “合成済み文字” と “合成文字” の２か所です。どちらも言葉として同じ意味です。それなのに、異なった状態を表す用語として無理矢理に使い分けようとしています。ここから、以下のような奇妙な文章ができあがります。
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
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のときのデフォルト
７.２ ASCII の NUL と DEL の本来の意味 - 文字コードに関する覚え書きと実験
文字コードについて調べたことや実験したこと， テストプログラム，データファイルなどを随時掲載する予定です． ただし筆者の理解不足や誤解により誤りがあるかもしれませんので， ご利用は自己責任で． このページの主な更新は Blog でお知らせします． 表示確認ブラウザ：FireFox 22.0，IE8． ０．目次 シフトJIS Shift_JIS と Windows-31J (CP932) の違い シフトJIS ２バイト文字の判定 謎の検索ワード集 (シフトJIS編) 「Shift_JIS(SJIS，Windows-31J，CP932) ３バイト文字」 「Shift_JIS(SJIS，Windows-31J，CP932) サロゲート(ペア)」 「UTF-8 4バイト文字 Shift_JIS(SJIS，Windows-31J，CP932) 変換」 「Unicode(UTF-8，UTF-16) か
ASCIIコードの秘密 - ザリガニが見ていた...。
本当はエスケープシーケンスのことを調べていたのだが、その前にASCIIコードについて調べることになってしまった...。文字コードの基本として知っているつもりだったASCIIコードについて、あらためて見直してみると、実は本当の意味をよく分かっていなかったことに気づいた。 ASCIIコード表 ASCIIコードは、7ビット（2進数7桁）の文字コードであり、全部で128のコードが定義されている。 最も基本的な文字コードであり、その他多くの文字コードはこのASCIIコードと互換性を維持している。 00 10 20 30 40 50 60 70 00 NUL DLE SP 0 @ P ` p 01 SOH DC1 ! 1 A Q a q 02 STX DC2 " 2 B R b r 03 ETX DC3 # 3 C S c s 04 EOT DC4 $ 4 D T d t 05 ENQ NAK % 5
漢数字が数字順にソートされない理由を調べてみた - give IT a try
はじめに：「なぜ漢数字は数字順に並ばない！？」 先日、こんなツイートをしたところ、結構たくさんの人にリツイートされました。（執筆時点で50件以上） 「漢数字はソートしても数字順に並ばない」という事実を生まれて初めて知った。まさかのサプライズ。 pic.twitter.com/Eqx3ltIfHs— Junichi Ito (伊藤淳一) (@jnchito) 2014年11月27日 「なぜ漢数字は数字順に並ばないのか」という問いに対して、表面的な回答をするなら「数字順に並ばないのは、数字の大きさではなく文字コード順でソートされているから」ということになります。 いや、もちろんそれはわかってるんです。 問題は「そもそもなんで数字順に文字コードを振らなかったの！？」ということです。 感覚的には「一郎、二郎、三郎」って並んでほしいじゃないですか。でも、プログラム上でソートすると「一郎、三郎、二郎」
「文字列」について - 2014-11-07 - はてなるせだいあり
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
Macの濁点問題を解決するPython unicodedataモジュール - ikeikeikeike's unk blog.
日本語のURLを使いたいんです 最近Scrapyで採取したゴミをMongoDB※1(笑) に入れておき、その後TinkererでブログにしてS3へアップロードする一連のスクリプトを書いて、ゴミサイトを何個も作りまくってるんですけど Tinkererで生成したtag list, tag cloudにUnicode文字も含めるカスタマイズをしたのですが、その後頻繁にS3で404が発生する現象が起きていたので調べていたのです、そしたらなにやらUTF-8関連のきな臭い問題のようでした UTF-8-MAC 使用している環境がMacなものでUTF-8-MAC問題が発生していました。 (この問題についてはこちらを参照) 説明は省きますが修正するにはUTF-8-MACからUTF-8に変換すれば良いみたいです。普通この際iconvを使うのが一般的思いますが今回は一連のゴミ採集スクリプトの言語がPythonな
文字コード地獄秘話 第1話：Unicodeにおける全角・半角 - ALBERT Engineering Blog
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
Ruby製のクローラー Anemoneの文字化け対策 - プログラマでありたい
何度も取り上げていますが、Ruby製のクローラーであるAnemoneについてです。もう2年ほどメンテナンスされていないものの、Rubyの中のクローラー・フレームワークとしては未だに一番の完成度です。しかし、残念ながら幾つかの問題点があります。その中で日本語を扱う我々にとっては一番大きな問題は、文字化けです。 Anemoneの文字化けの原因 Anemoneの文字化けの原因は、ずばりUTF-8以外の考慮が何もされていないためです。Anemoneが利用するHTMLパーサーであるNokogiriは、もともと内部的な文字コードをUTF-8として扱います。UTF-8以外の文字コードを扱う場合は、文字コードを指定して渡す必要があります。それにもかかわらず、AnemoneがHTMLをパースする時は、次のような実装になっています。 # # Nokogiri document for the HTML bod
はてなブログ
出雲大社までヒッチハイク旅したら自己発見できた[出雲大社ヒッチハイク体験記/前編] ふとした思いつきから内省と思索の旅へ。神奈川から出雲大社までのヒッチハイクで、予期せぬ自己発見を経験した4泊5日の記録。 はじめに - 旅の動機 - 10年友達関係が続いて、昨年頭から1年間付き合った恋人と年末に別れた。 失恋の詳細はどうでもいいので省く。付き合…
GNU grep 2.18リリース: 10倍速くなったと思ったら今度は200倍遅くなっていた | はむかず！
先日の記事 いまさらgrepが10倍高速化したのはなぜか が思わぬ閲覧数を稼いでしまい、トルコ語の知識を日本に広めるのに大きな貢献をしたような気がしますが、みなさんいかがお過ごしでしょうか。 実は先日の記事を書いた時にはすでに2.18がリリースされてたのだが、今回は2.17のときと違って日本の大手メディアが取り上げてなかったので、ついつい見落としていた。しかし実は2.18でも大きな変更が！！ リリースノート抜粋： grep -i in a multibyte, non-UTF8 locale could be up to 200 times slower than in 2.16. [bug introduced in grep-2.17] なんということでしょう。-iオプションでUTF8のときは2.17で10倍速くなっていたのだが、それ以外のマルチバイトロケールのときは200倍遅くなって
文字コードの脆弱性はこの3年間でどの程度対策されたか?
4. デモ1:半端な先行バイトによるXSS • 半端な先行バイトとは – Shift_JIS、EUC-JP、UTF-8などマルチバイト文字の1 バイト目だけが独立して存在する状態 – 次の文字が、マルチバイト文字の2バイト目以降の文 字として「食われる」状況になる – input要素などの引用符「”」を食わせて、イベントハ ンドラを注入する攻撃 Copyright © 2010-2014 HASH Consulting Corp. 4 5. デモ１：PHPソース <?php session_start(); header('Content-Type: text/html; charset=Shift_JIS'); $p1 = @$_GET['p1']; $p2 = @$_GET['p2']; ?> <body> <form> PHP Version:<?php echo htmlspeci
最近、モリサワのようすがちょっとおかしいんだが。 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
ところで、モリサワのPr6Nフォントがやばいらしいですね。 twitterで話題になってたね。 まとめを読んでも、ちょっとわかりにくかったんですけど、どういうことなんですか？ リュウミンとかのPr6/Pr6Nには複数のバージョンが存在して、新バージョンで作ったデータを旧バージョンの環境で開くと、豆腐になっちゃう文字があるんだよね。 うー、それはかなりイヤですね。 だよね。新バージョンのほうは、IVS（異体字シーケンス）対応版なんだけど、cmapも新しいのになってるから。 しーまっぷ？ cmapっていうのは、符号位置とグリフの対応表。DTP用の日本語OpenTypeフォント（Adobe-Japan1フォント）には、Unicodeに入ってないグリフもたくさん入ってるでしょ。 入ってますね。 「Unicodeに入ってない字」はcmapには載ってない。でも、そういう字が後からUnicodeに収録さ
wが二つ重なった文字「ʬ」がバイラビアル・パーカッシブだと調べる方法
もともと2ちゃんねるで回答されたものみたいですが、「ｗが縦に二つ重なった文字の出し方教えて」という質問に対して、「ʬ」を出したり、その読み方が「バイラビアルパーカッシブ」だと回答した人はどうやって調べたんでしょうね。 そ […] もともと2ちゃんねるで回答されたものみたいですが、「ｗが縦に二つ重なった文字の出し方教えて」という質問に対して、「ʬ」を出したり、その読み方が「バイラビアルパーカッシブ」だと回答した人はどうやって調べたんでしょうね。 その回答者がこれを使ったかどうかはわかりませんが、ユニコード内の文字だと、ShapeCatcherというサイトで調べられます。 左側のボックスに、マウスで探したい文字を書き、”Recognize”(認識せよ)をクリックすると、下にそれに近い文字が列挙されます。wを縦に二つ書いてみましょう。 コード 0x2ac のラテン文字 bilabial perc
jQuery.ajax() のリクエストパラメータを、指定した文字コードで渡す - 株式会社CFlatの明後日スタイルのブログ
jQuery.ajax() のレスポンスを指定した文字コードで取得する系の話はその辺にごろごろ転がっていますが、逆にリクエストを指定した文字コードで行う系の話がほとんど見つからなかったので、ライブラリを作成しました。 考え方としては、通常は UTF-8 で行われるリクエストパラメータの URI エンコード処理を、ShiftJIS や EUC-JP で行ってやればよいだけです。……とはいえ、文字列を ShiftJIS や EUC-JP に変換する部分は大変なので、ライブラリ任せにしてしまっています。 UTF-8 から他の文字コードへの変換処理には、http://polygon-planet-log.blogspot.jp/2012/04/javascript.html の encoder.js を使用しています。下記コードの利用には、encoder.js（https://raw.github
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/ymko/items/2d1409c155b97d27cbf0
UnicodeのWAVE DASH例示字形が、25年ぶりに修正された理由 
全角チルダ問題
