サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
テキストの改行や何かのコマンドを実行するためのキーとしてEnterとReturnがありますが、日本ではそれを「Enterキー」と呼ぶことが慣例化しています。広く普及しているWindowsPCがそのキーにEnterを採用しているためか、主にReturnを採用しているMacを使っているユーザーでさえもそれを「Enterキー」と呼ぶ人が多くいらっしゃいます。 現代においてReturnキーとEnterキーの機能的差異はほとんど見られないため、仮にMac環境でそれを「Enterキー」と呼んだとしても、現実的には何かの支障が生じることはほとんどありません。しかし、これら2つのキーを厳密に区別するソフトウェアや機能が存在する場合があることや、MacではReturnキーとEnterキーの両方を別々に備えている場合があること、そもそも刻印されているキーの名称を間違った呼び方をすることはよろしくない姿勢であ
どうも、『人文×社会』の中の人です。 今回は、WindowsとMacで起こった「波ダッシュ」をめぐるドタバタ劇をご紹介したいと思います。 波ダッシュといえば、「〜」という記号。どこにもドタバタする要素がないように思えますが、実は今でも組版業界で問題となっている大混乱があります。 波ダッシュと全角チルダ「それ、不等号ですよ！ 紛らわしい約物3連発！」の記事でもご紹介したように、見た目が「〜」に見える約物には、2種類あります。 「波ダッシュ」と「全角チルダ」です。 「波ダッシュ」は、日本語で範囲を表すときに使われる約物です。「明治〜大正」みたいな感じで使います。 「全角チルダ」は、半角チルダ（~）の全角版です。チルダは「漸近的に等しい」ことを表す数学記号として使われます。つまり、全角イコール（＝）の仲間です。（他にも半角チルダは、コンピュータ上のホームディレクトリを表したり、プログラミング言語
携帯電話を用いたコミュニケーションの手法の1つに「絵文字」がある。日本で生まれたこの絵文字は、GoogleとAppleによって標準化され、今ではさまざまなスマートフォンやPCでもでも閲覧できる。 その一方、ドコモで販売されるAndroidスマートフォンには、いまだフィーチャーフォン時代の絵文字が表示される。しかしこれが今のスマートフォンにそぐわない側面が出ている。この絵文字問題について考察したい。 今の絵文字は日本のものをベースにGoogleとAppleが標準化を提案絵文字を携帯電話に採用したのは、NTTドコモが最初だ。この後にDDI（現au）、J-フォン（現ソフトバンク）が採用する形で続く。絵文字にはシフトJISというコードが用いられていたが、互換性維持の空き領域に絵文字を割り当てたことから、キャリア間で互換性がなく、文字化けの要因となっていた。 後に自動変換サービスも展開されたが、使
2022年12月1日、Discordはカスタマイズされたオリジナルのフォント「gg sans」を導入しました。ggは"Good Game"に由来するようです。Webフォントなどを利用してDiscord 上の表示がこのフォントに順次切り替わる予定です。 補足 / UPDATE2022/12/03 14:37 JSTDiscordのCEO（Jason氏）より返事があり、ツとノの字形がgg sansから削除されたとのことです。右括弧は現時点で残っているようです（これは当初のわたしの指摘がツとノのみに限られていたせいです）。2022/12/04 14:55 JST 12/3時点でJason氏からの返信に右括弧が残っているという旨を補足しました。 12/4 午前にDiscordのエンジニア Brandon氏より連絡があり、括弧等の修正が完了したとのことです。 こちらで確認する限り、CJK関
PHP 8.1へのアップグレードにまつわるまとめPHP 8.1へのアップグレードには、mbstringにまつわるマニュアルに記述されない後方互換性のない変更が含まれることがあります。そのことを周知するべく、この記事を書くことにしました。 私てきめんは、PHPカンファレンス2022にて、「治っていくmbstring 令和時代の文字化け」というタイトルでトークしています。以下スライドも参考にしてください。 Major overhaul of mbstringについてPHP 8.1から、Major overhaul of mbstringと呼ばれる、mbstringの大規模改修の内容が反映されるようになりました。困ったことに、RFC(Request For Comments)やChangelog、マニュアルにない内容で、mbstringを多用するPHPユーザーにとてつもない困惑をもたらすこ
HTMLファイルで特殊記号を使う際、① は ①、© は © のように置き換えて書かないといけないものだと思いこんでいないでしょうか。 現代ではそれは誤解です。UTF-8では特殊記号の文字参照は不要 そもそも環境依存文字とは、データを扱う機種・ソフトウェアなどの違い（文字コードの割り当ての違い）により表示に違いが出てしまう文字のことでした。 例えばShift_JISには © が含まれておらずそもそも保存できなかったり、 ① などの丸数字は含まれているものの、WindowsとMac OS（当時）の割り当ての違いにより正しく表示できなかったりしました。[1] しかし現在ではUnicodeによって文字コードは統一化されており、その問題はほとんど起きなくなっています。 近年では多くの場合UTF-8 でファイルを記述すると思います。HTMLファイルの文字エンコーディングが
Googleは独自のルールに従って検索結果の表示順位を決めていますが、Googleの広告枠を購入すれば任意のウェブサイトを検索結果の最上部に表示することができます。この広告枠を悪用して人気画像処理ソフト「GIMP」の公式サイトになりすました偽サイトが検索結果の最上部に表示されてしまう事態が発生しました。偽サイトはドメインの見た目までソックリで、インターネットに慣れている人でも見分けることは困難となっています。 DangerousGoogle Ad DisguisingItself as www.gimp.org : GIMP https://www.reddit.com/r/GIMP/comments/ygbr4o/dangerous_google_ad_disguising_itself_as/ DangerousGoogle Ad DisguisingItself as www
プログラミング言語 AWK が最初に開発された 1977 年から 45 年後の2022年、Brian Kernighan 氏により Unicode サポートが追加されたそうだ (README.unicode、 The Register の記事、 ArsTechnica の記事、 Computerphile 動画)。 Kernighan 氏は AWK (Aho Weinberger Kernighan) の「K」の由来でもあるオリジナル開発者で、80 歳になる。GitHub の「The One True Awk」リポジトリに Unicode サポートがコミットされたのは 6 月 1 日だったが、先週 Kernighan 氏が YouTube の Computerphile に出演するまで注目されずにいたようだ。Kernighan 氏によれば、AWK が Unicode をサポートしていない
Pythonがファイルを開くときなどに使われるエンコーディングはロケール（WindowsではANSIコードページ）依存でした。 Unixの世界ではどんどんUTF-8ロケールが一般的になっている一方、WindowsのANSIコードページはなかなかUTF-8になりません。 そのために、Unixユーザーが open(filepath) のようにエンコーディングを指定しないままUTF-8を仮定するコードを気軽に書いてしまって、Windowsユーザーがエラーで困るといった問題が発生します。 また、Windowsでもメモ帳（Notepad.exe）やVSCodeはすでにUTF-8をデフォルトのエンコーディングで使用しています。ANSIコードページがUTF-8になるのを待っていたらどんどん周りの環境から置いていかれ、レガシー化してしまいます。Pythonがデフォルトで利用するエンコーディングをWind
はじめに Println で標準出力してみると以下のように表示されるかと思います。（SHIFT-JIS形式なのでmacでみると文字化けしていますがひとまず置いておきます） 日本では一般的にCSV ファイルは Shift_JIS でエンコードされている事が多いです。Go 言語は内部のエンコーディングがUTF-8 なので、Shift_JIS なCSV ファイルを読み込むと文字化けします。 そこで便利なのが エンコーディングの変換はgolang.org/x/text/transform が便利です。このパッケージと、golang.org/x/text/encoding/japanese を使う事で、os.Open で開いたファイルがさも初めからUTF-8 であるかの様に扱う事ができます。 どんな風に扱うかjapanese パッケージにはjapanese.ShiftJIS や jap
電子メール、ネットワーク機器集中管理、異常検知、分散処理、クラウド基盤などのシステム開発に従事。古代Rubyist。 CLI や TUI なアプリケーションを使っていると、端末の画面が崩れてしまうことがよくあります。 たとえば、こんな TUI が、 環境によってはこんな感じで崩れます。 スクロールなどをしながらしばらく使っているとさらにどんどん崩れていきます。 こうなってしまった場合、とりあえず Ctrl-l で画面を再描画することで、大抵はなんとか読める程度にリセットできますので、ことあるごとに Ctrl-l を連打することになります。 ですが、どうしようもないケースもままあります。 例えば、私の場合は以下のようなシチュエーションで困ります。w3m でテーブルなどを表示するとレンダリングが崩れる less でログの閲覧の際に表示されるべき文字が表示されず見落としが発生する Wander
以前少し話題になったLaravelのデバッグモード有効時の脆弱性であるCVE-2021-3129のPoCを読んでいたのですが、思ったより難しくて何でこんなことをしているんだろうと思ったら発見者による解説ブログがありました。読んでみたらバイパスのために思ったより色々していて普通に勉強になったのでメモを残しておきます。CTFerからすると常識な内容かもしれないので、何か間違いや補足があれば指摘をお願いします。 www.ambionics.io 前提知識1 前提知識2本題 問題点 = によるエラー 日付のデコード ログファイル内の他エントリ バイパス方法 consumedの利用 iconvの利用 パディングの利用 UTF-16のための調整 NULLバイトの回避 最終形 まとめ 前提知識1 上の脆弱性を理解するためにはいくつかの前提知識を必要とするため最初にまとめておきます。 まず、PHPでは外
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloudblog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータセキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
入門 Kubeflow ～Kubernetesで機械学習をはじめるために～ （NTTTech Conference #4 講演資料）
HTML 文書内に <meta charset="UTF-8"> を書いていますか? 書いているとしたら、その必要性を問われた時に理由を説明できますか? 実は私も勘違いしていた部分があり[1]、改めてまとめてみました。 まず基本的なおさらいをします。<meta charset="UTF-8"> はHTML5 で登場した新しい記法で、HTML4 以前は <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> などという長くて覚えにくい書き方をしていました。さらに遡ると、黎明期のHTML には meta 要素そのものが存在しません。HTML が考案された当初、 meta 要素はありませんでした。 home of the first website(info.cern.ch) 世界最初の Web ページ。ソー
Python がテキストファイルを開く時のデフォルトエンコーディングがUTF-8でないことは、多くのWindowsユーザー、特にプログラミング初心者にとって障害になっています。 UnicodeDecodeError で検索すると、多くのWindowsユーザーが問題に遭遇しているのがわかります。 https://qiita.com/Yuu94/items/9ffdfcb2c26d6b33792e https://www.mikan-partners.com/archives/3212 https://teratail.com/questions/268749 https://github.com/neovim/pynvim/issues/443 https://www.coder.work/article/1284080 https://teratail.com/questions/2713
2021/9/10 追記: 改めて更新された話を統合して整理して書き直しました. 以降はこちらを参考にしてください: ill-identified.hatenablog.com 2021/1/15 追記: RStudio 1.4 がリリースされたのでなるべくアップデートしましょう 2020/12/06 追記: Japan.R で今回の話の要約+新情報を『Mac でもWindows でも, PNG でもPDF でもRのグラフに好きなフォントで日本語を表示したい (2020年最終版)/Display-CJK-Font-in-Any-Gpraphic-Device-and-Platform-2020 - Speaker Deck』として発表した. ハイライトは「近々出るRStudio 1.4 があれば fontregisterer はほぼいらなくなる」 2020/10/31 追記: geom
先日、Emacsに一生入門できねえ2020という記事を目にした。 確かにEmacsは難しい。まったくもって増田の言う通りだ。うんうんと頷きながら、過去に自分が書いた「風になりたい奴だけがEmacs を使えばいい。」という記事が脳裏に浮かんだ。 10年間の出来事 # 僕が「風になりたい奴だけがEmacsを使えばいい」と言った記事は2010年9月4日に投稿されていて、あれから実に10年の月日が経過していた。とても懐しい。 振り返ればこの10年間でエディタの世界は大きく変わった。次世代エディタを銘打ったAtomが誕生し、エディタにおける表現の限界をぶち壊した。そして後続で登場したVSCodeが一気にシェアを奪い、一瞬でトップシェアの座に立ってしまった。予想しなかった未来があった。 一方、Emacsはどうなったかと言えば、メジャーバージョンが23から27になった。しかし、起動したてのEmacsは
以前に同僚と少し絵文字に関する話をしていたこともあり、ふと、絵文字はスクリーンリーダーでどう読み上げられるのかということが気になって、ごく簡単に読み上げさせてみましたという話です。 筆者の自宅の環境がWindowsとAndroidであることから、読み上げのテストにあたっては、NVDA、Windowsのナレーター、TalkBackで試してみました。以下にテスト環境を記しておきます。ブラウザーによる違いは見られなかったので、これについては省いています。Windows バージョン 1909（OS ビルド 18363.836） NVDA 2020.1jpAndroid 10 TalkBack バージョン 8.2.0.303936097 以下が4つの絵文字について読み上げテストを実施した結果になります。言語については、lang属性を付与して読み上げさせました。 笑顔を表す絵文字と各スクリーンリー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
