(2015/1/29)一部のリンク先を修正し、更にサンプルコードもPython 3で動作することなどを目的に一部修正した。 エンコーディングの簡易検出 例 ASCIIとISO-2022-JPの区別が重要でない場合のデコード 実用的なエンコーディング判別パッケージ エンコーディングの簡易検出「Pythonにおけるエンコーディングの扱いとエンコーディングの変換について」の最後で、特定のエンコーディングにエンコードされた文字列をUnicode文字列にデコードする際に実際のエンコーディングに合っていなければUnicodeDecodeErrorが出ることを書いたが、言い換えると、一部の例外を除いて正しいエンコーディング指定と文字列オブジェクトとの組み合わせでのみUnicodeDecodeErrorは発生しない。 これを利用して、エンコーディングが不明な文字列オブジェクトに対して、エンコーディング名の
初版 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正規化の考え方自体はとてもシンプルです。でも、よく知ろうとしていろいろ調べると、用語がハイコンテキストすぎて、混乱してワケがわからなくなります。日本で一般的に見られる用語を図にしてみましょう。 混乱するのはどこだと思いますか? “合成済み文字” と “合成文字” の2か所です。どちらも言葉として同じ意味です。それなのに、異なった状態を表す用語として無理矢理に使い分けようとしています。ここから、以下のような奇妙な文章ができあがります。

RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyukiMySQLのcharset utf8のときのデフォルト
This document is for an old version ofPython that is no longer supported. You should upgrade and read thePython documentation for the current stable release. Unicode HOWTO¶ Release 1.03 This HOWTO discussesPython 2.x’s support for Unicode, and explains various problems that people commonly encounter when trying to work with Unicode. For thePython 3 version, see <https://docs.python.org/3/howto
5/3 17:45追記:t_komuraさんに指摘いただいた関数と、さらに僕が調べ直したものを含め、「ロケール設定に従う関数一覧」に25個ほど追加しました。かなり見落としがありましたね…。PHPのロケール*1まわりについて調査したので、これをまとめてみます。 この記事は「ロケールの影響を受ける関数 - Sarabande.jp」を掘り下げたものです。masakielasticさん、ナイスな記事をありがとうございます。PHPの文字列型と文字エンコーディング 他のモダンなLL言語と異なり、PHPは文字列の文字エンコーディングに関して何も仮定せず、単なるバイト列として管理しています。つまり、文字エンコーディングの取り扱いは各関数の実装に委ねられています。 下記の通り、これはマニュアルにも記述があるのですが、実に残念なことです。 残念ながら、PHP の各関数が文字列のエンコーディングを判断する
本当はエスケープシーケンスのことを調べていたのだが、その前に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
CVE-2014-9390 aka "Git on case-insensitive filesystems" I did not give the… gitが影響を受けた、HFS+で、一部の文字を区別しなかったり無視したりする問題に対して、Linusが吠えている。 マジで、HFS+はたぶん最悪のファイルシステムだな。クソすぎるぜ。NTFSもutf8の正規化で似たような問題(/の非正規化された表現を使用)があったが、まあ、今は修正されたんだろうよ。OS Xの問題は根本的すぎる。 そりゃ、古いさ。そりゃ、データ保護がクソすぎるってのはあるさ。だが、そういうのは、単に「すげーファイルシステムじゃない」って問題だ。「自分のケツすら拭けないマヌケによって設計された信じがたいクソ」ってわけじゃない。 HFS+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
これは,こちらのサイトによると, Depending on your requirements, this may or may not be what you want, butit is certainly consistent with the overall design of the String type to abstract away as many Unicode details as possible. Rule of thumb: if two strings look equal to the user, they will be equal in your code. つまり,「Unicodeでの実装にかかわらず,ユーザ側からの見た目が同じであるからには,コード上でも同一として扱われるべきである」という原則に基づいているとのことです。 実際,この仕様はApple

2019年8月6日に開催されたヤフー名古屋Tech Meetup #3の内容です。 #3 は「Webフロントエンドを支えるノウハウ」をテーマに開催しました。 JJUGCCC 2019 fall g3のセッション資料です。 「ちょっと凝ったことをしようとすると大量のXMLを書かなきゃいけない」「プラグインを並べてもうまく動いてくれない」など、Mavenは誤解され敬遠され、Gradleなどの他のビルドツールにシェアを奪われてきました。 が、依然としてMavenはJavaのデファクトスタンダードなビルドツールに位置づけられており、マスターする価値は十分にあります。そして良く学んでみると、そもそもXMLで過度なカスタマイズしようというのが誤った使い方だったのに気づきます。そこへ至るにも、タスクランナーの延長線上にある他のビルドツールと異なり、Maven独特なライフサイクルとプラグインの関係性もき
Pythonにはじめて触って、いつのまにか1年が過ぎたのですが、一番はまったのは、やっぱりunicodeの扱いだったと思います。 特に、 UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-12: ordinal not in range(128) のようなエラーにはさんざん悩まされました。ここがたとえばrubyなど他の言語と比べてわかりにくいために、Pythonが取っつきにくい言語になっているのではないか、と個人的には思います。 そこで、このエラーに関係するはまりどころとTipsをいくつか列挙してみました。これからPythonに触れられる方の参考になればと思います。 なお、環境はUNIX上のPython 2.4, 2.5を想定しています。 u1はunicode型で、s1はstr型です。s1にどのよ
Pyhton の XML/HTML パーサ・ライブラリ BeautifulSoup を使って、Google の検索結果を整形するPython スクリプトを書いたところ、Python の日本語処理で UnicodeEncodeError、UnicodeDecodeError ではまった。いい機会なので、Python で日本語処理に関して、自分なりに整理してみる。 この記事はWindows でのPython 2.5.1 で動作確認している。Python 3.x では改善しているかもしれないので、この記事を読む方はご注意を。Python 3.x については時間があれば確認したい。というより、早くバージョンアップしなさい!という感じですが。 [2009.09.22 追記]Python 3.0 で Unicode まわりがかなり修正かかっていました。この記事を読む方は、Python 2.5.

乙女 期待 値京成 杯真のカウント「決定的な守備介入」 2試合連続でベンチ入りした冨安毅大はLEAGUENMB48の堀詩音さんと北海道コンサドーレ札幌のFW中島大輝さんが共演 フランケル キン肉 マン 超人 一覧スロット 炎炎ノ消防隊元ブラジル代表DFファビオ・ダ・シルバ(32)がブラジルのグレミオに完全移籍したと発表した1961年と1963年のエルジン・ベイラー(当時のロサンゼルス・レイカーズ) 株式 会社 三 協 山田 桃太郎成り上がりチームは6勝3敗と好調 12月中旬に左肩の負傷で欠場中のゴールデンステイト・ウォリアーズのステフィン・カリーがラジオ番組「95本田圭佑氏がカンボジア・ナショナル・フットボール・フェデレーション(FFC)のGMを辞任 4日 パチンコからくりサーカス
SecurityとValidationの奇妙な関係、あるいはDrupalはなぜValidationをしたがらないのか
新年早々、大笑いしてしまったこと。 下らないといえば下らないので書くまでもないかと思ったのですが、後で忘れた頃に読み返すと面白いかもしれないので書きとめておくことにします。 何があったのかは下記のページに詳しく書かれてあります。こちらを読んでいただければ、ぶっちゃけそれ以上のことはないです。 「LINEウイルス」の正体とは―LINE内で流行する「ウイルス攻撃」の現状について 簡単にまとめていうと、LINE上で「ウイルス」なるものを送りつけることができるという噂があって、実際にそれを送りつけられるとLINEのアプリが誤動作(重くなる)らしい 実際のところ、ここで「ウイルス」と呼ばれているものはある特定の文字列である (プログラムではない。であるからしてウイルスでもない) 特定の文字列を受け取ると動作が極端に重くなる不具合のあるアプリがある、というのが真相らしい 問題を引き起こす文字列は、U
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く