UTF-8のバリデーションとモノイドと半群
この記事はUTF-8のバリデーションとオートマトンの続きです。 前回はUTF-8のバリデーションが8状態のオートマトン (DFA) で表現できることを見ました。状態と遷移を擬似コードで書けば次のようになるでしょう： -- 8つの状態 data State = START | TAILx1 | TAILx2 | TAILx3 | A | B | C | D -- 入力バイトに応じて次の状態を返す。次の状態が該当しなかったら Nothing を返す next :: Word8 -> State -> Maybe State +----+----+-----+----+ | a0 | a1 | ... | aN | 8ビット整数列 +----+----+-----+----+ | | | v v v +----+----+-----+----+ | m0 | m1 | ... | mN | モノ
MySQLで4バイトutf-8文字を扱う＆ファイルフォーマットを変更する - アナログCPU：5108843109
エントリをアップするの忘れてて今更感。 そもそも4バイトutf-8って何？ 絵文字 なんか特殊な漢字 が該当します。 4バイトutf-8文字の例 𣖔：𣖔木作（ほうのきざく、福島県の地名） 𣗄：𣗄代（たらのきだい、山形県の地名） 𩸽：ホッケ（おいしいさかな） 🍣：寿司（おいしい） 🍺：ビール（おいしい）参考文献 JIS第3水準漢字一覧表【全1259字】(JIS X 0213:2004) - fragment.database. JIS第4水準漢字一覧表【全2436字】(JIS X 0213:2004) - fragment.database. 「文字コード技術入門」こぼれ話: 「ほうの木作」を訪ねる - yanok.net MySQLで扱えないの？ 結論から言うと、文字セットを「utf8mb4_*」にすればOKです。 「utf8_*」では使えません。（INSERTしてみると、4
BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)
かつてWindowsでテキストファイルといえばシフトJIS形式のものが大半だった。しかし最近では、UTF-8形式のテキストファイルも普通に見かけるようになってきた。世の中はUTF-8が主流になりつつあると言っていいだろう。 しかし、WindowsでUTF-8を使うと、ちょっと困ったことがある。それは、エクスプローラーの検索欄などで用いるWindows Searchが、UTF-8にはしっかり対応していないのである。正確に言うと、Windows Searchはファイル先頭に「BOM」のあるUTF-8は認識して正確にインデックス化し、ファイルの全文検索が可能になるが、BOMのないUTF-8では正しくインデックス化できず、ファイルの全文検索はASCIIコードのみ可能で、日本語などの非ASCII文字では全文検索ができない。 同じ内容のテキストをUTF-8、UTF-8 BOM付き、UTF-16ビッグエ
長くて覚えやすくて複雑なパスワードとemojiの話
すみだセキュリティ勉強会2018その1での発表資料です。 http://ozuma.sakura.ne.jp/sumida/2018/03/22/38/
最速で日本語環境のMySQL Dockerコンテナを建てる方法 - Qiita
はじめに MySQLの公式Dockerイメージは文字コードがlatin1だったり、タイムゾーンがTSだったり、localeがPOSIXだったりと、日本語環境で使うにはかなり不自由な感じです。 以下のdocker-compose.ymlを使うことで日本語環境をすぐに建てることが可能です。 最速で日本語環境を使いたい人はこちらをベースにしてみてください。 ファイル 以下のような構成を想定しています。 # Dockerfile_MySQL FROM mysql:5.6 # Set debian default locale to ja_JP.UTF-8 RUN apt-get update && \ apt-get install -y locales && \ rm -rf /var/lib/apt/lists/* && \ echo "ja_JP.UTF-8 UTF-8" > /etc/lo
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
utf-8とiso-2022-jpのencodeとdecodeのTips - ベスパリブ
半角英数字をUTF-8でencode >>> s = "aiueo012" >>> b = s.encode("utf-8") >>> b >>> b'aiueo012'これをdecodeする >>> b.decode("utf-8") 'aiueo012' >>> b.decode("iso-2022-jp") 'aiueo012'半角英数字をutf-8でエンコードしたものは、iso-2022-jpでデコードしても問題ない 半角英数字 + 日本語文字をUTF-8でencode >>> ss = "aiueo012あいうkakikukeko" >>> bb = ss.encode("utf-8") >>> bb b'aiueo012\xe3\x81\x82\xe3\x81\x84\xe3\x81\x86kakikukeko'日本語は1文字3バイトの16進数に変換されます。 これをUTF-8
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ninja 2.0.0 released!