「ASCIIをUTF-8にして」それが『できない』ことを理解してもらえなかった話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
かつて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ビッグエ
Unicode 版美乳テーブルを探せ
美乳テーブルとは 「美乳テーブル」という物がある。 「EUC-JP の文章を Shift_JIS だと誤認識されない様に、EUC-JP 固有のバイト値を文章先頭付近に埋め込んでおく」という物。 具体的に、Shift_JIS には 0xFD と 0xFE が現れず、EUC-JP にはそれが現れるので、その値を含む文字コードを書いておこうという事で、その文字の集合に付いた名前。 “美” = 0xC8FE、“乳” = 0xC6FD。 各文字エンコーディングの事情 但し、これは EUC-JP での話。 一応、文章の先頭付近に日本語の文字を書いておくのは、他の文字エンコーディングでも認識のヒントにはなるけど。 逆に「Shift_JIS の文章を EUC-JP だと誤認識されない様にする」には、EUC-JP にはないバイト値の 0x80〜0xA0 を書けばいいんだろうけど、これは沢山ありそうだから、慎
アイヌ語仮名「ㇷ゚」に対する正規表現の罠
導入 アイヌ語は日本語と異なり、閉音節（子音で終わる音節）も存在するので、表記の際音素文字であるラテン文字なら、そのまま p, t, k, m, n, s, r などの子音文字を後ろの付ければ良いわけなので、アイヌ語ローマ字表記では、何も問題が生じない。しかし、元々開音節言語である日本語に特化したカタカナのような仮名文字で表記する際、鼻音 n は「ン」でなんとかなる（実はそれでもまずい事になっているけどここでは割愛する）が、p, t, k, m, n, s, r, h はどうしようもないので、特殊の捨て仮名（小書き仮名文字）を利用することになっている。 具体的には以下のような特殊仮名文字（通称 アイヌ語仮名）である。 ㇷ゚ -p ッ -t ㇰ -k ㇺ -m ㇱ -s ㇻ -(a)r, ㇼ -(i)r, ㇽ -(u)r, ㇾ -(e)r, ㇿ -(o)r お分かり頂けただろうか… 問題 r
誤解の多い「NFD問題とUTF-8-MAC問題」を解説する - macOSの濁点を含むファイル名の扱い - Qiita
はじめに macOS では濁点や半濁点が含まれるファイル名でたびたび問題が発生しています。この問題は NFD 問題と言われたり UTF-8-MAC 問題と言われることがありますが、必要な情報が正確に書かれているところは少なく、正しく解説してある所でも情報が古く（主に HFS+ 時代の話に）なっており、読むと逆に混乱してしまう場合があります。 macOS 標準アプリや誰かが作ったアプリであればバグが修正されるまで待つだけですが、自分が作ったアプリやシェルスクリプトなどではこれがどういう問題なのかを理解しなければバグが修正できません。この記事ではそれらを整理し直して、（可能な限り正確に）解説したいと思います。検証は macOS 15.3（補助的に 15.5）で行っています。 この問題は、Mac で作成した zip ファイルを Windows で展開したときに、濁点や半濁点を含むファイルに Wi
HTMLファイルで特殊記号を使う際、① は ①、© は © のように置き換えて書かないといけないものだと思いこんでいないでしょうか。 現代ではそれは誤解です。 UTF-8では特殊記号の文字参照は不要 そもそも環境依存文字とは、データを扱う機種・ソフトウェアなどの違い（文字コードの割り当ての違い）により表示に違いが出てしまう文字のことでした。 例えばShift_JISには © が含まれておらずそもそも保存できなかったり、 ① などの丸数字は含まれているものの、WindowsとMac OS（当時）の割り当ての違いにより正しく表示できなかったりしました。[1] しかし現在ではUnicodeによって文字コードは統一化されており、その問題はほとんど起きなくなっています。 近年では多くの場合 UTF-8 でファイルを記述すると思います。 HTMLファイルの文字エンコーディングが
先日以下の記事を書きました。 ここでUTF-8の最初の文字かどうかの判定を以下の自作した関数で実装していました。 const ( t1 = 0b00000000 tx = 0b10000000 t2 = 0b00000110 t3 = 0b00001110 t4 = 0b00011110 ) func isUTF8LeadByte(tmp byte) bool { if tmp&tx == t1 { return true } tmp >>= 3 if tmp == t4 { return true } tmp >>= 1 if tmp == t3 { return true } tmp >>= 1 if tmp == t2 { return true } return false }
utf8とutf8mb4の違い【MySQL】
（なぜ2種類あるのかはMySQLの歴史によるものらしいのですが、私はいまいち分かっていないので詳しく知りたい方はググってみてください･･。） 保存できる文字の違い これはつまり、UnicodeのコードポイントがU+FFFFを超える文字は、utf8では保存できないってことです。 例えば 崎（U+5D0E）←保存できる 﨑（U+FA11）←保存できる 😀（U+1F600）←保存できない 𩸽（U+29E3D）←保存できない ※ちなみにこの漢字はホッケと読みます みたいな感じ。 絵文字などを保存したい場合はutf8mb4を使わないといけません。 MySQLのutf8はUTF-8ではないのでは･･？ UTF-8は「世界中の文字を1つの文字コードで表そうぜ！」な文字集合であるUnicodeを表すための文字符号化方式の1つなわけですが 本来UTF-8は、1～4バイトで文字を表すルールです。 なので、
UTF-8からSJISに変換する時にはShift-JIS系エンコードの種類だけじゃなくてUNICODE正規化も気にしないとダメという話 利用シーン UTF-8で記述されたテキストをShift-JISエンコードに変換する機会はあります。 UNICODEで表現できる文字の種類の方がShift-JISに比べて圧倒的に広いのですべての文字が変換できるわけではありませんが、「これは変換できてよかろう」というものまでこぼれ落ちるケースは多数あります。 以下こぼれ落ちる例とその対応を示します。 サンプルコード まずはサンプルコード。 rubyで記述していますが、原理はどの言語でも同じです。 str = "あ～あ①髙島屋パバぱ" sjis = str.encode(Encoding::Shift_JIS, :invalid => :replace, :undef => :replace) File.
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
UTF-8のテーブル(MySQL5.6)に竈門禰󠄀豆子が格納できない問題を調べてみた - Qiita
BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)
「HTMLでは環境依存文字（①や©など）を文字参照にしなければいけない」という誤解と、本当に置換すべき文字
Goの標準のutf8.RuneStart関数がエレガントすぎる
UTF-8からSJISに変換する時にはShift-JIS系エンコードの種類だけじゃなくてUNICODE正規化も気にしないとダメという話