SmartHR でプロダクトエンジニアをしている tmtms です。読み方がわからない(自分でもわからない)ので社内では tommy と名乗ってます。 2月に開催された社内LT大会第3回で「ショートカットと端末」というネタで発表したのですが、とても5分に収まる量ではなかったのでここにしたためておきます。 キーバインド macOSのテキスト編集のショートカットとEmacsとbashのキーバインドを比較するとこんな感じです。 control macOS Emacs bash A 行頭に移動 行頭に移動 行頭に移動 B 左に移動 左に移動 左に移動 C - prefix 中断 D 右文字削除 右文字削除 右文字削除/入力終了 E 行末に移動 行末に移動 行末に移動 F 右に移動 右に移動 右に移動 G - 中断 中断 H 左文字削除 ヘルプ 左文字削除 I - タブ タブ J - 改行 改行 K
前回のエントリで見たように、Adobe-Japan1フォントでは、欧文約物形状のダッシュ（CID+138）がU+2014 EM DASHに、和文約物形状のダッシュ（CID+661）がU+2015 HORIZONTAL BARに対応している（下図）。しかし、U+2015 HORIZONTAL BARがもともと「日本語組版のための全角ダッシュ」としてUnicodeに収録されたものだとは考えにくい。では、これは何なのか。わかっているいることを以下にメモするが、あらかじめ言っておくと、あまりまとまりはない。 Unicode Standardの「6.1 Writing Systems」には、「U+2015 HORIZONTAL BARは、ある種のタイポグラフィのスタイルで、引用文の導入に用いられる」と記されている。 U+2015 HORIZONTAL BAR is used to introduce
#!/usr/bin/ruby def hankaku b case b when 0xA1..0xDF [b].pack('C').encode(Encoding::UTF_8, Encoding::Shift_JIS) when nil '' else format('\\x%02x', b) end end (0xA1..0xF4).each {|bhi| (0xA1..0xFE).each {|blo| echar = [bhi, blo].pack('CC').force_encoding(Encoding::EUC_JP) begin uchar = echar.encode(Encoding::UTF_8) rescue Encoding::UndefinedConversionError next end uhex = uchar.unpack('H*').first sl
この記事は YAMAP エンジニア Advent Calendar 2020 の九日目になる予定です。 qiita.com tl;dr URL エンコードされた文字列を、コマンドラインでシュッとデコードしたかったので調べたのでメモ。 URL エンコードされる文字列は以下の通り。 負けない事 投げ出さない事 逃げ出さない事 これを URL エンコードすると、以下のような文字列となる。 %E8%B2%A0%E3%81%91%E3%81%AA%E3%81%84%E4%BA%8B%0D%0A%E6%8A%95%E3%81%92%E5%87%BA%E3%81%95%E3%81%AA%E3%81%84%E4%BA%8B%0D%0A%E9%80%83%E3%81%92%E5%87%BA%E3%81%95%E3%81%AA%E3%81%84%E4%BA%8B 本記事で利用する環境は以下の通り。 root@
Cygwinの具体的な日本語対応の方法 Windows環境でUNIX/Linux/BSD風のコンパイル環境を利用できるフリーソフトウェアCygwinで日本語を利用するに当たり、CygwinのセットアップとCygwin日本語パッケージのインストールと日本語環境設定でCygwinをインストールし、lsやcatで表示される日本語は正しく表示できるようになったと思います。 これらの設定を行った上でshellやコマンド等が出力するメッセージが文字化けする場合には、ソフトウェアの国際化に関連したメッセージカタログ(po/mo形式)とのミスマッチがその要因として濃厚で参照しているのはバイナリ形式の拡張子が.moのファイルであることがわかり、それを編集すればよさそうだという概要まで見てきましたので、ここでは、その具体的な方法を書きます。 尚、メッセージカタログの編集をしたのに反映されないとか、日本語用ファ
2023.05.10 官報に使われる「官報文字」というものがあります。 そこには渡辺さんの「辺」の異体字が１４０文字も登録されています。 日本語の常用漢字には２１３６文字ありますが、そこには邉や邊などは入っていません。 そこでＪＩＳの第四水準までを含むJIS X 0213という標準を定め、スマホやパソコンではここまでを標準的に表示できるようにしています。 ところが我が国の戸籍で使ってもよいとされている文字はそれを遙かに超えていて、少なくとも５５，２７０文字もあります。 全ての国民の氏名をコンピュータで扱えるようになることを目指して、戸籍統一文字や住基ネット用の統一文字を網羅した「文字情報基盤」を２０１１年に策定し、それにあわせたフォントを作成し、無償で提供しています。 この「文字情報基盤」（ＭＪ）には、５８，８６２文字が含まれています。 しかし、このＭＪを全庁的に採用している自治体は、川口
. ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) (( )) . ( ) ( ) = ( ) (( )) [ ] ( ) = = ( ) ( ) ( ) ( ) ( ) ( ) ( )
いよいよ、0x5c問題について書きます。 まず、0x5c問題とは何かということですが、 とりあえず私は、「2バイト目に0x5cを含む文字が起こす問題全般」だと考えています。 この「2バイト目に0x5cを含む文字」は後述します。(・・・もう見えてるかもしれませんが（笑）) その中で今回書くのは英語版環境や日本語処理に問題がある環境で発生する問題です。 (文字コード指定可能な環境ならば当然文字コードを正しく指定しなければ問題が発生します。 言語が漢字(文字)コード指定を持っている(だったはず)のRuby言語では要設定確認です) ちなみに何で英語版は問題になるのかといえば、たいていの場合、1文字を2バイトで表すなんてこと自体、 考えて作られてないからです。(アルファベットだけなら1バイトで十分) 前回のASCIIコード表を見ていただけると分かると思いますが、0x5cは「\」です。 そして、「\」
美乳テーブルとは 「美乳テーブル」という物がある。 「EUC-JP の文章を Shift_JIS だと誤認識されない様に、EUC-JP 固有のバイト値を文章先頭付近に埋め込んでおく」という物。 具体的に、Shift_JIS には 0xFD と 0xFE が現れず、EUC-JP にはそれが現れるので、その値を含む文字コードを書いておこうという事で、その文字の集合に付いた名前。 “美” = 0xC8FE、“乳” = 0xC6FD。 各文字エンコーディングの事情 但し、これは EUC-JP での話。 一応、文章の先頭付近に日本語の文字を書いておくのは、他の文字エンコーディングでも認識のヒントにはなるけど。 逆に「Shift_JIS の文章を EUC-JP だと誤認識されない様にする」には、EUC-JP にはないバイト値の 0x80〜0xA0 を書けばいいんだろうけど、これは沢山ありそうだから、慎
コンピュータによるテキスト表記とPDFのフォント埋め込みについて 更新日: 2021/1/31 はじめに PDFのフォント埋め込みとはなにか、フォント埋め込みがなぜ必要かについて理解することを主な目標とします。そのため必要な知識として、コンピュータでの文字の取り扱いに表記と情報処理の2種類があること、そして、文字コードとグリフ、アウトラインフォント、PDFのテキスト表示の仕組みとフォント埋め込みについて説明し、フォントを埋め込まない時に発生する問題などについても事例を挙げて解説します。 基礎知識 PDFへのフォント埋め込みについて理解するには、コンピュータの内部で文字を取り扱ったり、画面表示・紙に印刷する仕組みについての知識が必要です。そこで最初に前提となる知識についてできるだけ簡単に説明します。 字形、字体 一般の言語生活では、文字は言語を表記するための道具であり、主に書いたり・読んだり
C++標準化委員会、ついに文字とは何かを理解する: char8_tという記事が話題だってので、つらつらと書いてみました。 「グリフ」について グリフ（glyph）という言葉の定義をめぐって でも触れられていますが、「グリフ」という言葉が「字体」を指すのか「字形」を指すのかってのは議論がありますね。文字コードの文脈では普通「字形」の意味だとして話を進めることが多いように思います。 CJK統合漢字について Wikipediaの記事にまとまっていますが、実際に推進していたのは中国みたいですね。うまくやればあんまり問題なかったんでしょうが、あんまりうまく行かなかったんですが、それでも国ごとにその国の過去にあった文字コードとの互換性は取れているので、実際の所CJK統合漢字ってあんまり問題にはなってないと思うんですよね。中国語フォントと日本語フォントを切り替えないといけないって問題はありますけど、それ
Windowsでのやり方を書いたので、今度はLinuxでのやり方をメモ。 Linuxでファイルを16進数テキストに変換（bin -> hex） xxd -p 入力ファイル > 出力ファイル名 （例）xxd -p james.bin > james.hex Linuxで16進数テキストをファイルに変換（hex -> bin） xxd -r -p 入力ファイル名 > 出力ファイル名 （例）xxd -r -p james.hex > james.bin これでファイルを16進数で作成できるなぁ〜 関連エントリ Windowsでファイルを16進数テキストに変換したり、16進数テキストをファイルに変換したりする方法
最近procmailでメールの振り分けをしているのだが、日本語のフォルダへの振り分けってどうするの？ と悩んだので調べた。 命名規則自体はRFC2060に記載されているとおり、UTF-7の修正版が用いられている（UTF-7についてはIT用語辞典を参照のこと）。 Maildir以下のサブフォルダはこの規則に従って作成されるので、目的となる日本語フォルダ名を修正版UTF-7（IMAP-UTF7などとも呼ばれる）に変換し、それを振り分け先として指定すれば良い。 IMAP-UTF7への変換は文字コード変換ツールがあるので、こちらを使えばお手軽。たとえば「登録関係」というフォルダなら、「.�dnuTMpWiT8I-」というフォルダ名となる。
日本語の漢字は、戸籍などに使われているものも含めると６万字あるのに対し、コンピューターは、実は１万字しか扱うことができません。これに対し、このほど１５年越しの作業の末、６万字すべてが統一の規格にまとめられて、コンピューターがすべての漢字を扱えるようになり、ビッグデータの活用をはじめさまざまな効果が期待されています。 中には、メーカーなどが独自に対応した外字もありますが、コードが無いために、メーカーごとの互換性が無く、データを受け渡してもコンピューターが認識できずに「文字化け」してしまったり、ある人の名前に本名の外字を充てたものと略字を充てたものの２つのデータがあった場合、コンピューター上では、別の人と認識されてしまったりするなどの問題が起きていました。 このためＩＰＡ＝情報処理推進機構は平成１４年から、経済産業省とともに外字を含めたおよそ６万字の漢字１つ１つに、コードを割りつける作業を進め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く