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+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
文字コード地獄秘話 第2話：聖母マリアよ、二人を何故別々に？ | ALBERT Engineer Blog
はじめに 二人を最初から一つにしておけば、何も問題など起こらなかったのだ。 一つのものを二つに分けたその時から、長い物語が始まる。 おや？また会いましたね。どうも、文字コードおじさんです。 もう半年近くも前になりますが、前回の投稿はだいぶ反響があったようで驚いております。ありがとうございます。 今回も文字コードネタですが、Unicodeにおける結合文字列を取り上げてみようと思います。 高度に発達した文字コードは地獄と見分けがつかない 次の画像はTwitterの投稿フォームですが、おかしな点があります。わかりますか？ そうです。4文字しか入力していないはずなのに 5文字分とカウント されていますね。おかしいと思いませんか？あなた？ 改行とかスペース入れてるんじゃねーだろうな？とか言わないで下さいね？ さらに次の画像を見てみてください。 こちらは4文字とカウントされていますね。先のものとは一体
開発者向けUnicode FAQ--もう知らないではすまされない - builder by ZDNet Japan
クラウドネイティブの実現 モダンインフラの構築・運用の課題解決へ コンテナの可能性を広げるVMware Tanzu DX時代のアプリケーションセキュリティ 未来革新プロジェクトに邁進するSOMPO 基幹システムのモダナイゼーションに迫る VMware 渡辺氏に聞く 顧客のデジタル変革のために 自らも改革を続けるヴイエムウェアの戦略 日清食品グループのDX（前編） 現場が主役のDXのススメ トップの強い意思で変革に弾み Microsoft 365のデータは安全か？ クラウド型アプリを採用する企業のための 包括的なデータ保護のありかたを解説 ともにDXを推進する コンテナ化されたワークロードを管理 継続的な価値を生みだす「協創」への挑戦 ITインフラ運用からの解放 HCI＋JP1による統合運用による負荷激減で 次世代IT部門への役割変革へ一歩前進 エンドポイントセキュリティの転機 情報セキュリ
PythonでMacOSX上のファイル名を取得するとカナとかの濁点が分割される問題をまた考えてたら簡単な関数できた - 牌語備忘録 -pygo
『Shiroさん Gauche について語る - Higepon’s blog』の動画で、Gaucheの作者shiro氏（こんな人に師事したい）の「PerlからSchemeにほとんど書き（乗り）換えちゃった」的な発言に感化され、自分もPythonで色々やってみることにした。魔人ブウと村人A以上にレベル違うけど(||ﾟДﾟ) 過去にPythonでリネーマーでも作ろうかと思案したが、MacOSX上のファイル名を取得すると『ほげほげ』が『ほけ"ほけ"』みたいに濁点が分割される問題が面倒でサジ投げたことがある。 こことかあそことかで調べてみたけど、正規化とかユニコードとかわけわからなかった(´･ω･`)。それでも何とかなるだろうと信じてファイルネームの修正を試みることにした。（ここが参考になった『http://www.kharakawa.com/kh.log/archives/2008/03/py
Unicode正規化
正しい並び替えでは、表示は(A)のままですが、間違った並び替えでは、正規結合クラスが互いに等しいMACRONとACUTEを並び替えたため、表示は(B)のように、eの上のアクセント記号の位置が入れ替わってしまいます。 正規分解・互換分解 ある文字列の正規分解 (Canonical Decomposition) を得るには、まず、それぞれの文字を正規マッピングによって再帰的に、可能な限り、分解します。すなわち、1回分解した後に現れた文字がなおも分解可能であればさらに分解します。分解マッピングがその文字自身である場合は、分解不可能なので、そのままです。 しかし、分解しただけでは必ずしも正しい結果が得られません。つまり、結合文字の順序の一意性を保証するため、分解後の文字列に対して正規順序アルゴリズムを適用しなければなりません。このように、正規マッピングによる再帰的分解と、正規順序アルゴリズムによる
Unicode::Normalize で遊ぶ - daily dayflower
Unicode の規格では，文字の合字（リガチャ等）等を統一的に扱えるように，「正規化」という処理が仕様として定まっています。この正規化処理のうち「互換性分解」という処理を行うと副作用として半角カナを全角カナに変換できます（逆に全角カナ→半角カナはできません）。 #!/usr/bin/perl use strict; use utf8; use Encode; use Unicode::Normalize; my $src = 'ﾎﾟﾝｼﾞｭｰｽ'; my $dst = Unicode::Normalize::NFKC($src); print Encode::encode('utf8', "${src} => ${dst}\n"); # OUTPUT is: ﾎﾟﾝｼﾞｭｰｽ => ポンジュースUnicode の正規化についてはperl5.8のUnicodeサポート および http:/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
pythonと文字幅(Unicodeの正規化)