奇妙な「ツ」と「ノ」と右括弧 Discordの新フォント"gg sans"が抱える問題とその背景
2022年12月1日、Discordはカスタマイズされたオリジナルのフォント「gg sans」を導入しました。ggは"Good Game"に由来するようです。Web フォントなどを利用して Discord 上の表示がこのフォントに順次切り替わる予定です。 補足 / UPDATE 2022/12/03 14:37 JST DiscordのCEO（Jason氏）より返事があり、ツとノの字形がgg sansから削除されたとのことです。右括弧は現時点で残っているようです（これは当初のわたしの指摘がツとノのみに限られていたせいです）。 2022/12/04 14:55 JST 12/3時点でJason氏からの返信に右括弧が残っているという旨を補足しました。 12/4 午前にDiscordのエンジニア Brandon氏より連絡があり、括弧等の修正が完了したとのことです。 こちらで確認する限り、CJK関
「HTMLでは環境依存文字（①や©など）を文字参照にしなければいけない」という誤解と、本当に置換すべき文字
HTMLファイルで特殊記号を使う際、① は ①、© は © のように置き換えて書かないといけないものだと思いこんでいないでしょうか。 現代ではそれは誤解です。 UTF-8では特殊記号の文字参照は不要 そもそも環境依存文字とは、データを扱う機種・ソフトウェアなどの違い（文字コードの割り当ての違い）により表示に違いが出てしまう文字のことでした。 例えばShift_JISには © が含まれておらずそもそも保存できなかったり、 ① などの丸数字は含まれているものの、WindowsとMac OS（当時）の割り当ての違いにより正しく表示できなかったりしました。[1] しかし現在ではUnicodeによって文字コードは統一化されており、その問題はほとんど起きなくなっています。 近年では多くの場合 UTF-8 でファイルを記述すると思います。 HTMLファイルの文字エンコーディングが
Re: Goでcsvを操作するための基本的な知識
はじめに 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
端末の文字幅問題の傾向と対策 | IIJ Engineers Blog
電子メール、ネットワーク機器集中管理、異常検知、分散処理、クラウド基盤などのシステム開発に従事。古代Rubyist。 CLI や TUI なアプリケーションを使っていると、端末の画面が崩れてしまうことがよくあります。 たとえば、こんな TUI が、 環境によってはこんな感じで崩れます。 スクロールなどをしながらしばらく使っているとさらにどんどん崩れていきます。 こうなってしまった場合、とりあえず Ctrl-l で画面を再描画することで、大抵はなんとか読める程度にリセットできますので、ことあるごとに Ctrl-l を連打することになります。 ですが、どうしようもないケースもままあります。 例えば、私の場合は以下のようなシチュエーションで困ります。 w3m でテーブルなどを表示するとレンダリングが崩れる less でログの閲覧の際に表示されるべき文字が表示されず見落としが発生する Wander
PHPでログファイルへの読み書きを通して任意コード実行をする方法 - knqyf263's blog
以前少し話題になったLaravelのデバッグモード有効時の脆弱性であるCVE-2021-3129のPoCを読んでいたのですが、思ったより難しくて何でこんなことをしているんだろうと思ったら発見者による解説ブログがありました。読んでみたらバイパスのために思ったより色々していて普通に勉強になったのでメモを残しておきます。CTFerからすると常識な内容かもしれないので、何か間違いや補足があれば指摘をお願いします。 www.ambionics.io 前提知識1 前提知識2 本題 問題点 = によるエラー 日付のデコード ログファイル内の他エントリ バイパス方法 consumedの利用 iconvの利用 パディングの利用 UTF-16のための調整 NULLバイトの回避 最終形 まとめ 前提知識1 上の脆弱性を理解するためにはいくつかの前提知識を必要とするため最初にまとめておきます。 まず、PHPでは外
Python で Unicode 正規化 NFC/NFD の文字列を扱う - forest book
先日、ビジネスパーソン向けの Python 本を執筆したことを書きました。 t2y.hatenablog.jp 本稿では本書のことを「できるPy」と呼びます。 Amazon でいくつかカスタマーレビューもいただいて次のコメントをみつけました。 python3.7 対応ということで、pathlib を使ってる点が（古いpython は切り捨てる！的なところは）潔いと言えば潔いし、日本語のファイル名にも気を配っている記述はオライリーに期待するのは酷なところもある。でもこの本でもNFD問題は全くの記述無し。だめだろ、それじゃ。 Amazon CAPTCHA まさに仰る通りです。執筆時にそのことに気づかずご指摘いただいてありがとうございます。 ここでご指摘されている NFD 問題というのは、ファイル名のみに限った問題ではなく、Unicode の文字集合を扱ってエンコード／デコードするときに発生する
JSでDoSる/ Shibuya.XSS techtalk #11
Shibuya.XSS techtalk #11 の発表資料です。
ASCIIコードの秘密 - ザリガニが見ていた...。
本当はエスケープシーケンスのことを調べていたのだが、その前にASCIIコードについて調べることになってしまった...。文字コードの基本として知っているつもりだったASCIIコードについて、あらためて見直してみると、実は本当の意味をよく分かっていなかったことに気づいた。 ASCIIコード表 ASCIIコードは、7ビット（2進数7桁）の文字コードであり、全部で128のコードが定義されている。 最も基本的な文字コードであり、その他多くの文字コードはこのASCIIコードと互換性を維持している。 00 10 20 30 40 50 60 70 00 NUL DLE SP 0 @ P ` p 01 SOH DC1 ! 1 A Q a q 02 STX DC2 " 2 B R b r 03 ETX DC3 # 3 C S c s 04 EOT DC4 $ 4 D T d t 05 ENQ NAK % 5
「文字列」について - 2014-11-07 - はてなるせだいあり
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
UTF-8にもいろいろある - ザリガニが見ていた...。
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 OSX 10.8 Mountain Lion以前((OSX 10.9 Mavericksでは、Mac仕様なNFDのUTF-8を表示しようとするとエラーになってしまったため、10.8以前の環境で実験した。Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137. ** ** Abort trap: 6
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Cocoa: Unicode 正規化と照合
Cocoa: NSString の 1文字を取得するCocoa: NSString の文字数とバイト数を求めるCocoa: NSString を char 型の配列に変換するCocoa: Unicode 正規化と照合 NSString には Unicode 正規化のためのメソッドが用意されている。「正規合成」(NFC: Normalize Function Composite)、「互換合成」(NFKC: Normalize Function Compativle Composite)、 「正規分解」(NFD: Normalize Function Decomposite)、「互換分解」(NFKD: Normalize Function Compativle Decomposite)の説明は以前の記事で書いたので、テストケースを流用する。 #import <Foundation/Founda
Masato Kinugawa Security Blog: accounts.google.comに存在したXSS
Googleの脆弱性報酬制度の報酬がアップされましたね！ Google、脆弱性情報に支払う報奨金を大幅アップ - ITmedia エンタープライズ http://www.itmedia.co.jp/enterprise/articles/1306/10/news027.html Googleアカウントページに存在するクロスサイトスクリプティング（XSS）の脆弱性情報については3133.7ドルから7500ドル accounts.google.comのXSSは$7,500 だそうです。みつけたいですね！ みつけるのはかなり厳しいと思いますが、かつて2つみつけたことがあります。 今日はそのうち1つを紹介したいと思います。 oeパラメータを使ったXSS 2012年12月27日に報告し修正された問題です。 Googleは、一部のサービスで「oe」というクエリパラメータを付加することで、ページの表示に
Python 2 から Python 3 への移植 — Python 3.3.6 ドキュメント
概要 With Python 3 being the future of Python while Python 2 is still in active use, it is good to have your project available for both major releases of Python. This guide is meant to help you figure out how best to support both Python 2 & 3 simultaneously. もしあなたが標準 Python ライブラリではなく拡張ライブラリでの移植手段を探しているならば Python 3 への拡張モジュール移植 を参照してください。 If you would like to read one core Python developer’s take on w
いいから聞け！ 俺が文字コードについて教えてやるよ Advent Calendar 特別編 - 谷本 心 in せろ部屋
長らく更新の止まっている「いいから俺文字コード」シリーズですが、 このたび、Java Advent Calendarの一環として復活させました！ Java Advent Calendarって？ 本エントリーはJava Advent Calendarの5日目です。 Java Advent Calendarについては、以下のサイトをご覧ください。 http://atnd.org/events/22434 前の4日目は @akirakoyasu さんの「SDKで身近になるAmazon Web Service」 http://www.akirakoyasu.net/2011/12/04/easily-use-aws-through-sdk/ S3、SimpleDB、SESの使い方をサンプルコードつきで紹介しています。 次の6日目は @shuji_w6e さんの「JUnit のセカイ」 http:/
Rubyのエンコーディング - tmtms のメモ
Ruby 1.9 から文字列や正規表現オブジェクトはそれぞれエンコーディング(いわゆる文字コード)を保持するようになりました。 たとえば 0xB1 0xB2 という２バイトは EUC-JP エンコーディングでは「渦」、SHIFT_JIS エンコーディングでは「ｱｲ」という文字になります。つまり同じバイト列でもエンコーディングが異なれば異なる文字として解釈されます。 1.8 では文字列はただのバイト列でした。なので、それがどのような文字を表しているのか、つまりエンコーディングが何なのかはプログラムが知っている必要がありました。 1.9 では文字列オブジェクト自身が自分が何のエンコーディングかを知っています。同じ 0xB1 0xB2 というバイト列でも、それが EUC-JP の「渦」なのか SHIFT_JIS の「ｱｲ」なのかは、文字列自身が知っています。 スクリプトエンコーディング スクリプ
標準入出力のエンコーディングを指定する3つの方法の使い分け - methaneのブログ
そこまでおっしゃるなら、というわけで書いたのが以下。 #!/usr/bin/env python3.2 # -*- coding: utf-8 -*- import sys, os if 'PYTHONIOENCODING' in os.environ: for line in sys.stdin: chars = list(line.rstrip()) print('☆'.join(chars)) else: os.environ['PYTHONIOENCODING'] = 'UTF-8' sys.argv.insert(0, sys.executable) os.execvp(sys.argv[0], sys.argv) …強引さが増してるぞおいwllevalのようなsandbox環境では余計動かないしww http://blog.livedoor.jp/dankogai/archiv
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PDFのコピペが文字化けするのはなぜか？～CID/GIDと原ノ味フォント～
最後に改行がないファイルが作れない · Issue #152 · vim-jp/issues
Mysql toranomaki
