タグ

unicodeに関するsomathorのブックマーク (52)

  • 「住所は英数字もすべて全角で入力してください」はなぜそうなったのか - Qiita

    Webサービスのフォームに住所を入力するとき、丁目や番地などを入れる欄について、数字やハイフンを全角で書かなければいけない「全角縛り」をやっているフォームをよく見ます。半角文字を入力してしまってエラーになったり、咄嗟に変換方法を思い出せなかったり、全角と半角の見分けが付きづらかったり、「全角縛り」であることが明示されていなかったり、「ハイフン」としてどの文字を使うべきかわからなかったり……と、陶しさを感じることが多くあります。 「住所は全角のみ」(数字やハイフンも絶対に半角を受け付けない)という仕様がどういう経緯で生まれて、どう広まっていったのかが気になってる。いま存在しているのは過去の仕様や慣習の踏襲として理解できても、そもそもなぜそれらが生まれたのかが理解できない。 https://t.co/ZLz0Pw9GOK — ymrl (@ymrl) July 29, 2024 これについて

    「住所は英数字もすべて全角で入力してください」はなぜそうなったのか - Qiita
  • UTF-8 の BOM について - 将棋プログラミング

    1.はじめに UTF-8 の文字コードのファイルには、BOM (Byte Order Mark) がある場合とない場合がある。 Unicode の規格では、BOM は、推奨されないが、許容されている。 ja.wikipedia.org 今回、必要があり、色々な OS や言語で、UTF-8 の文字コードのファイルを作成した時、BOM が記録されるか、されないか、を調べた。 2.色々な OS や言語での BOM 2.1 Windows 10, Visual Studio, C++, _wfopen (_tfopen) // Visual Studio 2005 以降 保存 FILE *fp = _wfopen(name, _ L"w, ccs=UTF-8"); if (fp == NULL) { // エラー処理 } fwprintf_s(fp, L"ABC漢字123\n"); fclose(

  • Windowsコードページの謎|kzn

    語が格的に使えるようになりだした頃、そのコードはJISコードを巧妙に細工してモード切替を不要にしたシフトJISと呼ばれるものが使われました。当時は英語のみが使える環境でプログラムが作られることが殆どだったので、これを移植して日語を扱えるようにすれば充分だということだったのです。 文字コード 最初に使われたのはCP/M-86という説もありますが、一般的に使われるようになったのはMS-DOS(PC-DOS)が最初です。これはWindowsにも引き継がれ、Macintoshも日主導で日語化が行われたという経緯もありシフトJISが使われました。 さてシフトJISの問題は米国標準であるASCIIに対する拡張であって、それ以外の国のローカルコードのことを考えていないことです。例えば英国では一部の記号がポンド記号に置き換わっているコードが使われていましたし、他のヨーロッパ諸国の言語でもいろい

    Windowsコードページの謎|kzn
  • バックスラッシュと円記号の歴史と違い

    最近知ったんですが、Windowsではキーボードから円記号(¥)の入力はできないらしい。 というのも キーボード右上の¥キー キーボード右下の\キー のどちらかを押せば円記号(¥)を入力できますが、どちらを押しても入力されるのは円記号(¥)に偽装されたバックスラッシュ記号(\ )らしい。 皆さんこれ知ってました? いや正直、これを聞いても「何言ってんだコイツ」って思う人が大半だと思いますし、私も今でもそう思います。 これは「バックスラッシュと円記号問題」などと言って、Windowsで昔から続く”呪い”のようなものらしいのですが この”呪い”を理解するには文字コードの歴史を知る必要があります。 文字コードとは? その前に、そもそも文字コードってなによ?という根的な話からすると、文字コードは「パソコンに文字を覚えさせるための暗記表」みたいなものです。 パソコンは2進数しか理解できないので あ

  • 絵文字を支える技術について|nona

    はじめにこちらはmhidakaが建立したAdvent Calendar Day.3となります。 こんにちは、はじめまして、のなと申します。mhidakaさんのTweetを見つけて、初めてAdvent Calendarなるものを書いています。なにかお作法間違っていたら大目に見てください、よろしくお願いします。 軽く自己紹介をさせていただくと、普段はGoogleAndroidTextまわりの開発を行っており、DroidKaigiやShibuya APKで発表させていただいたりしています。最近はほぼ絵文字の話しかしてないので、絵文字おじさんと思われてそうですが、普段の仕事絵文字に限らず、Androidの文字表示の部分は大抵面倒をみています。 今回この機会をいただいたので、どんな内容を書こうか迷ったのですが、やはり皆が読んで面白い内容というと、絵文字になるのかなぁ、ということで性懲りもなく絵

    絵文字を支える技術について|nona
  • 文字コード表 シフトJIS(Shift_JIS)

    シフトJISの1バイトコード(半角文字)のエリア 0x00~0x1f、0x7f は制御コードです 0x20~0x7e はASCII文字です 0xa1~0xdf は半角カタカナです シフトJISの2バイトコード(全角文字)のエリア(JIS X 0208の漢字エリア) 上位1バイト  0x81~0x9f、 0xe0~0xef 下位1バイト  0x40~0x7e、 0x80~0xfc ですが機種に依存しない観点より、HTMLで以下の水色エリアは使用しないのが無難です 水色エリアはJIS X 0208 (1990) to Unicode 漢字コード表に存在しないコードです 0x8540~ 0x889e は機種依存文字の主なエリアです 0xeb40~ 0xeffc はMacOS では縦書用文字、Windows では特殊な外字エリアです 0xf040~ は外字エリアです(記載していません) perl

  • アイヌ語仮名「ㇷ゚」に対する正規表現の罠

    導入 アイヌ語は日語と異なり、閉音節(子音で終わる音節)も存在するので、表記の際音素文字であるラテン文字なら、そのまま p, t, k, m, n, s, r などの子音文字を後ろの付ければ良いわけなので、アイヌ語ローマ字表記では、何も問題が生じない。しかし、元々開音節言語である日語に特化したカタカナのような仮名文字で表記する際、鼻音 n は「ン」でなんとかなる(実はそれでもまずい事になっているけどここでは割愛する)が、p, t, k, m, n, s, r, h はどうしようもないので、特殊の捨て仮名(小書き仮名文字)を利用することになっている。 具体的には以下のような特殊仮名文字(通称 アイヌ語仮名)である。 ㇷ゚ -p ッ -t ㇰ -k ㇺ -m ㇱ -s ㇻ -(a)r, ㇼ -(i)r, ㇽ -(u)r, ㇾ -(e)r, ㇿ -(o)r お分かり頂けただろうか… 問題 r

    アイヌ語仮名「ㇷ゚」に対する正規表現の罠
  • MySQLのutf8mb4と戦った話 - Uzabase for Engineers

    皆様こんにちは、NewsPicksエンジニアの米澤です。 先日 2023/03/30は、こちらでアナウンスしていた通り、サービスの停止を伴うシステムメンテナンスを実施させて頂きました。 NewsPicksをご利用頂いている皆様には、ご迷惑おかけいたしました。 今回はこのメンテナンスの中で行われたDBテーブルのmigrationについてお話ししたいと思います。 ことの始まり やったこと 方針決め utf8mb4に対応していないテーブルを調べる migrationを作成する 影響範囲を調べる 開発環境でリハーサルを行う メンテナンスの日 最後に ことの始まり NewsPicksではバグの検知にBugSnagを利用しています。 ある時、BugSnagにこんなエラーが通知されてきました。 org.springframework.orm.hibernate4.HibernateJdbcExcepti

    MySQLのutf8mb4と戦った話 - Uzabase for Engineers
  • macOS 13.3.1 Venturaでは、ファイル名に濁音やアクセント記号が含まれるとダブルクリックでファイルが開けない不具合は未修正。

    macOS 13.3.1 Venturaでは、ファイル名に濁音やアクセント記号が含まれるとダブルクリックでファイルが開けない不具合は修正されていません。詳細は以下から。 Appleは現地時間2023年04月07日、絵文字の肌の色が選択できない/Apple Watchを利用したMacのロック解除ができない不具合と2件のゼロデイ脆弱性を修正した「macOS 13.3.1 Ventura (22E261)」をリリースしましたが、

    macOS 13.3.1 Venturaでは、ファイル名に濁音やアクセント記号が含まれるとダブルクリックでファイルが開けない不具合は未修正。
  • 「ソ」「ソ」による文字化けについて - Qiita

    最上位ビットに違いがあることが分かった。 「プログラマのための文字コード技術入門」という2010年に購入したを引っ張り出して軽く眺めてみた。 JISの8ビット符号にはGR領域とGL領域があり、GR領域を使用する場合には第8ビット(最上位ビット)に1をセットして用いるとのこと。 変換できないので「?」にして戻した後、第8ビットに1をセットする変換がされたことにより「ソ」になってしまったのではないかと推測している。 逆疑問符[¿」は「ソ」と同じコードであり、こちらはLatin-1の文字コードが使われたようだ。 ちなみに文字化けについては、環境変数に「NLS_LANG=JAPANESE_JAPAN.JA16SJISTILDE」を追加することで解消された。 「ソ」よる文字化け Shift-JISは半角文字と全角文字を表せますが、1文字が何バイトなのかが固定されていないのです。なので「ソ」など2バ

    「ソ」「ソ」による文字化けについて - Qiita
  • JavaScript: 文字数を正確にカウントするには? - Qiita

    この投稿ではJavaScriptで文字数をできるだけ正確にカウントする方法について取り上げます。 文字数とは? 要件で「文字数を表示してほしい」「○文字以上はバリデーションエラーにしたい」と文字数を考慮しないとならないことがあります。 そもそも文字数とは何でしょうか。 たとえば、アルファベットの「A」は1文字と数えられそうです。 次の絵文字は、何文字になるでしょうか? この絵文字はiOSであれば14.5の環境では、UI上では上のように1文字のように表示されます。しかし、それ以前のバージョンでは、同じ文字列データでも😵💫のように2文字で表示されます。なお、この絵文字は3つのコードポイントU+1F635 U+200D U+1F4ABからなります。この絵文字の「文字数」はいったい何文字として扱ったらよいのでしょうか。 以上のように、ひとことで文字数と言ってもデータと見た目と環境の3つのややこ

    JavaScript: 文字数を正確にカウントするには? - Qiita
  • 端末の文字幅問題の傾向と対策 | IIJ Engineers Blog

    電子メール、ネットワーク機器集中管理、異常検知、分散処理、クラウド基盤などのシステム開発に従事。古代Rubyist。 CLI や TUI なアプリケーションを使っていると、端末の画面が崩れてしまうことがよくあります。 たとえば、こんな TUI が、 環境によってはこんな感じで崩れます。 スクロールなどをしながらしばらく使っているとさらにどんどん崩れていきます。 こうなってしまった場合、とりあえず Ctrl-l で画面を再描画することで、大抵はなんとか読める程度にリセットできますので、ことあるごとに Ctrl-l を連打することになります。 ですが、どうしようもないケースもままあります。 例えば、私の場合は以下のようなシチュエーションで困ります。 w3m でテーブルなどを表示するとレンダリングが崩れる less でログの閲覧の際に表示されるべき文字が表示されず見落としが発生する Wander

    端末の文字幅問題の傾向と対策 | IIJ Engineers Blog
  • PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる

    PostgreSQL 10のICUコレーションを使うと日語を普通にソートでき、更に文字順序までカスタマイズできる (Last Updated On: 2018年8月13日)PostgreSQL 10からICU(International Components for Unicode)のロケール/コレーションがサポートされました。 これまでサポートされてきた、libcのja_JPロケールの貧弱な日語ソート機能とは比べ物にならないくらい高機能な文字比較をサポートしています。日語や他の言語での照合順序を柔軟に変更できます。 マトモな日語ソート順でソートする(かなり重要) 数字を後にソートする 大文字を先にソートする 仮名を先にソートする 自然ソートする これらをまとめて特別なソート順にする といったことがPostgreSQL 10から行えます。 基的な使い方 ja-x-icuはICUサ

    PostgreSQL 10のICUコレーションを使うと日本語を普通にソートでき、更に文字順序までカスタマイズできる
  • ハイフンに似ている横棒を全て統一するᅳㅡ˗𐆑–᭸‒-─−▬𐄐—━‐‑ー﹣―ー﹘-⁃➖⁻! - Qiita

    はじめに これらの横棒、コンピュータにとっては全て違うのですが 見分けがつくでしょうか? -˗ᅳ᭸‐‑‒–—―⁃⁻−▬─━➖ーㅡ﹘﹣-ー𐄐𐆑 郵便番号、住所、電話番号など、横棒が使われているデータを扱うとき、 人が入力したデータや購入したデータであると、同じ記号が使われていないことはよくあることです。 090-1234-5678 090᭸1234᭸5678 090‑1234‑5678 090−1234−5678 これらの電話番号の文字列も phone_no_list = ['090-1234-5678', '090᭸1234᭸5678', '090‑1234‑5678', '090−1234−5678'] # 文字をUnicodeコードポイントに変換 for n in phone_no_list: # 文字列の4番目の横棒の文字コードを見てみる print(n[3], ord(n[3]

    ハイフンに似ている横棒を全て統一するᅳㅡ˗𐆑–᭸‒-─−▬𐄐—━‐‑ー﹣―ー﹘-⁃➖⁻! - Qiita
  • Your code displays Japanese wrong

    A static site to link people to when their code is displaying Japanese wrong. View the Project on GitHub heistak/your-code-displays-japanese-wrong Why am I here? If someone gave you a link to this page, that person probably thinks your code displays Japanese wrong. In short, from a native Japanese eye, yѳur ҭєxҭ lѳѳκs κιnd ѳf lικє ҭЋιs. This page will give you a brief description of the glyph appe

  • 第157回 MySQLのデフォルトcollationの注意点 | gihyo.jp

    MySQLではcharacter set(以後、charset)やcollationをグローバル、データベース、テーブルやカラムレベルで設定することができます。今回はMySQLのデフォルトcollationの注意点を紹介したいと思います。使用するMySQLのバージョンは8.0.26です。 charsetやcollationとはなにかについては説明はしません。よって、charsetやcollationについてご存知ない方は、先にマニュアル「第10章 文字セット、照合順序、Unicode」をご確認ください。 charsetやcollationの各レベルの設定方法 グローバル 以下のシステム変数を設定します。 character_set_server… サーバーのデフォルトのcharset collation_server… サーバーのデフォルトのcollation データベース CREATE

    第157回 MySQLのデフォルトcollationの注意点 | gihyo.jp
  • \と¥の問題 - 立命館大学情報理工学部セキュリティ・ネットワークコース プログラミング言語サポートページ

    バックスラッシュ\を入力する時に円記号¥に文字化けが起きる理由 プログラムのソースプログラムは(LaTeXのソースファイルやWebページのHTMLファイル等と同様に)テキストファイル(教科書ではテキスト形式と呼ばれています。プレーンテキスト(plain text)とも呼ばれることがあります)というファイル形式で書かれます。このテキストファイルはどのようなOSでも必ずサポートされている最も基的なファイル形式であり、実体は1バイトを単位として文字コードで表現されたデータが先頭から順に並んでいるだけのファイルです。 その文字コードは歴史的にはさまざまなものがありましたが、次第にアメリカで定められたASCIIコードが主流になり、世界中で使われるようになりました。これが国際的な規格になったものがISO/IEC 646です。これらは7ビットの文字コードなので2の7乗つまり128種類の文字が表現でき、

    \と¥の問題 - 立命館大学情報理工学部セキュリティ・ネットワークコース プログラミング言語サポートページ
  • BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)

    かつてWindowsでテキストファイルといえばシフトJIS形式のものが大半だった。しかし最近では、UTF-8形式のテキストファイルも普通に見かけるようになってきた。世の中はUTF-8が主流になりつつあると言っていいだろう。 しかし、WindowsUTF-8を使うと、ちょっと困ったことがある。それは、エクスプローラーの検索欄などで用いるWindows Searchが、UTF-8にはしっかり対応していないのである。正確に言うと、Windows Searchはファイル先頭に「BOM」のあるUTF-8は認識して正確にインデックス化し、ファイルの全文検索が可能になるが、BOMのないUTF-8では正しくインデックス化できず、ファイルの全文検索はASCIIコードのみ可能で、日語などの非ASCII文字では全文検索ができない。 同じ内容のテキストをUTF-8UTF-8 BOM付き、UTF-16ビッグエ

    BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)
  • ハイフンとかマイナスとかダッシュとか | 404 motivation not found

    目次 ハイフンに似た文字参考ソースコードを読んでいたら、既存処理にとある文字列変換処理があった。 例 (ソースはイメージです) const convert = (arg) => { return arg.split('ー').join('‐'); }; いざテストをしようと思って、「—」を入力したら期待値が出なかった。 なぜならば、この処理は「ー(全角長音)」を「‐(全角ハイフン)」に変換しているので、「—(全角ダッシュ)」はスルーされるからだ。 ハイフンに似た文字 気になったので色々調べたら、少なくとも以下の文字があることがわかった。 -(全角ハイフンマイナス) -(半角ハイフンマイナス) ‐(全角ハイフン) −(全角マイナス) ‒(フィギュアダッシュ) —(全角ダッシュ(emダッシュ)) –(二分ダッシュ(enダッシュ)) ―(ホリゾンタルバー) ー(全角長音) ー(半角長音) ─(罫

    ハイフンとかマイナスとかダッシュとか | 404 motivation not found
  • GitHub - trueroad/tr-NTTtech05: NTT Tech Conference #5 Presentation 「PDFのコピペが文字化けするのはなぜか?~CID/GIDと原ノ味フォント~」関連資料

    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

    GitHub - trueroad/tr-NTTtech05: NTT Tech Conference #5 Presentation 「PDFのコピペが文字化けするのはなぜか?~CID/GIDと原ノ味フォント~」関連資料