ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × « VALUE DOMAINからスタードメインにドメイン移管 MacのUSB 3.0が遅くなる問題(USB 2.0で認識される) » EmacsでBOM付きUTF-8を扱うときはutf-8-autoを使おう BOM付きUTF-8文章のファイルローカル変数(ファイル先頭の-*-で囲まれたアレ)のcodingはutf-8-autoとしておくのが良さそう。autoだとBOMの有無を自動判別し、よしなに扱ってくれる。 大抵はutf-8(強制BOMなし)かutf-8-with-signature(強制BOMあり)のどちらかで事足りるが、Emacsと別のアプリ間で同一ファイルを行き来させると、たまにBOMの処理がバッティングしてBOMが2個ついたり消えたりって事が起きるので……。まぁ、Perforceの事なんですけどね! PerfoceにBOM付きUTF-8のファイルを登録すると、どうもチェックアウト時にBOMを付加してるようで、それがEmacsのutf-8-with-signature処理と被って二重BOMになるのよね(´・ω・`)。かといって、ただのutf-8にすると何かの拍子にBOMが消えてしまい色々不都合なのよね(必ずしも消える訳でもないのがそれはそれで謎)。 BOM付きUTF-8とかこの世から死滅すればいいのに。ゲイツ、てめーの事だ!!BOM付きUTF-8は、CJK統合漢字の次に嫌いなUnicodeのクソ仕様だと思うわ。大体だね、16bitに全ての文字を収めようとしたUnicode自体がアルファベット圏人の浅はかな考えに起因するクソ規格であって、CJK統合漢字などという「見た目が同じだから」とかいう非漢字圏人の安易な発想に基づく仕様は、漢字圏各国の文化を破壊する人種差別的行為であると言わざるを得ないものであり(以下略 Comments 貴重な情報ありがとうございます。 BOM付きUTF-8は、CJK統合漢字の次に嫌いなUnicodeのクソ仕様だと思うわ。 まあまあ。 BOMつきUTF-8が糞仕様なことには同意します。でも、Unicodeの仕様書のどこかに「UTF-8にするならBOMはつけるな」とハッキリ書いてあったような気がするんです。つまり、そもそもBOMをつけること自体が、Shift_JISやWindows-125xとUTF-8とを識別するための苦肉の策、というのがボクの見解です。 以下、既にご存知だと思いますので「宗教講話」のつもりでお聞き流しください。 CJK統合漢字などという「見た目が同じだから」とかいう非漢字圏人の安易な発想に基づく仕様 違います(キッパリ)。 実は漢字の統合については、元々の仕様では32bit空間の中に各国のISO-2022-Xシリーズをそっくりそのまま移植する予定だったけれど、中国が強硬に反対して今の形になった、ということだそうです。参考:Wikipedia「CJK統合漢字」https://ja.wikipedia.org/wiki/CJK%E7%B5%B1%E5%90%88%E6%BC%A2%E5%AD%97(当該部分に「要出典」タグがついていますけど)。 ちなみに、今はBMPに加えて漢字専用に確保されたU+2xxxxの領域がほぼ埋まって、そのあとはU+3xxxxも丸ごと漢字関係に使うことが既定路線になっています。 それに、CJK統合に関しては、欧米人がメインだとは思いますが漢文学・漢字学の専門家が多数参加していたはずです。日本でロシア文学を研究している人がいるように、向こうにも漢籍とか平家物語とかを研究している人たちがいるわけですね。「歯」とか「亀」とかの部首が立てられていない、という批判はありますが、これは、「確かに起源としては固有のものなんだろうけど、今となっては、非漢字圏の人が中国語・日本語を学ぶときに混乱のもとになる」ということで、向こうでは別のメジャーな部首の中に入れるのが定石なんだと思います。(a Chinese-English Dictionary が手元にないので未確認ですが。) あと、統合してくれたおかげで、JIS X0208ベースで普通に書いた文章がそのまま中国でも読んでコピペできて、逆にGB 2312ベースで普通に書いた文章が日本でも普通にコピペできて、というありがたみのほうを重視すべきかと思います。今は異体字セレクタがU+Exxxx領域にありますし。 統合に関しては、ローマ字圏のほうが「ISO-8859-Xを別々に収録すること」への抵抗が強かったと想像します。 たとえば、紙データ・ビットマップデータにU+00E4の「ä」が書いてあったとしますよね。これはISO-8859の複数のセットで0xE4にマップされているわけですが(ISO-8859では同形の文字には、収録されていればどの枝番でも同じコードポイントが割り当てられています)、OCRにかけるときにはそのどれに割り当てるのよ、という問題が出てきます。 それにそもそもこの「¨」の記号、ゲルマン系で使うウムラウト(アではない別の音で発音することを示す記号)なのか、それともロマンス系で使うトレマ(前の母音と一緒にせずに単独のアとして発音することを示す記号)なのか、この文字単独では判然としませんし、LaTeXのソースとかでもウムラウトとトレマとは区別されませんので、原理的に区別不能なものは単一のコードポイントにしてしまえ、となるのは自然な流れだと思います。 …で、こちらは結局、HTMLのタグに chat とか chat とか書くわけですが、こちらのほうがボク的には糞仕様なように思います。 でわでわ。 1 | でるもんた・いいじま | 2016-06-24 22:52 | reply Name E-Mail Website 人間の証明として、ボックス内の全ての文字を入力してください。 この項目は空のままにして下さい:Preview Comment blog/2015/2015-02-16.txt 最終更新: 2015-02-16 12:51by Decomo