タグ

unicodeに関するpsychedesireのブックマーク (5)

  • UnicodeとUTF-8の違いは? - Humanity

    という2chのスレがかなり勉強になったのでまとめ。 少しでも有用だと思ったものは載せてあるので結構長いです。 Unicodeのような文字集合(符号化文字集合?)やUTF-8のようなエンコーディング方式に限らず色んな文字コードにまつわる話があります。 たびたび話が繰り替えされますがそれは確認ということで。 (元スレ) 追記:簡単にまとめました。 1 :デフォルトの名無しさん:2007/04/30(月) 20:02:37 ビッグインディアンとかなんとかかんとか 3 :デフォルトの名無しさん:2007/04/30(月) 20:05:48 また、頭の悪そうなスレが・・・ >>1 それは魚とマグロの違いを訊ねるようなもんだ。 4 :デフォルトの名無しさん:2007/04/30(月) 20:06:49 魚と鮪というよりは、魚と刺身の違いのような気がする。 5 :デフォルトの名無しさん:2007/04/

    UnicodeとUTF-8の違いは? - Humanity
    psychedesire
    psychedesire 2009/11/30
    おもすれーなこれは
  • JavaScript/備忘録/文字コード変換 - Felix-labo's Wiki

    文字コードの変換 † サーバーを、UTF-8で統一できたので、あまり問題のなさそうなところですが、京すごろく(kusano@kyosugoroku.com) は、SJIS で書いているのでこちらの変更でAJAXを使ってコールバックによる結果呼び出しを行った際に、きれーいに文字化けしました。 結果としては、すばらしい.js ファイルにめぐり合えて解決です。 まず、以下のリンクから、ecl.js.txt ファイルをダウンロードし、.txt 拡張子を取り去り、.jpファイルとしルートなどに設置します。 http://nurucom-archives.hp.infoseek.co.jp/digital/ecl.js.txt ご心配な方は、オリジナルページhttp://nurucom-archives.hp.infoseek.co.jp/digital/escape-codec-library.ht

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • UTF-8の冗長なエンコードとは何で、なんでそれがセキュリティ的に危ないのか?を文字コード知識レヴェル3くらいの凡プログラマが考えてみる - tohokuaikiのチラシの裏

    何故かあたり前にならない文字エンコーディングバリデーション | yohgaki's blog ってあるように、いまいち文字コードの不正な判定による危険性ってのが分かってない。 SJISの問題は、(2/3)SQLインジェクションを根絶!セキュア開発の極意 - 第5回■注目される文字コードのセキュリティ問題:ITproの記事がわかりやすかった。 というか、やっぱりPHP使ってると誰でも一度は「なんじゃこの『¥』は?」って思うもんなんで。 なるほど、確かに↓の図のように「あるバイト」が2つの意味を持つっていう文字コード形態はやばいんだなと。 EUC-JPはそんなことはしないで、1つのバイトには1つの意味しか取らせない。 だけど、これでも文字化けが起こることがある。経験的には、「マルチバイトをXX文字で切り落としたい」とかやった場合。ちゃんと文字コードを判定してくれるPHPでいえばmb_subst

    psychedesire
    psychedesire 2009/09/11
    『要するに、「3バイト食いますよ~」っていうフラグを立てておきながら(つまり1100000のバイトを送る)、2バイトしか送らなかった場合、次の文字も巻き込んでしまうんじゃないかってことかな?これって、EUC-JPやSJISで
  • s.decode('utf8') よりも unicode(s, 'utf-8') の方が速い - methaneのブログ

    http://groups.google.com/group/comp.lang.python/browse_thread/thread/314a3043ea63319f/ unicode vs s.decode unicodeはLOAD_GLOBALで、s.decodeはLOAD_ATTRでスタックに積まれる。で、LOAD_GLOBALの方が速い。 さらに言えば、何度もデコードを行うのであれば u = unicode のようにローカル変数にするとさらに速くなる。LOAD_ATTRやLOAD_GLOBALは最適化で消すことが出来ないので、明示的にローカル変数に束縛することはCPythonに限らず有効な手法だ。 'utf8' vs 'utf-8' 単なる1タイプの問題だけど、内部的には 'utf-8' が利用されており、 'utf8' を使うと 'utf-8' だと判断するのに1クッション必

    s.decode('utf8') よりも unicode(s, 'utf-8') の方が速い - methaneのブログ
  • 1