作成日：2014.03.13 更新履歴 (2014.0313) 2013年6月27日の日記と2014年3月3日の日記から作成。 目次 はじめに strcoll 関数 strxfrm 関数 疑問 UTF-8 の話 文字列照合順序(Collation) L1 Base Characters L2 Accents L3 Case/Variants L4 Punctuation Llast Identical ライブラリ実装 参考文献 コメント はじめに C 言語の文字列の比較は strcmp() を用いるのが一般的である。 この関数は 2 つの NULL 終端文字列を先頭から符号なしバイトとして比較し大小関係を決める。 一方、文字列が各国のロケール(locale)を持つ場合、言語・国固有の文字列の照合順序(collation)が存在する。 Collation に基づいて文字比較を行うには str
unicodeに関するseiunskyのブックマーク (12)
-
seiunsky 2015/03/23
-
MySQL と寿司ビール問題 - かみぽわーる
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
-
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる で、日本語が分かる人には utf8_unicode_ci のヤバさを感じてもらえたと思うんですけど、この挙動はドキュメントによると UCA というアルゴリズムによるものらしい。 MySQL implements the xxx_unicode_ci collations according to the Unicode Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/. The collation uses the version-4.0.0 UCA weight keys: http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. Currently,
-
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+の恐ろしさは、すげーファイルシステムではない、ということではない。いいアイディアがあると信じ
-
日付フォーマット yyyy と YYYY の違い - 強火で進め
結論 まず最初に急いでる人向けに結論を先に書いておきます。2つの違いは以下の様に成っています。 yyyy 年(西暦)を出力 YYYY ある年における「最初の木曜日を含む週が、その年の第1週である」というルールで年(西暦)を出力。 例えば 2015/1/1 は木曜日なのでその週の日は日曜日〜土曜日まで全て2015年の第1週という解釈になります。この場合には2014年で有る、 2014/12/28(日曜)〜2014/12/31(水曜) の時でも YYYY では 2015 を返します。 きっかけ Podcast で Rebuild の第73回を聴いていたら日付フォーマットで yyyy ではなく、YYYY を使った為に Twitter の Android クライアントで不具合が出たという話が出てきました。 ※根本的な原因はこのルールでサーバ側が実装されていた為、 Android クライアントで正し
-
Swiftでの文字列比較におけるUnicode正規化を巡る注意点 - Qiita
これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it 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
-
iPhone間の新しい文字化け「兄化け」 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
iPhone間の新しい文字化けパターンが発見されたのでメモ*1。この少なくとも3つのダメな仕様が重なって発生する文字化けは、発見者によって「兄化け」と命名された*2。 「兄化け」は、兄がSoftBankまたはauのiPhoneでメッセージアプリを、妹がiPhoneのメールアプリでdocomo.ne.jpアドレスを使っている場合に発生する。兄が絵文字入りのメールを送信すると、妹の環境では絵文字が豆腐に化け、それを引用して返信すると、今度は兄の側でメッセージ全文が化ける。 以下、この文字化けの理屈について。兄のメッセージアプリは、絵文字入りのメッセージをUTF-8で送信。キャリアの送信側のサーバが、これをドコモのShift_JISに変換する。しかし、妹のiPhoneのメールアプリはドコモのShift_JISに対応していないので、ドコモの絵文字を単に「Shift_JISの未定義領域の文字」として
-
-
Twitter時代の文字の数え方 | 配電盤
入力「×」のブラウザでは、「𠮷」が2文字とみなされるため、2文字目まで、つまり「𠮷野」までしか入力できません。 Mozillaの文書には、Unicode code pointsで数えると書いてあるので、そのうち改善されるのかもしれませんが、現時点ではTwitterのために「maxlength="140"」を使うことはできません。 pattern属性 Firefox 21とChrome 27、IE 10、Opera 12.15は、「pattern=".{0,3}"」（任意の文字からなる0から3文字）のような正規表現を使った検証にも対応していますが、やはり「𠮷野家」は4文字とみなされてしまいます。 JavaScript 追記：javascript – でBMP以外のUnicode文字をきちんと扱う（404 Blog Not Found） JavaScriptでは、文字列strの長さをst
-
SourceTree の圧倒的な素晴らしさと致命的な欠点について。(修正済み) - こせきの技術日記
(追記) 下記の問題点は、1.5で修正される予定とのことです。 (追追記) 濁点付きの検索はできないようですが、ログの問題は修正されていました。v1.5.3で確認。 SourceTree の UI は最高に素晴らしく、これまで見たどんなバージョン管理アプリケーションと比べても、次元が違う洗練されたユーザエクスペリエリンスが約束されており、有料になったら絶対買うんですが、いまは無料なので本当に感動的です。 Free Mac client for Git, Mercurial and SVN - Atlassian SourceTree Git、Mercurial 対応 DVCS Mac クライアント | Atlassian 日本語サイト Mac App Store - SourceTree (Git/Hg) Mac App Store でも一つだけ問題があって、、まともなコミットログが書けな
-
文字コード（UTF-8,Shift_JIS,EUC-JP,ISO-2022-JP）についての俺的まとめ - 今日もスミマセン。
「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか？ 日本語の文字コードは大きく以下の２つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング（文字符号化方式）」の事を指す。 文字符号化方式 文字集合って？ 読んでそのまんま”文字の種類の集まり”。「キャラ
-
Ruby 1.9 - Feature #2833: 絵文字エンコーディングの提案 - Ruby Issue Tracking System
絵文字に対応したエンコーディングを実装しました。 これらを 1.9.2 のリリース前に trunk にマージすることを提案します。 redmine のチケットにパッチを添付しました。 このパッチは以下のエンコーディングを実装しています。 - UTF8-Google - UTF8-DoCoMo - Shift_JIS-DoCoMo - UTF8-KDDI - Shift_JIS-KDDI - ISO-2022-JP-KDDI - stateless-ISO-2022-JP-KDDI - UTF8-SoftBank - Shift_JIS-SoftBank そして、これらのエンコーディング間における fallback なしの 相互変換を行うための transcoder も実装しています。 fallback とは、変換先エンコーディングに対応絵文字が存在しない場合に、 たとえば "[稲穂]" の
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました