TL;DR Shift_JISにしただけでコンパイラが通らなくなる恐ろしい事件とその回避法について。 \ (¥)のASCIIコードは0x5c 表、能は良くない UTF-8は神 2023/12/06追記 誤りがあったので訂正します。こんな読まれると思ってなかったので正直ちょっとびっくりしていますが、いろいろコメントありがとうございました。（ツイート等全て拝見しました。） Shift_JISが悪いわけではない（デフォルトのエンコーディング設定の問題）→追記しました UTF-8にはUTF-FSSという仕様でこの問題が回避されている→マジでタメになる知識ありがとうございます OSによってデフォルトのエンコーディング設定が異なるせいで、デフォルト環境での動作がOSにより異なる→なるほど？（調査中） CRLFとLF問題では→なるほど？（調査中） そんな問題何を今更→UTF-8が出てから生まれたからです
こんにちは。徒然なるままにTweetを眺めていたら、Tanakaさんがこのようなことを呟いていました。 そういやRustのStringにreverseメソッドないなと思ったけど、まあよく考えたらUTF-8で文字逆転させるとか地獄のような話になるしそもそも長さが変わるケースとかあったりしそうで怖いわな･･･(´･_･`) — Hideyuki Tanaka (@tanakh) May 1, 2021 背景等はよくわからないですが、文字列の反転というのは確かに難しい問題ですし、どう難しいのかというのを、ちょっと真面目に考えて解説してみました。というノートです。 本文での表記についてこれから文字とそのバイト表現の話をしていきます。文字のエンコードの方式で同じ数値でも色々意味が分かれてしまいますので、本文では以下のように表記することにします。 Unicodeコードポイント（以下、単にコードポイント
Ruby 2.7 アドベントカレンダーの19日目の記事です。 qiita.com Encoding::CESU_8 追加 Fiber#raise 追加 FrozenError#receiver 追加 Encoding::CESU_8 追加 自分は知らなかったのですが、Unicode の文字エンコーディングに UTF-8 の亜種で CESU-8 というのがあるらしく、2.7 でそれに対応しました。 通信用語の基礎知識 より: UTF-8の亜種の一つで、Oracleが使っている不届き千万な仕様の一つ。 本来UTF-8(RFC 2279 [外部リンク] )では、サロゲートペアは適時解釈してから符号化せねばならない。 しかしこのCESU-8は、サロゲートの各ペアを機械的にUTF-8に変換するのみであり、supplementary characterは6バイトで表現される。これはUTF-8の仕様から
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一
Windows Experience Blogの告知などでは一切言及されていないようだが、Windows 10 Redstone 4のInsider Previewでは、システムロケールの変更を行うダイアログに「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」（英語では'Beta: Use Unicode UTF-8 for worldwide language support'）というチェックボックスが追加されている。手もとにスナップショットが残っていた最古のRS4ビルド（17004）ですでに存在していたので、正確にいつ追加されたのかは不明。 このチェックボックスをチェックして再起動すると、Build 17035時点では以下のような動作が確認できた。 圧縮 （zip形式） フォルダーにファイル名がUTF-8で保存されるようになった。これに伴い、シフトJISに含まれな
ついにマイナンバー制度の情報連携と、マイナポータルの試行運用が、7月18日に始まった。情報連携を担うのは、国の機関や自治体が個別に保有している住民個人情報を連携させる「情報提供ネットワークシステム」である。制度としては試行運用だが、マイナンバー制度の基盤を支えるシステムとしては本格稼働したことになる。もうひとつのマイナポータルは、住民が自身の登録情報や情報連携の履歴を確認できるインターネット上のサイトであり、正式な名称は「情報提供等記録開示システム」という。 「ついに」と書いたが、各種メディアでの扱いはこじんまりとしたものだ。2015年秋にマイナンバーの通知カードの発送が始まったときや、2016年初めにマイナンバーカードの交付が始まったときは、テレビなどでも盛んに報道されたが、今回は総じてひっそりとしている。 通知カードは全国民に配布されたし、マイナンバーカードは申請が必要だが実体があるカ
Ruby製のツールを扱う際にデフォルトエンコーディングがUTF-8じゃなくて人生厳しい場合がある やりたかったこと 自分が使ったわけじゃないんですけど、compassを使うときにSASSファイル等はUTF-8なんだけどWindows環境でcompassを使ってビルドしようとするとデフォルトエンコーディングの違いからWindows-31Jじゃないプギャーと言わるらしい。 一般的なやり方と回避方法 当然ググったりしてみるんですけど、そうするとターミナル上でset LANG=ja_JP.UTF-8したり環境変数にLANGを登録しておけば良いと書いてある。 だがしかし、どうもRuby1.9系ではそれで対応できるらしいけど、Ruby2.0系では対応できないようだ。 追記 コメント欄で教えてもらいましたが、set RUBYOPT=-EUTF-8でエンコーディングを指定すれば良いのでした*1。そっちのほ
私の手元に「Buffalo WLI-UC-AG300N」というUSB無線LANアダプタがあるのですが、Macの「システム情報」で見ると製造元が「敇瑭步挮浯䩟」となっていることに気づきました。 バッファローとかメルコとか書いてあるなら分かりますが、少なくとも日本語ではありませんし、簡体字なり繁体字なりだとしても不自然に思えます。となると、一体何が表示されているのでしょうか？文字コード警察的な意味で興味を持ったので、調べてみました。 謎解き(1) 何が書いてあるのか この記事の執筆時点では「敇瑭步挮浯䩟」でGoogle検索しても同じ無線LANアダプタの情報が1件見つかるだけで、そんなメーカーは地球上に存在しなさそうなことがわかります。 ネット上にも情報が無いときに頼れるのは自分の直感だけです。そこで、私は謎の漢字列をUTF-16にしてみることにしました。 上記PHPファイルをUTF-8で保存し
日本語を扱える文字コードにはメジャーなものでUTF-8, Shift_JIS, EUC-JP, UTF-16, ISO-2022-JP(JIS)などがあります。 近年UTF-8を使う傾向が強まっていますが、今でもShift_JISは多用されています。 ところがこの「Shift_JIS」にはいくつかバリエーションがあります。 Shift_JIS系1バイト文字 Shift_JIS系の1バイト文字は、以下のようになっています。00～1F, 7Fは制御文字、20～7Eはアスキー文字です (SPACEはアスキー文字としても制御文字としても扱われることがあります)。 ここはUTF-8でもEUC-JPでもJISでも共通です。 A1～DFは半角カナが割り当てられています。半角カナを(エスケープシーケンス無しで) 1バイトで表現できるのはShift_JIS系文字コードの特徴です。 下位4ビット 012345
URI.decode まわりを見ていて、いい勉強になったので記しておきます。 ざっくり言うと Ruby 2.3.0 でマルチバイト文字を含んだ URL を URI.decode でうまくデコードできなかった場合は CGI.unescape などの利用を検討されると良いと思います CarrierWave (執筆時 0.10.0 が最新) を Ruby 2.3.0 と組み合わせた際に、Fog 経由でのファイル名を期待したエンコーディングで取得できない問題について CarrierWave の HEAD ではなおったと思います URI.decode (URI.unescape), URI.encode (URI.escape) は非推奨 URI::Generic#to_s によるエンコーディングの違い URI::Generic#to_s について、Ruby 2.2.4 と Ruby 2.3.0 で
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
9. 参考) 確かめかた (Windows の場合) • 確かめたい文字をコピーします。 • WordPad を起動し、コピーした文字を貼り付けます。 • 確かめたい文字を一文字選択し、ALT + X を押します。 • コード (UCS-4) が表示されます。 • U+301C が波ダッシュ • U+FF5E が全角チルダ 10. 基礎知識1) チルダとは何か？ • こういうやつらしい。 ÃÕÑ • 鼻音に関する音をあらわす、ダイアクリティカルマークの一種 • ダイアクリティカルマークってこんなやつら (よくしらない) À Á Â Ä Å Ă Ą Ā http://ja.wikipedia.org/wiki/%E3%83%80%E3%82%A4%E3%82%A2%E3%82%AF%E3%83%AA%E3%83 %86%E3%82%A3%E3%82%AB%E3%83%AB%E3%83%9E%
先日の記事 いまさらgrepが10倍高速化したのはなぜか が思わぬ閲覧数を稼いでしまい、トルコ語の知識を日本に広めるのに大きな貢献をしたような気がしますが、みなさんいかがお過ごしでしょうか。 実は先日の記事を書いた時にはすでに2.18がリリースされてたのだが、今回は2.17のときと違って日本の大手メディアが取り上げてなかったので、ついつい見落としていた。しかし実は2.18でも大きな変更が！！ リリースノート抜粋： grep -i in a multibyte, non-UTF8 locale could be up to 200 times slower than in 2.16. [bug introduced in grep-2.17] なんということでしょう。-iオプションでUTF8のときは2.17で10倍速くなっていたのだが、それ以外のマルチバイトロケールのときは200倍遅くなって
Mechanize#get などによって取得されたリソースは、Mechanize::Page のインスタンスとして返される。その際の Mechanize::Page の初期化プロセスの中で、取得したリソースの文字エンコーディングを推定している。 エンコーディング候補 以下で得られるエンコーディングを、エンコーディング候補として @encodings に格納する。 ボディのデータから推定する Mechanize::Util.detect_charset(body) NKF.guess を利用して文字エンコーディングを推定する。 推定できた場合は ISO-2022-JP, EUC-JP, SHIFT_JIS, UTF-8, UTF-16, UTF-32 の様なエンコーディング文字列が得られる。 推定できなかった場合はデフォルト値として ISO-8859-1 を得る。 レスポンスヘッダから推定す
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
2004.10.17 新規作成。2004.12.19 加筆。2005.04.02加筆。 最近、コンピュータで扱う文字列の文字コードがUnicodeでなければならない場面が増えてきた。UnicodeとシフトJIS、EUC-JPを変換する機会が多い。この変換は変換表で行うが、変換表が実際的なものでなければ、文字化けが発生することになる。 おかしな変換表は、これまでは、特にLinuxなどの上で動作するオープンソースソフトウェアで多く見られた。おそらく規格原理主義者が多かったためだろう。そもそも、規格どおりに変換表を作ると、実用的な変換表にはならない。しかし、最近ではまともな変換表を実装しているものも増えてきて、うまく選ぶだけでいいようになってきている。 変換表の違いをまとめたページはよく見かけるが、実際にどのような条件を満たして変換するものを選べばいいか不明なので、まとめてみた。 変換表に求めら
English page もどる 変換表がベンダーによって異なる (2002-04-04) はじめに 調査に用いたファイルやソフトウェア 調査結果 註釈 はじめに テキストファイルに実際に用いられる文字コードは、 「エンコーディング」と言います。 これは、例えば、EUC-JP、Shift_JIS、 ISO-2022-JP、ISO-8859-1、UTF-8 などです。 エンコーディングは、ひとつまたは複数の「符号化文字集合」 (Coded Character Set, CCS) をその構成要素としています。EUC-JP というエンコーディングは、 ISO 646 IRV (ASCII と同じ)、JIS X 0208、 JIS X 0201 カナ、JIS X 0212 の符号化文字集合を構成要素としています。ISO-8859-1 というエンコーディングは、 ISO-8859-1 という符号化文
「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか？ 日本語の文字コードは大きく以下の２つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング（文字符号化方式）」の事を指す。 文字符号化方式 文字集合って？ 読んでそのまんま”文字の種類の集まり”。「キャラ
とあるシステムでデータベースから引いてきたデータの表示が文字化けするという不具合がありました。 データベース内のデータとしては文字化けしていない状態で格納されていることはわかっていたので、どこかしらの文字変換で化けていることはわかっています。まずはどの誤変換により文字化けするのか原因切り分けのために、decode/encode の組み合わせによる文字化けパターン一覧を作りました。おかげさまでどのパターンに類するものか判別することができ、無事に改修することができました。 その話はまた別にするとして、今も昔も変わらず文字化けに悩む人は意外と多いと思います。誤変換結果一覧は原因解析の参考になると思い、記事としてまとめることにしました。 文字コード変換ミスによる文字化けパターンを可視化するプログラムと一覧表 まずは誤変換を生成する perl スクリプトです。プログラムはとっても簡単で、「文字化けで
文字コードについて調べたことや実験したこと， テストプログラム，データファイルなどを随時掲載する予定です． ただし筆者の理解不足や誤解により誤りがあるかもしれませんので， ご利用は自己責任で． このページの主な更新は Blog でお知らせします． 表示確認ブラウザ：FireFox 22.0，IE8． ０．目次 シフトJIS Shift_JIS と Windows-31J (CP932) の違い シフトJIS ２バイト文字の判定 謎の検索ワード集 (シフトJIS編) 「Shift_JIS(SJIS，Windows-31J，CP932) ３バイト文字」 「Shift_JIS(SJIS，Windows-31J，CP932) サロゲート(ペア)」 「UTF-8 4バイト文字 Shift_JIS(SJIS，Windows-31J，CP932) 変換」 「Unicode(UTF-8，UTF-16) か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く