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ビッグエ
ヤブ on Twitter: "これと戦ってる（白目 －（全角ハイフンマイナス） -（半角ハイフンマイナス） ‐（全角ハイフン） −（全角マイナス） ‒（フィギュアダッシュ） —（全角ダッシュ） –（二分ダッシュ） ―（ホリゾンタルバー） ー（全角長音） ｰ（半角長音） ─（罫線） ━（罫線） 一（いち）"
これと戦ってる（白目 －（全角ハイフンマイナス） -（半角ハイフンマイナス） ‐（全角ハイフン） −（全角マイナス） ‒（フィギュアダッシュ） —（全角ダッシュ） –（二分ダッシュ） ―（ホリゾンタルバー） ー（全角長音） ｰ（半角長音） ─（罫線） ━（罫線） 一（いち）
絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
「ユニコード」で予期せぬ目に遭った話 - 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. 同じコードポイ
Mac OS Xの濁点ファイルがやってきた - miauのブログ
一ヶ月ほど前の話。Mac OS X を使っている人から Skype で送られてきた Excel ファイルが WinMerge でうまく開けなくて。「xdoc2txt が .xlsx に対応してない？いやそんなはずは・・・」とかいろいろ調べてて、ふと思い立って dir すると こんな感じと。今まで仕事で Mac OS X を使っている人には出会ったことがなかったので、「これが噂の濁点問題かー」とちょっと嬉しくなって、このファイルをいじりまわして遊んだのでそのお話。 簡単に現象＆用語を説明 詳しいことは Unicode正規化 紹介マニアどらふと版: Mac OS X におけるファイル名に関するメモ(NFC, NFD等) あたりを読んでいただくのが確実なんですが、今回問題になった濁点まわりに限定してかいつまんで説明すると・・・。 Unicode で「が」という文字を表したい場合、以下の二種類の表
日本語名のファイルを直接アップロード・ダウンロードさせる時の諸問題
実務系のWebシステムを作っていると、ファイルを日本語のファイル名のままアップロードを受け付けたり、ダウンロードして保存した時に分かりやすいように日本語ファイル名でダウンロードさせたいという希望がよくある。 お気持ちはよく分かるのですが〜、これは実は結構大変な場合があるので、その辺りの事情を解説します。プログラミング言語は私は Perl を使っています。 日本語名ファイルのアップロード・ダウンロードの際に考慮すべき問題 日本語名ファイルをアップロード・そのファイル名のまま保存・ダウンロードさせる時に、開発者が考慮しておかなければならない点があります。せっかちな人と早く終わらせて帰りたい人は、末尾のまとめだけをご覧下さい。 アップロード時のファイル名 アップロード時のファイル名は、ブラウザが送信してきます。通常はファイルをアップロードさせるページ（＝送信フォーム）と同じ文字コードでファイル名
文字コード地獄秘話 第1話：Unicodeにおける全角・半角 - ALBERT Engineering Blog
ごあいさつ 皆様はじめまして、文字コードおじさんです。細々とカメラ屋を営んでおりましたが、エンジニアとしての技量を評価され、ALBERTのシステム開発・コンサルティング部で働くことを許されました。特技はサーバーの統廃合です。 今回は最初ということですが、Unicodeにおける全角・半角の取り扱いについて触れてみようと思います。なお、さも連載するかのように第1話と銘打っていますが、上層部の無慈悲な裁決によっては1話打ち切りもありえますので、その際はご容赦ください。 固定観念を捨てよう 「全角50文字、半角100文字まで」といったような文言を見かけたことがあると思います。 特にUnicode以前のレガシーな処理系では全角文字に2バイト、それ以外は1バイトという割り当てが慣習となっていました。 このため、「全角=2バイト文字、半角=1バイト文字」という観念が世間に定着しているのが現状です。 しか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
全角チルダ問題