漢字のようで漢字でないUnicodeの「康熙部首」と「CJK部首補助」｜TechRacho by BPS株式会社
きっかけ 以下のツイートで「埼玉埼⽟問題」と康煕部首を知りました。 「埼玉」と「埼⽟」の話。unicodedata.normalize('NFKC', '「埼玉」と「埼⽟」') でいけそう https://t.co/kte0sxDvZT — Haruhiko Okumura (@h_okumura) July 11, 2020 康煕部首とは ⼀⼁⼂⼃⼄⼅⼆⼇⼈⼉⼊⼋⼌⼍⼎⼏⼐⼑⼒⼓⼔⼕⼖⼗⼘⼙⼚⼛⼜⼝⼞⼟⼠⼡⼢⼣⼤⼥⼦⼧⼨⼩⼪⼫⼬⼭⼮⼯⼰⼱⼲⼳⼴⼵⼶⼷⼸⼹⼺⼻⼼⼽⼾⼿⽀⽁⽂⽃⽄⽅⽆⽇⽈⽉⽊⽋⽌⽍⽎⽏⽐⽑⽒⽓⽔⽕⽖⽗⽘⽙⽚⽛⽜⽝⽞⽟⽠⽡⽢⽣⽤⽥⽦⽧⽨⽩⽪⽫⽬⽭⽮⽯⽰⽱⽲⽳⽴⽵⽶⽷⽸⽹⽺⽻⽼⽽⽾⽿⾀⾁⾂⾃⾄⾅⾆⾇⾈⾉⾊⾋⾌⾍⾎⾏⾐⾑⾒⾓⾔⾕⾖⾗⾘⾙⾚⾛⾜⾝⾞⾟⾠⾡⾢⾣⾤⾥⾦⾧⾨⾩⾪⾫⾬⾭⾮⾯⾰⾱⾲⾳⾴⾵⾶⾷⾸⾹⾺⾻⾼⾽⾾⾿⿀⿁⿂⿃⿄⿅⿆⿇⿈⿉⿊⿋⿌⿍⿎⿏⿐⿑⿒⿓⿔⿕ KangXi Radica
文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！ 文字コードには、どのような種類があり、それぞれどのような意味を持つのか、といった、文字コードの基本的な概念、従来の文字コードを紹介し、現在のUnicodeの構成を概説し、プログラミングにおいて注意すべき箇所をいくつか取り上げます。 ソフトウェア開発に携わる方の多くは、何らかの形で文字コードに触れることがあるでしょう。文字や記号をコンピュータ上でデータとして扱うには、文字コードの知識が必要不可欠です。 本稿では、書籍『プログラマのための文字コード技術入門』の著者である矢野啓介さんが、知っておきたい基礎知識を分かりやすく解説します。 文字コードとは？ Unicode以前の文字コード Unicodeとその主な符号化形式 UTF-16 UTF-32 UTF-8 Webで文字コードを指定する仕組み
Ctrl-[ が Esc になる理由 - Humanity
理由 SHIFT キーはキーコードを -0x20、CTRL キーはキーコードを -0x40 する機能 全文 vim-jp.slack.com の #random から。 heavenshell [10:08 AM] TouchBar MBP にしたら強制的に C-[ になるので、オススメです！ようやく矯正できた。 mattn [10:09 AM] 人間の方が最適化されている yoshitia [10:12 AM] Escが物理的にない状況用にデフォルトでCtrl-[ 用意してるのすごい mattn [10:14 AM] いや、用意した訳ではないです。 SHIFT キーはキーコードを -0x20、CTRL キーはキーコードを -0x40 する機能なのです。 なので `[` つまり 0x5b は 0x1b になる。 0x1b = ESC 同様に CTRL-H は H が 0x48 なので 0x
ゼロ幅文字にエンコードした隠し情報で、文書をリークしたメンバーを特定 | 秋元@サイボウズラボ・プログラマー・ブログ
とある会員制掲示板からの文書の流出に困った運営者が、ユニコードの見えない文字「ゼロ幅文字(Zero-Width characters)」を使って流出させたユーザーを特定した、という話が出ていました。 数年前の話、Tom さんが所属していた競技ビデオゲームのチームでは、ログインが必要なプライベートの掲示板を使って連絡していました。その掲示板に書かれた秘密情報や戦術に関する重大アナウンスなどがしばしば掲示板外のウェブにコピペされ、チームにとって大きな問題となっていたそうです。 外部ユーザーの攻撃で中身が漏れたというよりは、メンバーの誰かがコピーしているのでは、と考えた Tom さんは、当時気になっていたユニコードのゼロ幅文字を使ったトリックを仕掛けたそうです。 ユーザーを特定する情報を、見えない文字に変換して埋め込む ログイン中のログインユーザーのユーザーIDを、一定のルールによってゼロ幅文字
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
únicode is hard
In the last couple of months, I've been seeing the ú symbol on British receipts. Why? 1963 - ASCIIIn the beginning* was ASCII. A standard way for computers to exchange text. ASCII was originally designed with 7 bits - that means 128 possible symbols. That ought to be enough for everyone, right? Wrong! ASCII is the American Code for Information Interchange. It contains a $ symbol, but nothing for o
「ユニコード」で予期せぬ目に遭った話 - moriyoshiの日記
自分の知らないCJK Ideographのバリエーションがまだあったことに戦慄している pic.twitter.com/kUlyRLDDTM— moriyoshit (@moriyoshit) March 9, 2017 などというツイートをしたところ、思ったより反響があったのでまとめておく。 上記ではあいまいに「バリエーション」などと書いたが、Unicodeとそれを扱う環境においては、バリエーションと一口に言っても次のような状況がある。 意味論的に等価な異なる字形の集合 同じ字形で異なるコードポイントの集合 aは結構なじみ深いと思う。 a-1. 異なるコードポイントにそれぞれ異なる字形が割り当てられているもの 例: 「東」(U+6771) ⇔「东」(U+4E1C) 「斉」(U+6589) ⇔「齊」(U+9F4A) 「高」(U+9AD8) ⇔「髙」(U+9AD9) a-2. 同じコードポイ
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
Programming with Unicode — Programming with Unicode
Versions latest Downloads On Read the Docs Project Home Builds Free document hosting provided by Read the Docs.
Unicode Collation Algorithm - tmtms のメモ
文字コードは面白いね！ わーい！ たのしー！ 🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾 MySQL で utf8mb4_unicode_ci コレーションを使用した時に「🍣」=「🍺」や「ハ」=「パ」になる問題があります。 この utf8mb4_unicode_ci ってなんぞや？と思ってマニュアルを見てみると、 MySQL は、http://www.unicode.org/reports/tr10/ で説明している Unicode 照合順序アルゴリズム (UCA) に従って xxx_unicode_ci 照合順序を実装します。照合順序は、バージョン 4.0.0 UCA 重みキー (http://www.unicode.org/Public/UCA/4.0.0/
MySQLの文字コード事情 - tmtms のメモ
この前 MySQL Casual に登壇して、「MySQLの文字コード事情」と称して発表してきました。 終電の都合で途中退席しましたが楽しかったです。また機会があれば参加したいです。 発表スライドはこちら MySQLの文字コード事情 2017版 from Masahiro Tomita www.slideshare.net 以下、補足のような何か。 「Charset≒エンコーディング (MySQLに限らない)」 英語版のWikipediaでもcharsetは Character encoding にリダイレクトされます。 自分がcharsetという用語に出会ったのはおそらくメールのContent-Typeヘッダが初めてだったと思います。 今ではメールだけではなくHTTPのヘッダでも使用されています。 なお、CharsetはInternet Assigned Numbers Authorit
Rubyの内部文字コードはUTF-8ではない...だと...？！｜TechRacho by BPS株式会社
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
Perlにおける日本語文字化け対策の私的まとめ - the code to rock
環境づくり utf8プラグマ openプラグマ binmode関数 標準入出力もopenプラグマにまとめる まとめ 付録 Perlで日本語のテキストを処理しているとけっこうな割合で文字化けにハマる。 近いことについては以前ここでみっちり書いたが、 note103.hateblo.jp どうもその後、自分はbinmode関数やopen関数、およびutf8やopenプラグマについて理解が怪しいな、と思ったのでいろいろ調べつつ現時点での認識をまとめてみる。 環境づくり まずはサンプルケース的に、文字化けしがちな状況を作る。 素材データとして、以下の内容をエンコーディングUTF-8のテキストファイルにsource.txtという名前で保存。 りんご hello 犬 1234 ネコ 次に、そのデータをopen関数で読み込み、split関数で切り刻んで標準出力および書き込み用ファイルresult.txt
プログラミング言語における文字コードの話
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
Gitで、事前にUnicodeの結合を行う - Faith and Brave - C++で遊ぼう
WindowsとMacでリポジトリを共有していると、日本語ファイル名の問題が出てきます。「ボタン.png」のようなファイルがあった場合、Windowsのファイルシステムでは「ボ」はひとつのコードポイントとして扱われますが、Macのファイルシステムでは「ホ」と「゛」が分解されます。 これは、Unicodeの結合文字に対する正規化の扱いが、OSのファイルシステムごとに異なるということです。 これによって、Gitを使ってWindowsで「ボタン.png」をコミットし、Macでそのコミットを持ってくると、「ボタン.png」を削除して「ホ゛タン.png」を追加するような動作になるのです。 この問題を解決するために、Mac OSでのGit実装には、core.precomposeUnicodeという設定があります。configファイルで以下のようになっていた場合、 [core] … precompose
Python 3誕生の理由 ― つまり、なぜunicode/str/bytesの仕様は変更されたのか | POSTD
12月、私は PuPPy(the Puget Sound Python users group)の会合でQ&A セッション を行いました。そこでようやくPython 3が誕生した理由と、string/bytesに関する全てを説明しました。Python 3が作られた理由をユーザはもう知っているはずだと思っていたので、私はこの説明で称賛を得たことに、ちょっと驚きました。後で考えてみると、Pythonに詳しい人もそうでない人も含めて大多数の人が、その理由を探すように言われたり、好奇心からその理由を探し当てられるなどと考えた私が愚かでした。ですから、このブログの記事で、Python 3が存在する理由をわかりやすく説明します。後方互換性の全くない unicode / str / bytes の仕様変更は、Python 3のコードの移植の中でも本当に難解な部分ですので、私たちがその仕様変更を選択した理
Unicodeで「漢字」の正規表現 – ものかの
改訂：2017/07/22 Unicode 10.0に合わせて書き直し。正規表現を簡易にしようとしてやりすぎていたのを修正。 改訂：2023/03/21 U+30000以降を追加。InDesignの正規表現を追記。 正規表現で漢字の範囲指定をする場合、Unicodeではどうするかが悩ましいところです。 Unicodeの漢字の範囲として [一-龠] にしている例を見かけます。しかしこれは旧規格JIS X 0208の漢字が含まれる範囲をUnicodeの中から切り出しているだけです。互換漢字ブロックをまるごと取りこぼしているので、WindowsのシフトJIS（CP932）の拡張漢字に当たるものが含まれていません。現規格JIS X 0213の第３・第４水準漢字も考慮されていません。簡易な範囲指定だとしても、新常用漢字の「𠮟」が含まれておらず、今から見るとあまりに時代遅れです。 Unicodeのす
Unicode 内のそれぞれの文字種の範囲 - みちのぶのねぐら 工作室 旧館
郵便番号データを利用するサンプル を作っている最中に気になって、ひらがな、カタカナなどの文字種の Unicode の文字コードの範囲を調べました。 資料として http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/SHIFTJIS.TXT を使います。 “OBSOLETE” となっていますが参考にはなります。これを表計算のシートに貼り付けて Unicode 順に並べ替えるとわかりやすいです。以下の説明には unicode.org の対応する “Code Charts” の URL も記しておきましたので、個別の字面とコード値の確認のためにご参照ください。
文字コード地獄秘話 第1話：Unicodeにおける全角・半角 - ALBERT Engineering Blog
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
Unicodeを斬りたい
※2014/4/17 記事の内容に関していくつか訂正させていただきました。 ご指摘いただいた皆様ありがとうございました。 誤字脱字を修正しました。 ソースコードの間違いを修正しました。 BOMの記述を分かりやすい表現に修正しました。 合字に関する記載を追記いたしました。 こんにちは。 Yahoo! JAPANで通知プラットフォームの開発をおこなっています佐々木海（@Lewuathe）と申します。 普段は全社向けのPush通知プラットフォームやメール配信プラットフォームの開発、保守をしています。通知というのはPush通知にしろ、メール配信にしろ基本的には「テキストデータ」を送ることになります。プラットフォーム内ではこれらのテキストに対してさまざまな処理をかけることになるのですが、さすが日本語といったところでしょうか、一筋縄ではいかない部分が出てきました。具体的にはUTF-8でエンコーディング
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
