C/C++で日本語を扱いたい - Qiita
#include <stdio.h> #include <string.h> int main() { char str[] = "日本語サンプル"; int length = strlen(str); printf("1文字目: %c\n", str[0]); printf("長さ: %d\n", length); return 0; } このように、単なるchar型として扱うと日本語を上手く処理できない。まあ、日本語が2バイト以上で表現されているので当たり前といえば当たり前なんだけど。 そこで、C/C++で上手に日本語を処理するための方法を2通り紹介したい。 ワイド文字を使う ワイド文字は、16ビット固定長で表現される多言語文字体型のことである。 C言語では、wchar_t型を用いてワイド文字を扱うことができる。 しかし、ワイド文字を扱うには、ロケールの設定が必要である。日本語だけ扱い
UTF-16のことをUnicodeと記しているソフトウェア(Windowsのメモ帳など)もありますのでUnicodeとあったらそれはUTF-16を使って変換したものなのだな、というふうに理解してください。 そうなってしまっている理由はこちらで解説されていました。 これでUnicodeとUTF-8の違いはバッチリですね！おわり。 読んで分かりやすかったり少しでも何か学べたと思えたら いいね や コメント をもらえるとこれからの励みになります！ もう少し時間がある方へ 手計算で文字をUTF-8での符号まで計算してみましょう。 理解が一気に深まります。手順は以下。 1. 文字のコードポイントをUnicodeから見つけてくる。 2. コードポイントをUTF-8の方式で変換してみる。 Omiitaの「お」をUTF-8による符号まで変換してみます。 文字「お」のコードポイントをUnicodeから見つけ
ミャンマー語フォント『Zawgyi-one』の問題に直面した話 - GMO Research & AI Tech Blog
システム部のはたです。 GMOリサーチには2年ぐらい前に入社して、主にシステム開発をやっています。 趣味は音楽鑑賞と旅行とキャンプで、焚火を見ながらお酒を飲んでのんびり過ごすのにハマってます。 今回は、ミャンマー語フォントの問題についてお話をしたいと思います。 GMOリサーチでは、国内だけではなく、海外ビジネスの展開にも力を入れており、2019年にはミャンマーへ進出し、リサーチサービスの展開を行ってきました。 そんな中、ミャンマー語のWebアンケートサイトを作ることになったのですが、ある問題に直面しました。それは「ミャンマー語のWebサイトの文字化け問題」です。 ということで、早速どんな事象が発生したのかご紹介していきます。 ◆ ミャンマー進出の背景 まず、ミャンマー進出の背景から簡単にご説明させていただきます。 弊社では生活者の方々の声を企業に届けること、そしてそのデータを企業のマーケテ
One of the most common “data type” in programming is the text string. When programmers think of a string, they imagine that they are dealing with a list or an array of characters. It is often a “good enough” approximation, but reality is more complex. The characters must be encoded into bits in some way. Most strings on the Internet, including this blog post, are encoded using a standard called UT
これらは、MS-DOS時代からのルールである。ある意味、「command.com」のルールだとも言える。これらの文字がファイル名やフォルダー名に使えなくなったのは、コマンドラインで特別な意味を持つからである。MS-DOSはもともとコマンドラインですべての操作をする。このとき、コマンドラインで特別な意味を持つ記号文字に関しては、ファイルやフォルダー名での利用を禁止してコマンドラインやファイル名、フォルダー名の判定を簡略化した。 これらが今でも特殊扱いされていて、ファイルやフォルダーの名前に使えなくなっている。ただし、このことはNTFSやvFATなどのファイルシステムとしての仕様とは部分的にしか関係がない。パス区切り文字としての「\」と「/」は共通だが、他の文字は絶対ファイル名やパス名に入れられないのかというと、実はそうではない。ただし、ファイル名のAPIでもある程度の安全対策がしてあり、渡さ
初稿: 2020-10-16 小松弘幸 (@komatsuh) 記事の内容 シュトヘルという漫画がとてもよいです 西夏文字をコンピューター上で扱う方法を紹介します 西夏文字の簡易辞書を作成します シュトヘルの登場人物を西夏文字で表現します ユルール 𘅝𘚻 (U+1815D U+186BB) - 祝福 (慶喜) ハラバル 𗱈𗰞 (U+17C48 U+17C1E) - 黒虎 シュトヘル 𘄅𗾢 (U+18105 U+17FA2) - 雀子 左から順に ユルール ハラバル シュトヘル はじめに この文書に登場する西夏文字を正しく表示するためには、おそらくフォントのインストールが必要です。下記の GitHub などからダウンロードとインストールができます。 Noto fonts: NotoSerifTangut (GitHub) シュトヘルと西夏文字 シュトヘルという漫画を読んでとても好
GitHub - unicode-org/last-resort-font: Last Resort Font
This repository includes two versions of the Last Resort font: Last Resort and Last Resort High-Efficiency. Although both fonts can be installed at the same time—because they have different names—you are encouraged to download and install only the one that is expected to work in the environments that you use: The file LastResort-Regular.ttf is a font named Last Resort, and its 'cmap' table include
漢字のようで漢字でないUnicodeの「康熙部首」と「CJK部首補助」｜TechRacho by BPS株式会社
きっかけ 以下のツイートで「埼玉埼⽟問題」と康煕部首を知りました。 「埼玉」と「埼⽟」の話。unicodedata.normalize('NFKC', '「埼玉」と「埼⽟」') でいけそう https://t.co/kte0sxDvZT — Haruhiko Okumura (@h_okumura) July 11, 2020 康煕部首とは ⼀⼁⼂⼃⼄⼅⼆⼇⼈⼉⼊⼋⼌⼍⼎⼏⼐⼑⼒⼓⼔⼕⼖⼗⼘⼙⼚⼛⼜⼝⼞⼟⼠⼡⼢⼣⼤⼥⼦⼧⼨⼩⼪⼫⼬⼭⼮⼯⼰⼱⼲⼳⼴⼵⼶⼷⼸⼹⼺⼻⼼⼽⼾⼿⽀⽁⽂⽃⽄⽅⽆⽇⽈⽉⽊⽋⽌⽍⽎⽏⽐⽑⽒⽓⽔⽕⽖⽗⽘⽙⽚⽛⽜⽝⽞⽟⽠⽡⽢⽣⽤⽥⽦⽧⽨⽩⽪⽫⽬⽭⽮⽯⽰⽱⽲⽳⽴⽵⽶⽷⽸⽹⽺⽻⽼⽽⽾⽿⾀⾁⾂⾃⾄⾅⾆⾇⾈⾉⾊⾋⾌⾍⾎⾏⾐⾑⾒⾓⾔⾕⾖⾗⾘⾙⾚⾛⾜⾝⾞⾟⾠⾡⾢⾣⾤⾥⾦⾧⾨⾩⾪⾫⾬⾭⾮⾯⾰⾱⾲⾳⾴⾵⾶⾷⾸⾹⾺⾻⾼⾽⾾⾿⿀⿁⿂⿃⿄⿅⿆⿇⿈⿉⿊⿋⿌⿍⿎⿏⿐⿑⿒⿓⿔⿕ KangXi Radica
grep の「バイナリファイル (標準入力) に一致しました」が出る条件を調べていたらそれは長い旅路の始まりだった。
はじめに 昨今では1行につき、1つの JSON を出力する様なログファイル形式も珍しくはありません。 grep しやすい データベース化しやすい これらの理由で各所で多く使われています。僕も仕事で普通に使っているのですが、ある日突然そのログファイルを集計するスクリプトで以下の様なエラーが出始めました。
おまえはもうRのグラフの日本語表示に悩まない (各OS対応) - ill-identified diary
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
NHK「チコちゃんに叱られる！」でチコちゃんが「ギョーザ」を漢字で書く問題を出しました。豊川悦司さんが書いたのは「飠」に「交」と「子」。これをチコちゃんは不正解としました。それはないよ。チコちゃん、トヨエツにダメ出ししてんじゃねーよ！ 「しょくへん」が「飠」ではダメなのか トヨエツこと豊川悦司さんがＮＨＫ「チコちゃんに叱られる！」に出た回。チコちゃんが出演者に正解されて「ボーッと生きてんじゃねーよ！」という決めぜりふを言えない悔しさを紛らすために「ギョーザ」を漢字で書く問題を出しました。 豊川さんがボードに書いたのは、おちゃめなことに「飠」の右にギョーザの絵。その下に書かれていたのは「飠」に「交」の「子」でした。 これをチコちゃんは不正解としました。正解は「餃子」で、「しょくへん」の下は「二」みたいな横線でなければいけないということです。 それはないよ。チコちゃん、トヨエツにダメ出ししてん
PDF に謎の漢字が含まれるとき
gistfile1.md PDF に謎の漢字が含まれるとき PDF などの中にある一部の日本語の漢字が、見た目は同じだけど異なる謎の文字に変換されていることがある 例 1: https://www.mhlw.go.jp/content/10906000/000628667.pdf 「長野」と「長崎」の「長」が、 U+9577 ではなく「⾧ (U+2FA7)」になっている 例 2: https://www.dpri.kyoto-u.ac.jp/news/12739/ 大量にある、どうしてこうなった PDF ではないので何かからコピーして書いた？ この文字は 康煕部首 (Kangxi Radicals) というもので、部首としての文字である ＭＳ ゴシックなど Kangxi Radicals の字形がないフォントを指定すると表示できないので区別しやすい どこから来たのか？ これらは（フォントに
$utf8Str = "❶❷❸❹❺"; $sjisStr = mb_convert_encoding($utf8Str, 'SJIS-mac'); echo(mb_detect_encoding($sjisStr, ['UTF-8','SJIS-mac', 'SJIS-win', 'SJIS'])); // SJIS-win ← SJIS-macに変換したはずなのに、何故かSJIS-winと判定されてしまいます。 そもそもSJIS-macってなんだよって話ですが、単にMacJapaneseのエイリアスです。 従ってMacJapaneseと書いても同じく、正しく誤判定されます。 そしてコメント欄にThis is a bug in PHP's mbstring extension『mbstringエクステンションのバグじゃよ』という人が現れています。 間違ったコードを書いたときに自分のせいでは
風になりたい奴だけがEmacsを使えばいい 2020
先日、Emacsに一生入門できねえ2020という記事を目にした。 確かにEmacsは難しい。まったくもって増田の言う通りだ。うんうんと頷きながら、過去に自分が書いた「風になりたい奴だけが Emacs を使えばいい。」という記事が脳裏に浮かんだ。 10年間の出来事 # 僕が「風になりたい奴だけがEmacsを使えばいい」と言った記事は2010年9月4日に投稿されていて、あれから実に10年の月日が経過していた。とても懐しい。 振り返ればこの10年間でエディタの世界は大きく変わった。次世代エディタを銘打ったAtomが誕生し、エディタにおける表現の限界をぶち壊した。そして後続で登場したVSCodeが一気にシェアを奪い、一瞬でトップシェアの座に立ってしまった。予想しなかった未来があった。 一方、Emacsはどうなったかと言えば、メジャーバージョンが23から27になった。しかし、起動したてのEmacsは
GitHub - qntm/base2048: Binary encoding optimised for Twitter
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
コード値：00000000_00000000_0xxxxxxx（1-7ビット） ⇒ UTF-8：0xxxxxxx（1バイト） コード値：00000000_00000yyy_yyxxxxxx（8-11ビット） ⇒ UTF-8：110yyyyy 10xxxxxx（2バイト） コード値：00000000_zzzzyyyy_yyxxxxxx（12-16ビット） ⇒ UTF-8：1110zzzz 10yyyyyy 10xxxxxx（3バイト） コード値：000wwwzz_zzzzyyyy_yyxxxxxx（17-21ビット） ⇒ UTF-8：11110www 10zzzzzz 10yyyyyy 10xxxxxx（4バイト） 特に重要な点は以下の2つである。 1バイト目（開始バイト）の先頭のビットパターンによって全体のバイト数を判定できる。 （0...：1バイト、110...：2バイト、1110...
他にもまだまだあると思いますが、自分が見たことがあるのは上記になります。 それぞれ見比べてみると、やはりエンコード・デコード両方に対応しているライブラリが人気があるようです。 この中で特に人気のある easyjson , gojay , json-iterator/go でベンチマークをとってみた結果、パフォーマンスの良い順に並べると次のようになりました。 gojay > json-iterator/go > easyjson > encoding/json 設計方針の違いがそのまま速度に現れているようにも見えますが、理論上最速にできるはずの easyjson が遅かったりと実装の良し悪しも影響しているようです。 一番遅いのは encoding/json です。そもそも encoding/json が遅いから新しい JSONライブラリを作ろうとしているはずなので、一番遅いのは仕方ないのです
Appleのメールアプリで送信するメールをチェックして文字化けを防いでくれるプラグイン「LetterFix」が試験的にmacOS 11 Big Surに対応。
Appleのメールアプリで送信するメールをチェックし文字化けを防いでくれるプラグイン「LetterFix」が試験的にmacOS 11 Big Surに対応しています。詳細は以下から。 LetterFixはmacOSのデフォルトのメーラーであるメールアプリ(Mail.app)で作成したメール中のUnicode文字のチェック＆必要に応じて文字の置換を行うとともに、日本国内で一般にメールのやり取りに用いられているISO 2022-JPエンコーディングで送信に設定し文字化けを防止してくれるプラグインですが、このLetteFixが2020年秋にリリースされるmacOS 11 Big Surのメールアプリに試験的に対応しています。 /Users/(ユーザ名)/Library/Mail/Bundles/ #プラグインのインストールディレクトリ macOS 11 Big Surに対応しているのはLette
[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました | DevelopersIO
本日のアップデートで ALB および CLB が HTTP Desync 緩和モードをサポートするようになりました。 Application and Classic Load Balancers are adding defense in depth with the introduction of Desync Mitigation Mode 何がうれしいのか HTTP Desync 攻撃とは このアップデートの何が嬉しいのかを理解するには、まず HTTP Desync 攻撃 について知る必要があります。 近年では Web アプリケーションでは CDN やプロキシをフロントエンドに配置し、バックエンドのサーバーにリクエストを転送するような構成を一般的にとられているかと思います。まず大前提として HTTP Desync 攻撃は、このようなフロントエンド、バックエンド構成において成り立ちます
![[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
Pythonのchardetモジュールが、"testあ"という文字列（UTF-8）の文字コードを"Windows-1254"だと判定する
"testあ"のUTF-8表現は、74 65 73 74 e3 81 82 (1バイトデータの表記は全部16進、以下同様, python3風に書くとb'\x74\x65\x73\x74\xe3\x81\x82')で、chardetが判定するのは「文字列」ではなく、このバイト列です。 ちなみにこのバイト列をUTF-8, Shift_JIS, EUC-JP, ISO-8859-1, Code Page 437, Windows-1254で解釈すると、以下のようになります。 UTF-8 testあ (まぁ、当たり前) Shift_JIS (不正) EUC-JP (不正) ISO-8859-1 testã (81 82 は制御コードにあたるので見えないが不正ではない) CP437 testπüé Win1254 testã‚ (81は未定義なので本来は不正、chardetは未定義にあたるバイトが現
先日、きりきりやままさんがこのような記事を公開していました UTF-8 の文字列をできる限り Shift_JIS に変換したい - きりきりやま それでは実際にそのような文字列変換を行うにはどうすればよいのか、またコメントでiconvについて触れられていたので、この記事ではUnicodeにおけるNFKC正規化をどうやって行うのか試してみることにしました。 追記 GoとPythonとJavaScriptでの例を足しました。またいくつかのscriptにおいてブラウザ上で実行できるURLを添付しました。 (2020-08-17 16:22) “Go” に表記を統一しました。 (2020-08-17 17:00) Ruby 僕にとって文字列処理といえばRubyなので、まずは以下のようなscriptを書いてみました。 puts "\u304c" puts "String#encode('Shift_
更新日: 2020年8月14日 このページの目的 プログラマーは、クライアントから提供されたPDFファイルで、その要求を実現させようとしたとき、PDFのどんなところを見ているのでしょうか。このページでは、ちょっと珍しい視点でPDFファイルを解き明かしていきます。 自分でプログラムを書いてPDFファイルからテキストデータを取り出したいという人も、ぜひご一読ください。 はじめに PDFファイルをクリックすると、あたかも紙に印刷したかのように、どんなマシンでも同じような見た目で文章や画像がディスプレイに表示されます。 この単純な事実は、日常的にPDFファイルを利用していると当たり前に感じられるかもしれません。しかし、よくよく考えると驚くべきことです。 いったい、どのような仕組みがあれば、「過去から現在に至るさまざまな種類のコンピューターで見た目を変えずに同一の紙面を再現する」という目的を達成でき
やっかいな漢字 – CJK部首補助／康煕部首 – ものかの
DTP制作向けのテキスト整形の話です（楽しい文字沼）。 CJK部首補助や康煕部首の漢字は、とてもやっかいです。なにがやっかいかというと、見た目では通常の漢字と区別ができないことです。 文字コードが違うのにどうして見た目がこれほど同じなのかというと、フォントの同じグリフが表示されているからです。 クライアントから支給された文字原稿に、もしかするとこのやっかいな漢字が混入しているかもしれません。なぜかというと、PDFから文字をコピーすると、通常の漢字だったはずなのに、なぜかやっかいな漢字に変わってしまうことがあるからです。このごろは文字原稿の作成にPDFから文字をコピー＆ペーストすることが普通に行われているので、やっかいな漢字の混入は日常茶飯事といってよいかもしれません。 クライアントからPDFを支給されたときも、DTP制作者がPDFから文字をコピー＆ペーストして、気づかずにやっかいな漢字を混
Shift_JIS の CSV で連携する外部サービスがあり、DB では UTF-8 でテキストを持っていたため文字コードを変換する必要が生じた。 ところが UTF-8 に存在する多くの文字は Shift_JIS に対応がないため変換することができない1。 そこで、事前に NFKC 形式で Unicode 正規化することで変換可能な文字を増やすことを試みた。 まずは Unicode 正規化の前提として、Unicode の正準等価と互換等価について説明する。 以降の U+16進数 という表記は Unicode のコードポイント (文字に ID のようなものが割り当てられている) を示す。 また、コードポイントに対応する文字の詳細は https://codepoints.net/ といったサイトで確認することができる。 正準等価 例として、ひらがなの「が」について考える。Unicode では「
カスタマーセンターでも人事でも役所の戸籍関係の人とか、世の中に同志は沢山潜んでると思うんですが。 山﨑の「﨑」とか、高橋の「高」の字がいわゆる"梯子高"の人とか、なんかちゃんとJISフォントに乗せるようにするか、「崎」と「高」に統一しちゃうか、どっちかにしてくれ！って思ったことありませんか。 どっちかにしてくれ！
（表ではフォントに源ノ角ゴシックを指定しているので、インストールしてない人はsource-han-sansからどうぞ。どのファイルか迷う人はSuperOTCを入れればOK。） 百聞は一見にしかず、次の表に適当に漢字を比較させてみたのでどうぞ。 国および地域別のUnicodeコードポイントとグリフの比較 地域 言語タグ U+9AA8 U+6B21 U+771F U+4E03 U+904D 台湾（繁体字） zh-Hant-TW 骨 次 真 七 遍 香港（繁体字） zh-Hant-HK 骨 次 真 七 遍 中国（簡体字） zh-Hans 骨 次 真 七 遍 日本（参考） ja 骨 次 真 七 遍 韓国（参考） ko 骨 次 真 七 遍 …とそれだけではあまりにも味気ないので、補足説明をほんのちょっと。 ふと簡体字と繁体字を言語コードで表すときに、zh-Hansとzh-Hantとしましょうというと
Unicodeで半角全角を扱う Ambiguous（曖昧さ）とUncertainty（不確実性）の恐怖 - Qiita
Ambiguousだけ東アジアか否かによって扱いを変える必要があります。 FullwidthとWideは東アジア圏では全角で扱いますが、それ以外の文化圏の文章には登場しないため考慮する必要がありません。 東アジア圏かどうか？をどう判定するべきかはプラットフォームによって異なります。私は.NETで扱ったのでデフォルトはCurrentUICultureInfoで処理分岐するようにしました。 さて、ここまでが基本です。 ここから先が闇です。 闇の始まり さて、先ほどの扱いについては、UAX #11: East Asian Widthに明確に記載されています。 しかし、実際に文字をひとつずつ追いかけていくと怪しい文字が頻出します。 ここからは日本で最も著名な等幅フォントである「MS ゴシック」で見ていきたいと思います。 さてAmbiguousは全角で扱います。Ambiguousには「☎」や「®」が
Hideyuki Tanaka on Twitter: "文字コードがUTF8になっただけでは一切対応が進まなかったアメリカ人の書くコードの多倍長文字対応が、絵文字が入った途端に全てのソフトが完璧に多倍長文字に対応されるようになったんで、なんだかんだでアメリカ人に多倍長文字を使う強力なモ… https://t.co/JTxQUjo8vY"
文字コードがUTF8になっただけでは一切対応が進まなかったアメリカ人の書くコードの多倍長文字対応が、絵文字が入った途端に全てのソフトが完璧に多倍長文字に対応されるようになったんで、なんだかんだでアメリカ人に多倍長文字を使う強力なモ… https://t.co/JTxQUjo8vY
Windows 10には、マイクロソフトが実装したcurl.exeコマンドが同梱されている。公開されているソースを元に作られた公式のcURLとはバージョンなどが異なっている Windows 10には、2018年のWindows 10 Ver.1803（RS3）からcurl.exeコマンドが標準で付属している。curl（カール）は、cURLの意味で、URLを使って指定するプロトコルを実行するコマンドラインツールである（以後記事中ではcURLをオリジナルの表記として使う）。 curlは1990年代後半に開発が始められ、当初はUnix（SunOS）上で、名前もhttpgetだった。開発が進むとともに、複数のプロトコルをサポートするなどして「cURL」となったのは1998年で、この頃にLinuxにも移植されたようだ。 Windows 10に付属しているのは、cURLの仕様からMicrosoftが作
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
Code for Japan Summit の人気企画に、「BADオープンデータ供養寺」というコンテンツがあります。 BADオープンデータ供養寺 【セッション概要】 世の中のBADオープンデータが二度とこの世を彷徨わないように、「供養（データクレンジング）」する方法を考える場です。 データの公開に携わる行政職員の方や、データを利活用するエンジニア・データサイエンティスト等の皆さまと、より使いやすく品質の高いオープンデータの公開と加工の仕組みを考えていくために建立されました。 前半はパネリストが、日頃の業務の中で、どのようなBADオープンデータにいかに対処してきたか、実例やクレンジング技術を紹介します。 後半では事前投稿されたBADオープンデータを紹介しながら、オーディエンスの皆さまと一緒に成仏させる方法を考えて行きたいと思います。 ちょうど最近、総務省が公開しているマイナンバーカードの交付
![[BOD供養寺] スクレイピングしてきたデータの文字コードがおかしかったので修正した - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/be93b31a37afc243b38b7ba8e9100fd1abf6fc19/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCQk9EJUU0JUJFJTlCJUU5JUE0JThBJUU1JUFGJUJBJTVEJTIwJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFDJUUzJTgyJUE0JUUzJTgzJTk0JUUzJTgzJUIzJUUzJTgyJUIwJUUzJTgxJTk3JUUzJTgxJUE2JUUzJTgxJThEJUUzJTgxJTlGJUUzJTgzJTg3JUUzJTgzJUJDJUUzJTgyJUJGJUUzJTgxJUFFJUU2JTk2JTg3JUU1JUFEJTk3JUUzJTgyJUIzJUUzJTgzJUJDJUUzJTgzJTg5JUUzJTgxJThDJUUzJTgxJThBJUUzJTgxJThCJUUzJTgxJTk3JUUzJTgxJThCJUUzJTgxJUEzJUUzJTgxJTlGJUUzJTgxJUFFJUUzJTgxJUE3JUU0JUJGJUFFJUU2JUFEJUEzJUUzJTgxJTk3JUUzJTgxJTlGJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1lNGVhY2RkZjYzNzRlMzYwMzlhYzdlYjYzYWNhN2M4ZQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBoYWxfc2smdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWFiZjUyMWM5MWRmMzA0OGY4ZmI5ZWYwZjBkMTIxMWI5%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D37783e0d796a62b152961ca948c4be61)
Fraunhofer Heinrich Hertz Instituteが、Windows/macOS/Android/iOSといった各種OSでデフォルトでサポートされている動画圧縮規格「H.265/HEVC」の次世代規格となる「H.266/VVC」を発表しました。「H.266/VVC」はデータの圧縮効率を改善し、約50％ビットレートを削減することが可能となります。 Fraunhofer Heinrich Hertz Institute HHI https://newsletter.fraunhofer.de/-viewonline2/17386/465/11/14SHcBTt/V44RELLZBp/1 記事作成時点で、インターネットトラフィックの80％を占めているのが圧縮されたムービーデータです。Fraunhofer Heinrich Hertz Instituteが発表した新しい動画圧縮
ストリーム処理におけるApache Avroの活用について（NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05）
ストリーム処理におけるApache Avroの活用について （NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05） 株式会社NTTデータ 技術開発本部 関 堅吾（Apache Bigtopコミッタ, Apache Yetus PMC/コミッタ） https://oss.nttdata.com/techconf2019/Read less
)
ブロック (Unicode) - Wikipedia
Unicodeにおいて、ブロック（英語: block）とは、符号位置 (code points) の連続する範囲を意味する。ブロックには一意に名前が付けられ、重なりはない。各ブロックは hhh0 形式の開始符号位置と hhhF 形式の終了符号位置を持つ。ブロックは、未割当 (unassigned) または非文字 (non-character) である符号位置 (en) を、明示的に含むことができる[1]。名前付きのブロックのいずれにも属さない符号位置、例えば未割当の面である第4面-第13面に属する符号位置は、ブロックとして「No_block」という値を持つ。 逆に言えば、割当済 (assigned) の符号位置はすべて「ブロック名」(Block name) という特性（英語版） (property) を持つ。これはその文字 (character) があるブロックの名前である。これは符号位置
zip の中のファイル名 zip ファイルを展開（解凍）すると、書庫内の各データは元のファイル名で展開されます。すなわちファイル名情報も zip ファイル内に格納されています。 zip ファイル内に格納されている各ファイル名のエンコーディングは、現バージョンの zip の仕様だと UTF-8 フラグの有無を指定することができるようですが、 UTF-8 以外のエンコーディングを具体的に指定することができません。 歴史的に、従来より日本語ロケールの Windows で zip ファイルを作成すると（ツールにもよりますが）、ファイル名情報は Shift_JIS (CP932) で書き込まれます。最近の Linux や Mac は UTF-8 がほとんどです。 異なる OS で作成された zip ファイルを展開するときに、 UTF-8 フラグが付いていれば（最近の展開ツールであれば）問題なく展開す
🀈🀉🀊🀈🀉🀊🀈🀉🀊🀚🀚🀚🀋 🀋
タ ン ヤ オ
画数の多い漢字、ビャンビャン麺の「ビャン」 vs 機械印字
変なモノ好きで、比較文化にこだわる2人組（1号＆2号）旅行ライターユニット。中国の面白可笑しいものばかりを集めて本にした「 中国の変-現代中国路上考現学 」（バジリコ刊）が発売中。 前の記事：インドでおもちゃのロボットを買う ＞ 個人サイト 旅ライターユニット、ライスマウンテンのページ びゃん。 ビャンの字はアート ビャンビャン麺のビャンの字は57画（簡体字でも42画）だ。ビャンビャンで総画数は114画、さらに麺を加えると総画数130画になる。ラーメンをカタカナで書くと4文字なのに総画数は7画なので、18倍もの差になる。ものすごく多い。 当の中国人も驚愕するらしく、沢山のサイトが扱っている。中国人が漢字で驚くとは、インド人もびっくりみがある。 ビャンの字の由来は諸説あるが、だいたい一致しているのが、なんでも西安の近くの咸陽というところに、とある秀才が馬車で向かう際の情景なんだそうで、こんな
Unicode変体仮名一覧
Unicode（ユニコード）に登録されている変体仮名（へんたいがな）286文字（U+1B001〜U+1B11E）を、現代のひらがなごとにまとめ直し、ひらがなごとに字母を確認できるようにしました。 表の左列のリンクから、日本古典籍くずし字データセットに収録された実際の字形を確認できます。ただしすべての字母に対応する字形が収録されているわけではない点にご注意下さい。なお、変体仮名や字母の説明については、くずし字とは？をご覧下さい。くずし字の字形については、くずし字データベース検索（ひらがな（変体仮名）・カタカナ・漢字）やくずし字データセット 文字種（くずし字）一覧をご利用ください。
急なレスポンスタイム悪化から、オープンソースプロジェクトにPull Requestを送るまで - 弥生開発者ブログ
こんにちは、Misoca開発チームの黒曜(@kokuyouwind)です。 最近はシャニマスのイベントシナリオ感想記事をnoteにまとめたりしています。 😨 急に本番のレスポンスタイムが悪化した話 Webエンジニアにとって、「本番障害」という4文字ほど見たくないものはないでしょう。 本番障害ほどではないにしても、「急なレスポンスタイム悪化」もあまり見たくない文字列ですね。まぁ、見たくなくても向こうからやってくるんですが… というわけで、今回は本番レスポンスが急に悪化したときの話です。いろいろ調べた結果、利用しているオープンソースプロジェクトが原因だったことがわかりPull Requestを送ったので、その流れをまとめてみたいと思います。 ❗️ レスポンスタイム悪化の検知 Misocaでは監視ツールとしてMackerelを、APMツールとしてSkylightを利用しています。 本番レスポン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【図解】【3分解説】UnicodeとUTF-8の違い！【今さら聞けない】 - Qiita
Ridiculously fast unicode (UTF-8) validation – Daniel Lemire's blog
Windowsでファイルやフォルダーに「使わない方がいい」文字 (1/2)
シュトヘル達の名前を西夏文字 (Unicode) で書く
ギョーザの漢字は？ チコちゃん、それはないよ
SJIS-macに変換したはずなのにSJIS-winになる - Qiita
【Rust】文字列型のUTF-8検証の中身 - Qiita
Goで高速JSONライブラリを作るためにしたこと | メルカリエンジニアリング
UTF-8 の文字列をできる限り Shift_JIS に変換したい(実践編) | うなすけとあれこれ
プログラマーから見たPDFファイル - アンテナハウス PDF資料室
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
UTF-8 の文字列をできる限り Shift_JIS に変換したい - きりきりやま
山﨑の「﨑」とか、高橋の「高」の字がいわゆる"梯子高"の人とか
（メモ）同じ繁体字でも台湾と香港ではグリフが違う話 - 水底の血
Windows 10で標準で用意されるようになったcurlを使ってみる (1/2)
新しく登場したエモい絵文字たちをご紹介します
[BOD供養寺] スクレイピングしてきたデータの文字コードがおかしかったので修正した - Qiita
「H.265/HEVC」と同じ画質でファイルサイズを50％削減できる次世代動画圧縮規格「H.266/VVC」が登場
Python で zip 展開（日本語ファイル名対応） - Qiita