ソフトウェアの互換性と僕らのUser-Agent文字列問題｜Rui Ueyama
いろいろな環境で動くプログラムでは互換性のためにその場しのぎのことをしないといけないことがよくあるけど、歴史が積み重なってくると、アドホックな技の上にアドホックな技が積み上がる喜劇的な状態になることがある。こういう問題は認識するのは簡単だが直すことは誰にもできない。まさに僕がそのような体験をしたのでちょっと説明したい。 僕は仕事としてオープンソースのlldというリンカを書いている。リンカというのはコンパイラが生成したバイナリファイルをつなぎ合わせて最終的な実行ファイルやDLLを作成するプログラムで、知らない人も多いと思うけど、何をコンパイルしても最後にはリンカが動いている。lldは既存プログラムより何倍も速くてビルドが早くなるというので最近は結構人気が高まっていて、FreeBSDなどのいくつかのOSが全面的にスイッチしようとしたり、あるいは大規模プロジェクト（Chromeや、どうもFire
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
HTML文書は文字エンコーディングUTF-8でなければなりません - 水底の血
さよならレガシーエンコーディング。 文字エンコーディング宣言が存在するかどうかにかかわらず、文書のエンコードに使用される実際の文字エンコーディングはUTF-8でなければならない。 4.2.5.5 文書の文字エンコーディングを指定する - HTML Standard 日本語訳 Require utf-8 when specifying character encoding by sideshowbarker · Pull Request #3091 · whatwg/htmlにより、HTMLで使用できるエンコーディングはUTF-8のみとなりました。これにより、古いHTMLでは許容されていた、Shift_JIS、ISO-2022-JP、EUC-JP、UTF16LEといった文字エンコーディングは適合するHTMLではなくなりました。すでにNu Html CheckerでUTF-8以外の文字エンコー
C++のfilesystemライブラリが膨大すぎる
C++17の参考書はほぼ書き終えて、あとはfilesystemライブラリの解説を残すだけになっている。 EzoeRyou/cpp17book: textbook for C++17 ファイルシステムライブラリは、ext4とかbtrfsのようないわゆるファイルシステムに対するライブラリではなく、ディレクトリとファイルに対する操作を提供するライブラリだ。具体的にはファイルパスの文字列処理や、ファイルのコピーやリネーム、ディレクトリ構造のトラバースといった雑多なファイルシステム操作を提供する。 C++のファイルシステムライブラリは、原則としてPOSIX互換になっている。POSIXの規定するライブラリをモダンなC++風のライブラリとして設計したものだ。例えば、カレントディレクトリにあるファイルをすべて表示するプログラムは以下のように書ける。 #include <filesystem> #inclu
ú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
寿司とビールについて話し合いをしてきました | GREE Engineering
こんにちわ。せじまです。 さいきんの kernel について調べてたら、俄に Chromebook への興味が湧いてきたので、遅まきながら C302CA ポチってみました。わたしにとって人生初 Core M ということもあって、早く届かないかなと心待ちにしている今日このごろです。 はじめに MySQL5.7以前でおそらく最も有名な問題の一つに、Sushi-Beer issue of MySQL with utf8mb4 というものがあります。 忙しい人のために三行でまとめますと MySQL は character-set に utf8mb4 を指定すると、寿司やビールなどの絵文字を扱える。 ただ、Collation（照合順序） が utf8mb4_general_ci や utf8mb4_unicode_ci だと、絵文字を区別できない（寿司とビールの絵文字を区別できない）。 utf8mb
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
寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst
これまでのMySQLでよく問題になった、絵文字や日本語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少
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
MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
プログラミング言語における文字コードの話
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
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 も記しておきましたので、個別の字面とコード値の確認のためにご参照ください。
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
第4回 入国管理局正字
2012年7月、日本に3カ月以上在留する外国人は、在留カードの携帯が義務付けられた。在留カードには、氏名、生年月日、性別、国籍、住所などが記載されている。在留カードの氏名は、通常はアルファベット（ローマ字）大文字のみによる記載となるが、申し出により漢字で記載することもできる。 この在留カードの外国人氏名に使える漢字が、入国管理局正字（以下、入管正字）であり、2011年12月の「法務省告示第582号」で定められている。 入管正字は、漢字1万3285字を収録する漢字コードである。各漢字には4桁あるいは5桁の16進数が付けられており、本稿では、N+xxxxあるいはN+xxxxxで示すことにする。 1万3285字の内訳は、JIS X 0213の第一・第二・第三・第四水準漢字および「仝」の1万51字、JIS X 0212の漢字のうちUCS（Universal Multiple-Octet Coded
文字コード地獄秘話 第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ページを開く
