Practical Tips for Bootstrapping Information Extraction Pipelines
2003年には「プレーンテキストなんてものは全く存在しない」と言われ、テキストの解読には文字コードの情報が必須となっていました。しかし、2023年になるまでの20年の間に絵文字などのおかげでUnicodeの利用率は98％へと到達し、再び文字コードを気にせずにすむ時代がやってきています。そんな時代において、正しくUnicodeを使うために必要な知識をエンジニアのニキータ・プロコポフさんが解説しています。 The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!) @ tonsky.me https://tonsky.me/blog/unicode/ Unicodeの歴史と利用率の推移をまとめたグラフは下図の通り。2000年代後半から急速に普及が進んでいったこ
はじめに これらの横棒、コンピュータにとっては全て違うのですが 見分けがつくでしょうか？ -˗ᅳ᭸‐‑‒–—―⁃⁻−▬─━➖ーㅡ﹘﹣－ｰ𐄐𐆑 郵便番号、住所、電話番号など、横棒が使われているデータを扱うとき、 人が入力したデータや購入したデータであると、同じ記号が使われていないことはよくあることです。 090-1234-5678 090᭸1234᭸5678 090‑1234‑5678 090−1234−5678 これらの電話番号の文字列も phone_no_list = ['090-1234-5678', '090᭸1234᭸5678', '090‑1234‑5678', '090−1234−5678'] # 文字をUnicodeコードポイントに変換 for n in phone_no_list: # 文字列の４番目の横棒の文字コードを見てみる print(n[3], ord(n[3]
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
This story starts with a confession: I was afraid of Unicode for a long time. When a programming task required Unicode knowledge, I was searching for a hackable solution for the problem, without a good understanding of what I was doing. My avoidance continued until I faced a problem that required detailed Unicode knowledge. There was no way to apply situational solutions. After putting in some eff
Bizreach Tech Beer Bashでの発表資料です
(訳注：記事をご覧の環境によって文字列が正しく表示されない場合がございます。) 投稿が遅れたFriday Q&Aにようこそ。Swiftユーザの最大の不満の一つに、 String APIがあります。Swiftの文字列APIは難しく鈍いため、多くのユーザが他言語の文字列APIのようであればと感じているのではないでしょうか。今日はなぜSwiftの String APIがこのように設計されているのか（少なくとも私がなぜそう設計されていると思うのか）を説明します。そして、基本的設計の観点から見て、なぜこれが最高の文字列APIなのかを説明します。 文字列とは何か 説明に入る前に、まず基本的な概念を構築しましょう。文字列について、漠然とは理解しているものの、あまり深くは考えないものなのではないでしょうか。文字列をじっくり考えることで、どのようなことが起きているのか理解することができます。 概念としての文
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
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,
文字コードについて調べたことや実験したこと， テストプログラム，データファイルなどを随時掲載する予定です． ただし筆者の理解不足や誤解により誤りがあるかもしれませんので， ご利用は自己責任で． このページの主な更新は Blog でお知らせします． 表示確認ブラウザ：FireFox 22.0，IE8． ０．目次 シフトJIS Shift_JIS と Windows-31J (CP932) の違い シフトJIS ２バイト文字の判定 謎の検索ワード集 (シフトJIS編) 「Shift_JIS(SJIS，Windows-31J，CP932) ３バイト文字」 「Shift_JIS(SJIS，Windows-31J，CP932) サロゲート(ペア)」 「UTF-8 4バイト文字 Shift_JIS(SJIS，Windows-31J，CP932) 変換」 「Unicode(UTF-8，UTF-16) か
前回の記事の続編です。 HFS+ における Modified NFD Apple が OS X でファイルシステムとして採用しているHFS+では，ファイル名を原則としてNFDで分解して保持するようになっています。 2種類の「が」は分解形で統一される たとえば，ユーザが が.txt（「が」はU+304Cの1文字）というファイル名でファイルを保存しても，ファイルシステム上は が.txt（「が」は U+304B U+3099 の合成文字）として保存されます。 実際，が.txt（「が」はU+304Cの1文字）としてファイルを保存した後，Finderでファイル名変更モードに入り，「が」という文字をコピーすると，U+304C ではなく，U+304B U+3099 という2文字がコピーされるのが確認できます。 → か(U+304B) + 結合用濁点(U+3099) がコピーされる CJK互換漢字を置き
これは，こちらのサイトによると， 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
はじめに 二人を最初から一つにしておけば、何も問題など起こらなかったのだ。 一つのものを二つに分けたその時から、長い物語が始まる。 おや？また会いましたね。どうも、文字コードおじさんです。 もう半年近くも前になりますが、前回の投稿はだいぶ反響があったようで驚いております。ありがとうございます。 今回も文字コードネタですが、Unicodeにおける結合文字列を取り上げてみようと思います。 高度に発達した文字コードは地獄と見分けがつかない 次の画像はTwitterの投稿フォームですが、おかしな点があります。わかりますか？ そうです。4文字しか入力していないはずなのに 5文字分とカウント されていますね。おかしいと思いませんか？あなた？ 改行とかスペース入れてるんじゃねーだろうな？とか言わないで下さいね？ さらに次の画像を見てみてください。 こちらは4文字とカウントされていますね。先のものとは一体
The way JavaScript handles Unicode is… surprising, to say the least. This write-up explains the pain points associated with Unicode in JavaScript, provides solutions for common problems, and explains how the ECMAScript 6 standard improves the situation. Unicode basics Before we take a closer look at JavaScript, let’s make sure we’re all on the same page when it comes to Unicode. It’s easiest to th
表題のような感じなのですが、これまで理解が曖昧だったUnicodeとか何とかが今までよりわかったのでメモ。 尚、こちらのサイトを非常に参考にさせていただきました。 Unicodeについて コードポイントとは 文字コードとは 今日覚えた単語その一。Unicodeに限らず、文字をコンピュータ上で表現する際、1つの文字に1つの数値を対応させるわけですが、この文字に対応する数値をコードポイントというそう。 いままでASCIIコードとか呼んでました。 そして、文字と数値の割り当てのルールのことを「文字コード」と言うんだそうです。 Unicodeとは から UTF-XXは何が違うんじゃ という話へ Unicode誕生 文字コードが乱立したため、あるコードポイントで表現される文字が、文字コードによって、てんでばらばらという状況に。 ややこしいから、ひとつの統一した文字コードをつくろう！ ということで「U
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
