本当はこわいエンコーディングの話 // Speaker Deck東京Ruby会議10 で発表したスライド
websocket.elでマルチバイト文字を扱う時の注意 - Shohei Yoshida's Diary
追記 修正されたようですので、自分で回避していた方は最新版にアップデートしてください。 websocket.el + Amon2でリアルタイム Markdown Viewer - Life is very short で書いた、websocket.elで使った Realtime markdown viewerで 日本を使うとエラーになっていた問題は websocket.elにマルチバイト 文字列をそのまま送っていたことが原因でした。 websocket.elの websocketのフレームに収める部分で利用する unibyte-stringという関数は 0-255の文字コードしか受付ません。 なのでマルチバイト文字列を渡す場合は、それをバイト列にする 必要があります。Perlで言うところの Encode::encodeの処理が 必要になるわけです。 Emacs Lispの場合は encod
開発メモ: UTF-8とUCS-4の変換メモ
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
C++0xのUTF-8対応に問題あり
今まであまり気にしていなかったのだが、C++0xのUTF-8対応には、非常に深刻な問題があるように思われる。 C++0xでは、u8 encoding prefixを使うことによって、UTF-8でエンコードされた文字列リテラルが使える。 u8"あいうえお" ; しかし、このリテラルの型は、char const [16]なのだ。（UTF-8では、ひらがなは一文字3バイトを要する。null終端を付け加えて、サイズは16となる。） しかし、charという型は、歴史的に、あらゆるマルチバイト文字コードを格納するのに使われている。charを入力に受け取った時点で、それがどんなエンコードを使っているかは分からないのだ。 つまり、以下の様な関数を書いた場合、 // UTF-8の文字列を入力に取る関数 void f( char const * ptr ) { // ptrがUTF-8文字列を参照している保証
Tips on IEC (implicit encoding conversion) - Islands in the byte stream
Perlにおいて日本語のテキスト文字列とバイナリ文字列*1を結合すると激しく文字化けするのは誰もがつまづくトラップですが、これはPerlのデフォルトのIECが Latin-1 に基づいて行われるからです。UTF-8ではなくLatin-1なのは後方互換のために必要な決定なのですが、我々日本人にとってはこのせいで文字化けに苦しまれることになってしまいました。 そこで、IECが発生したときに致命的エラーを発生させるプラグマを書いてみました。 https://github.com/gfx/p5-encoding-implicit `no encoding::implicit` によって、そのスクリプト全体でIECを禁止します。これはencoding::warningsプラグマとほとんど同じですが、デフォルトで警告ではなく致命的エラーであること、スクリプト全体に効果があることが異なります。これにより
第9回 文字コードが引き起こす表示上の問題点［前編］ | gihyo.jp
文字コードが引き起こす問題点は、これまで説明したような比較の一致・不一致といったソフトウェアの処理上のものだけでなく、人間に対する視覚的な効果という点でも強く影響を与え、攻撃者にとっての強力な道具となることがあります。 今回および次回で、そのような文字コードが引き起こす視覚的な問題点を紹介します。 視覚的に似た文字 見かけのよく似た文字は、フィッシングなどによく利用されます。典型的な例としては、アルファベット小文字のl（エル）と数字の1などがあります。たとえば、http://bank1.example.jp/ というURLのオンラインバンクがあったとすると、攻撃者は http://bankl.example.jp/ というURLを使ってフィッシングを企むということは容易に想像できると思います。 もちろん、収録している文字数が増えれば増えるだけ、このように見かけのよく似た文字が存在する率も高
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TSNET - Text and Scripting Network
HTML-Pictogram-MobileJp-0.02
Perlゼミ(サンプルコードPerl入門)