Firefox などで下の半角濁点「ﾞ」・半角半濁点「ﾟ」を選択してみてほしい。 ｶﾞ、あﾞ、漢ﾞ、aﾞ、 ﾞ、☃ﾞ、✐ﾞ えﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞﾞっ!! ふﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟﾟ。 ぬﾞﾞﾟﾞﾞﾞﾟﾟﾟﾟﾞﾞﾞﾞﾟﾞﾟﾞﾞﾟﾞﾞﾞﾞﾞﾟﾞﾞﾞﾟﾞﾟﾟﾟﾞﾞﾞﾟﾟﾟﾟﾟﾟﾟﾞﾞﾞﾟーん いくら半角（半）濁点だけを選択しようとしても、前の文字まで（それがスペースだろうが記号だろうが）一緒に選択されてしまうと思う。もう少し正確に言えば選択されるのは [^ﾞﾟ][ﾞﾟ]* にマッチする部分で、カーソルの移動の際にも [^ﾞﾟ][ﾞﾟ]* が一文字として扱われる。delete キーを押すと [^ﾞﾟ][ﾞﾟ]* が一気に消えるが、backspace キーでは半角（半）濁点がひとつずつ消える。 Windows のメモ帳*1など昔ながらのアプリケーショ
UTF-8とUCS-4の相互変換をC/C++で書いた時のメモ。たぶんまた自分で読むので。 背景 文字のちょっとした正規化などの処理をしたいがiconvやICUなどの巨大なライブラリは使いたくないということがたまにある。嚴密な文字列処理をしたい場合にはそれらのライブラリを使った方が安全だし確実であることは言うまでもないが、ちょっとしたユーティリティを作るのにはちょっとオーバースペックである。 一方で、UTF-8文字列に対してはASCII用正規表現ライブラリを使えば検索や置換などの大抵の操作ができるので、自分でゴリゴリと変換処理を書かなければいけないことはあんまりない。 ただ、たまに自分で書きたくなることもある。ヨーロッパ系言語のアクセント記号を外したり、半角片仮名を全角片仮名にしたり、漢字の異体字表記を常用漢字に統一したりといった処理を一気にやりたい場合とか。そんな場合、各文字が可変長バイト
Tweet Twitterで見かけるようになったオバケのような動物の顔文字。 Yahoo知恵袋にこの顔文字についての問い合わせがあった。 ✔ 最近ʕ•̫͡•ʔとか༼⍨༽を見かけますが、これはどんな仕組みになっているのですか？ - Yahoo!知恵袋 質問の回答として当ブログの記事がリンクされているが、この顔文字は本当に合成用区分符号で構成されているのだろうか。 気になったので調べることにした。 実は、先の記事でUnicoder Liteを紹介した後、アプリの作者さんからメールを頂いていた。 そこにUnicoder Pro (App Store 450円)なら顔文字を解析できると書いてあったので試した。 簡単にできた。 1）IPA発音記号拡張 0295 2）一般句読点 2022 3）合成用区分符号 0361 4）合成用区分符号 032B 5）一般句読点 2022 6）IPA発音記号拡張 02
IVSというかUnicodeに見る日本政府のダメな感じ
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. UnicodeでのIVS (Ideographic Variation Sequence) の倒れそうなお話 IVS (要は異体字のサポートね) ってのはUnicode 5.1で導入されたもので、簡単に言ってしまえば、"渡辺"の"辺"っていろんなバリエーションがあるじゃない？で、それをどうにかできるものなんだよね。それだけ聞くと、おぉ！いいじゃない？って思うんだけど、まぁ、聞け "辺"の例は、この日経の記事にあるけど、これはわかりづらいから、もっと簡単な例をだす。 U+53DFの異体字一覧があるわけだけど、なんか気付かない?。同じ文字としか見えないものがダブってるだけだよね。 Adobe-Japan-1ってのは、その名の通りAdobeのフォントで定義さ
前置き おはミルキィ! ChromeFullFeedが公開停止になった話を前置きとして書いていたのですが, あまり関係がないのと, 長くなりそうになってきたので, 別の記事に分けました. http://d.hatena.ne.jp/Constellation/20110530/1306701693 概要 という前置きで. ECMAScriptと切っても切れない文字コード, UTF-16. iv / lv5はUnicode変換のためにICUに依存していたのですが, UTF-8 <=> UTF-16なら何とか自分でも書けるのではないかと思い, Unicode Converterを書きました. これでlv5の依存はlibboost, libgc (Boehm GC)に減りましたー. Unicodeの変換の教授, bugつぶしにおいて, id:masa141421356 さんに非常にお世話になりま
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2017年4月） 独自研究が含まれているおそれがあります。（2017年4月） 出典検索?: "東アジアの文字幅" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 「東アジアの文字幅」（英: East Asian Width）は、Unicode標準の附属書 (英: Unicode Standard Annex) の一つ。Unicodeに収録されている各文字の文字幅に関するヒントを与える East_Asian_Width 参考特性（英: informative property）を定めている。 東アジアのマルチバイト文字コード規格は必ずしも文字幅を
Unicode 6.0で導入されたU+1F3E9「LOVE HOTEL」が、ちょっとアレなのではないか、というご意見をいただいた。いや、それ、私(安岡孝一)が導入したわけじゃなくて、auのEzWeb絵文字492番とか、softbank絵文字E501とかが、ISO/IEC 10646に収録されつつあるので、Unicodeもサポートしたっていうだけのことなんだけど。 ただ「LOVE HOTEL」っていう文字の名前が、ちょっと国際的にアレなのは、確かにそうだったりする。けど、でもじゃあ、どういう名前ならいいのか、私には正直わからなかった。それに、分類も「Building and map symbols」じゃなくて、実は「Romance symbols」なんじゃないか、っていう気がするし…。
「著」と「着」が異体関係にあることは、10年以上前に出た「JIS漢字字典」初版のコラムを読んで知識としては知っていたのですが、新しい本にしか触れていない私は、実際にそのように使われている例を知りませんでした。 が、今現在現役で販売されている本の中にも、そういう例があることに気付きました。 岩波文庫で出ている中村元訳『ブッダのことば』(私の手元にあるのは2009年の第51刷)には、「執著」と書いて「しゆうじやく」とルビの振られている箇所が頻繁にあります。また、「愛著」に「あいじやく」とルビの振られている箇所もあります。 闇雲に「著」ばかりなのではなく、「落ち着く」という言葉の表記には「着」が使われていたりします。執着や愛着という語の表記については割合最近まで「著」が使われることが多かった、ということなのでしょうか。 手持ちの国語辞典を見てみると、大辞林第二版には「執著」の見出しはなく、広辞苑
Java 6が対応しているUnicodeのバージョンは4.1だそうです 【追記: 後で確かめたら4.0だそうです。私の思い違いでした _o_】。IVSに使われる面0Eのvariation selector (異体字セレクタ)はこのバージョンには既に入っています。なので、最新IVDの知識は期待できないとしても、variation selectorを無視するくらいの処理はひょっとしたら入っていてくれないかな、と思ってちょっと試してみました。 まず、Stringクラスの挙動から。まあ、何が起こるかは大体想像できるのですが、一応確認しておきましょう。 こんな風な文字列があるとします。 String nonIvs = "与太郎"; String ivs1 = "与\uDB40\uDD00太郎"; String ivs2 = "与\uDB40\uDD02太郎"; ここで、\uDB40\uDD00という
前にも書いたとおりAdaのStringは規格ではLatin-1*1ということになってまして、IO関係はWide_Text_IOであってもファイル名は軒並みStringですので、規格を鵜呑みにすると、Latin-1以外の文字が使われたファイル名を扱う方法が全くないとか、ワイド文字を識別子に使える規格なのに識別子を返す系の関数でLatin-1に収まらない文字がどうなるかはimplementation-definedだったりするとか、Wide_Characters.HandlingやWide_Wide_Maps.Wide_Wide_ConstantsがLatin-1の範囲外を扱わないと規格に明記されちゃってて仮に真面目にワイド文字を扱う実装をしたら逆に違反になってしまうとか、とにかく酷いとしか言いようがないわけです。 多バイト文字圏の人はAdaなんて使っちゃダメですマジで……。 とりあえず私の自
UTF-8-MAC とは[編集] UTF-8-MAC とは、Mac OS X に付属する iconv にて利用できる文字エンコードの一つで、 Normalization Form D (NFD) で符号化した UTF-8 のことを指します。 一般に UTF-8 とだけいった場合には、Normalization Form C (NFC) でエンコードされたものを意味します。 Unicode 標準では、NFC は正規結合(Canonical Composition)、 NFD は正規分解(Canonical Decomposition)として規定されています。 たとえば、「が」の字を NFC で表現すると U+304C (HIRAGANA LETTER GA) ですが、 NFD では U+304B U+3099 (HIRAGANA LETTER KA + COMBINING KATAKANA-
探したのだけど作っている人がいなかったので、いわゆるutf-8-macと呼ばれるエンコーディングを追加するEncode::Encodingをつくりました。 https://github.com/tomi-ru/Encode-UTF8Mac use Encode; use Encode::UTF8Mac; print Encode::encode('utf-8-mac', '蘄藭づけ'); use Path::Class; for my $entry (dir(".")->children) { my $filename = Encode::decode('utf-8-mac', $entry); } 反応みてPODちゃんと書いたらUPしようと思っている →POD書いた. PODの方が少し整理されているのでわかりやすいかもしれない。 https://github.com/tomi-ru/En
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
