Charbase: A visual unicode databaseCharbase is a visual database of characters from the Unicode 6.1 standard, made available without clutter. Tweet
文字と濁点・半濁点が分かれていて，それらを結合したい時 - Qiita
例えば「レポート」という文字列をユニコードで扱うときに， 文字「ポ」が「ホ + ゜」 というように，文字と濁点・半濁点に分かれてしまう場合
Pythonにおける日本語のエンコーディングの検出について - 試験運用中なLinux備忘録・旧記事
(2015/1/29)一部のリンク先を修正し、更にサンプルコードもPython 3で動作することなどを目的に一部修正した。 エンコーディングの簡易検出 例 ASCIIとISO-2022-JPの区別が重要でない場合のデコード 実用的なエンコーディング判別パッケージ エンコーディングの簡易検出「Pythonにおけるエンコーディングの扱いとエンコーディングの変換について」の最後で、特定のエンコーディングにエンコードされた文字列をUnicode文字列にデコードする際に実際のエンコーディングに合っていなければUnicodeDecodeErrorが出ることを書いたが、言い換えると、一部の例外を除いて正しいエンコーディング指定と文字列オブジェクトとの組み合わせでのみUnicodeDecodeErrorは発生しない。 これを利用して、エンコーディングが不明な文字列オブジェクトに対して、エンコーディング名の
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正規化の考え方自体はとてもシンプルです。でも、よく知ろうとしていろいろ調べると、用語がハイコンテキストすぎて、混乱してワケがわからなくなります。日本で一般的に見られる用語を図にしてみましょう。 混乱するのはどこだと思いますか？ “合成済み文字” と “合成文字” の２か所です。どちらも言葉として同じ意味です。それなのに、異なった状態を表す用語として無理矢理に使い分けようとしています。ここから、以下のような奇妙な文章ができあがります。
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のときのデフォルト
Unicode HOWTO — Python 2.7.18 documentation
This document is for an old version of Python that is no longer supported. You should upgrade and read the Python documentation for the current stable release. Unicode HOWTO¶ Release 1.03 This HOWTO discusses Python 2.x’s support for Unicode, and explains various problems that people commonly encounter when trying to work with Unicode. For the Python 3 version, see <https://docs.python.org/3/howto
PHPのロケールに関するまとめ - hnwの日記
5/3 17:45追記：t_komuraさんに指摘いただいた関数と、さらに僕が調べ直したものを含め、「ロケール設定に従う関数一覧」に25個ほど追加しました。かなり見落としがありましたね…。 PHPのロケール*1まわりについて調査したので、これをまとめてみます。 この記事は「ロケールの影響を受ける関数 - Sarabande.jp」を掘り下げたものです。masakielasticさん、ナイスな記事をありがとうございます。 PHPの文字列型と文字エンコーディング 他のモダンなLL言語と異なり、PHPは文字列の文字エンコーディングに関して何も仮定せず、単なるバイト列として管理しています。つまり、文字エンコーディングの取り扱いは各関数の実装に委ねられています。 下記の通り、これはマニュアルにも記述があるのですが、実に残念なことです。 残念ながら、PHP の各関数が文字列のエンコーディングを判断する
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
Linus Torvalds、HFS+に激怒
CVE-2014-9390 aka "Git on case-insensitive filesystems" I did not give the… gitが影響を受けた、HFS+で、一部の文字を区別しなかったり無視したりする問題に対して、Linusが吠えている。 マジで、HFS+はたぶん最悪のファイルシステムだな。クソすぎるぜ。NTFSもutf8の正規化で似たような問題（/の非正規化された表現を使用）があったが、まあ、今は修正されたんだろうよ。OS Xの問題は根本的すぎる。 そりゃ、古いさ。そりゃ、データ保護がクソすぎるってのはあるさ。だが、そういうのは、単に「すげーファイルシステムじゃない」って問題だ。「自分のケツすら拭けないマヌケによって設計された信じがたいクソ」ってわけじゃない。 HFS+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
Swiftでの文字列比較におけるUnicode正規化を巡る注意点 - Qiita
Stringの比較は正規化をかけた上で行われる Swiftの文字列比較は，Unicode正規化をかけた上で行われます。 たとえば，次の例をご覧ください。 let gaC = "\u{304C}" // 「が」の結合形 let gaD = "\u{304B}\u{3099}" // 「が」の分解形 // NSString としての文字数（UTF16での文字数）は異なる (gaC as NSString).length // => 1 (gaD as NSString).length // => 2 // String としての比較 gaC == gaD // => true (!!) これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainl
PythonのUnicodeEncodeErrorを知る - HDEラボ
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にどのよ
Pythonでの日本語処理：Unicode型と文字列型 - 思い立ったら書く日記
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.
「～ (から・波線)」がWebページで文字化けする条件と対処法 全角チルダと波ダッシュ | アイビーネットblog
2008年9月22日 09:30 (X)HTMLWebサイト管理 Webページ上で「10月10日から10月23日の期間」といった表現したい場合、次のような表現をよく使うと思います。 しかし条件によっては、Winで表示した場合に「～」が崩れたように文字化けして表示がされる事があります。 「～ (から・波線)」がWinで文字化けする条件 「～」がWinで文字化けする条件ですが、下記がそろった場合などに起こります。 Webページの文字コードが「UTF-8」 Macで「～」を入力した Winで表示した (メイリオでは起こらない) 「～ (から・波線)」がWinで文字化けする理由 各OSで「～」を入力 表示される文字 Winで入力 上記の表からわかるように、同じ「～」を入力していても、Winでは「全角チルダ(FF5E)」が表示され、Macでは「波ダッシュ(301C)」が表示されます。OSによって表示
「ユニコードは犯罪だからやめてください」の衝撃 - yanok.net
新年早々、大笑いしてしまったこと。 下らないといえば下らないので書くまでもないかと思ったのですが、後で忘れた頃に読み返すと面白いかもしれないので書きとめておくことにします。 何があったのかは下記のページに詳しく書かれてあります。こちらを読んでいただければ、ぶっちゃけそれ以上のことはないです。 「LINEウイルス」の正体とは―LINE内で流行する「ウイルス攻撃」の現状について 簡単にまとめていうと、 LINE上で「ウイルス」なるものを送りつけることができるという噂があって、実際にそれを送りつけられるとLINEのアプリが誤動作(重くなる)らしい 実際のところ、ここで「ウイルス」と呼ばれているものはある特定の文字列である (プログラムではない。であるからしてウイルスでもない) 特定の文字列を受け取ると動作が極端に重くなる不具合のあるアプリがある、というのが真相らしい 問題を引き起こす文字列は、U
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - rspeer/python-ftfy: Fixes mojibake and other glitches in Unicode text, after the fact.
UnicodeのWAVE DASH例示字形が、25年ぶりに修正された理由 
Mac における MP3 ファイルの文字化けを直してみた - あらびき日記
全角チルダ問題
Engadget | Technology News & Reviews
文字コードの脆弱性はこの3年間でどの程度対策されたか?
