* 仕様書 [REFS[ - [18] [CITE[The Unicode Standard, Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-09T10:59:29.820Z]] ]REFS] * ハイフン文字 [3] [[ハイフン付け]]関連 [SEE[ [[ハイフン付け]] ]] - [4] [[改行]]抑制: [CODE[U+2011]] [CODE(charname)@en[NON-BREAKING HYPHEN]] [CODE[U+0F0C]] [CODE(charname)@en[TIBETAN MARK DELIMITER TSHEG BSTAR]] [SRC[>>18]] * 文脈 [FIG(short list)[ [35] [[横線]]と[[縦線]]の用法 - [[ハイフン]] -- [[複合語]]の区切り -- [[対]] (対戦結果の区切り) -- (複数で) 横区切り線 -- 該当なし -- 省略 -- 階層区切り --- [[住所]]の丁目、番、号、室の区切り --- 学級番号の学年と学級の区切り (、出席番号の区切り) --- [[電話番号]]の[[局番]]区切り --- [[座席番号]]の区切り --- [[面区点位置]]の区切り - [[負]]記号 -- [[負符号]] -- [[減算]] -- [[震度]]の「弱」 -- [[負]]の[[電荷]] -- [[陰イオン]] - [[長音記号]] - [[取り消し線]] - [[傍線]] - [[縦線踊り字]] - [[罫線素片]] - [[モールス符号]]の[[転写]] - [[マイナスドライバー]] - [[伏せ字]] - [[ダッシュ]] -- [[範囲]] -- [[副題]] -- [[インタビューアー]]発言 -- 間 -- [[挿入句]] --- [[引用]] ]FIG] [FIG(short list)[ [10] [[ハイフン]] - [[ハイフン付け]] - [[[CODE[-]] (Unix)]] - [CODE[--]] ]FIG] * 人名をつなぐ横線 [16] [[複合姓]] [FIG(quote)[ [FIGCAPTION[ [15] [CITE[二分ダーシ - JAGAT]], [TIME[2020-03-27T05:47:34.000Z]], [TIME[2024-10-19T08:00:08.190Z]] ]FIGCAPTION] >二分ダーシは、固有名詞などの単語の結合にも用いる。例えば、“Boyle–Charle's law”のように、科学の法則では人名をつないで示す例があり、この場合はハイフンではなく、二分ダーシでつなぐ。片仮名で示す場合も同様に“ボイル–シャルルの法則”のように2人の人名を二分ダーシでつなぐ。 >なお、二分ダーシは、図番号・表番号で、“図3–5”のように章番号を組み合わせて表示する場合や、外国人名の片仮名表記で複合姓を示す場合にも使用されている。 ]FIG] [17] [CITE@ja[★旧版★【西洋風ネーミング雑話】その姓、なにモノ??■改稿版を再投稿済み■]], [TIME[2024-10-19T08:02:07.000Z]] > ラテン文字(アルファベット)表記の場合、複合姓は「-」(ハイフン)で結びます。それが日本語カタカナ表記になる場合は、通常「゠」(ダブルハイフン)もしくは、その代用として「=」(イコール)に変わります。 [FIG(quote)[ [FIGCAPTION[ [25] [CITE@en[RE: UTCへのレターの本体]], [[Kobayashi Toshi]], [TIME[2024-07-03T13:13:52.000Z]], [TIME[2024-10-19T08:20:21.849Z]] ]FIGCAPTION] >最近の現状は,そうかもしれませんが,本来的には二分ダーシだと思います. 複合姓は,複合語ではなく,独立した姓+姓だと思います. > 複合語であれば,ハイフンですが,単語と単語の結合は,複合語を示す際のハイフンとの区別のために二分ダーシが原則でしょう. > しかし,ハイフンと二分ダーシは区別がつきにくく,また,ハイフンの入力と比較し,二分ダーシは面倒です.ですので,最近は,ハイフンと二分ダーシは区別しなくてよいんだ,どっちでもよいのだ,数字の範囲を示す場合も含めて,すべてハイフンでよいんだ,ということを書いた本もあります(数字の範囲を示す場合にハイフンを使用した例は,最近はけっこう目にします). ]FIG] [30] [CITE@en[Topic Q&A List]], [TIME[2024-10-19T08:34:47.000Z]] >[B[Q.]] If someone has a compound surname like “De Chicago-Smith,” do we use an en dash? I understand the rationale, but I think it looks weird (but who cares what I think?). What about “De Chicago-Von Suedkurve Auf Der CSS&SBRR,” for example? >[B[A.]] Although a simple hyphenated name normally takes (no surprise) a hyphen, a name with multiple appendages might be able to pull off the slightly longer en dash. Anyone with such a dazzling name as “De Chicago–Von Suedkurve Auf Der CSS&SBRR” deserves all the dashes and doodads they want. (And we care what you think.) [27] [CITE@ja[Xユーザーの日本結核・非結核性抗酸菌症学会【公式】さん: 「医療従事者の間でも、実はあまり知られていない事実。 https://t.co/1DnM5uT7Ox」 / X]], [TIME[午前8:45 · 2024年10月8日][2024-10-07T23:45:13.000Z]], [TIME[2024-10-08T04:40:21.000Z]] [26] >>27 のように hyphen で[[複合姓]]区切り、 en dash で列挙が1つの[[複合語]]に混在する事例があるらしい。 [28] ということで[[複合姓]]区切りは現実問題として en dash より hyphen が好ましい。 [29] また、[[組版]]的厳密性が求められない日常では [CH[-]] でも十分。 [31] [[ChatGPT]] 先生は、すべてではないにせよ多くの [[style guide]] が[[複合姓]]の[[横線]]で [[word wrap]] するべきではないとしていると述べています。 [要出典] [32] そのために使える[[文字]]としては、 [CC[U+2011]] [CN[NON-BREAKING HYPHEN]] があります。 [33] [[欧文]]では [[hyphenation]] があるため、混乱を避けるための措置です。 [[和文]]ではこの措置は不要であり、 double hyphen ないし hyphen の後で改行できます。 [34] [[漢民族名]]の[[ラテン文字]]表記で[[音節]]ごとに1語として[[分かち書き]]、[[capitalize]] するとき、姓や名のブロックを表すためブロック内で使う [CH[-]] も、 [[複合姓]]・[[複合名]]として扱うのがいいらしい。 * [CC[U+002D]] [CN[HYPHEN-MINUS]] ([CH[-]]) [19] [[ハイフン]]から[[マイナス]]を引きます ([[哲学]])。 [21] [CITE@en[Charinfo — "-"]] ( ([TIME[2013-03-30 02:40:32 +09:00]] 版)) [20] [CITE@ja[緒方恵美@2/11「M's BAR」開催!さんはTwitterを使っています 「「Hang In There!」計画、299日目! スタジオへの通りすがりにハッケン。 「僕も、見たい…!」 エヴァンゲリオンイラスト集・複製画展。紀伊國屋書店で2/14迄。#エヴァ Hang in there! = 我々が直面している問題は困難だけど、諦めずにがんばれ!ちいさな楽しみをみつけていこう。 #HangInThere https://t.co/l7bdLaUFcw」 / Twitter]] (午前10:29 · 2021年1月26日 [TZ[+09:00]], [TIME[2021-01-26T02:33:43.000Z]]) [FIG(short list data)[ [[文字]] :[F[文字]]:[CH[-]] :[F[関連]]:[CH[㆐]] :[F[関連]]:[CH[±]] ]FIG] * [CC[U+1806]] [CN[MONGOLIAN TODO SOFT HYPHEN]] ([CH[᠆]]) [11] [CITE[RFC Errata Report » RFC Editor]], [TIME[2021-04-23T09:39:24.000Z]] [12] [CITE@en[Todo hyphen · Issue #30 · w3c/mlreq · GitHub]], [TIME[2024-10-19T07:33:48.000Z]] [13] 関連: [[Unicode蒙古文字]] * [CC[U+2011]] ([CH[‑]]) non-breaking hyphen [FIG(quote)[ [FIGCAPTION[ [60] [CITE@ja[非分離スペースと非分離ハイフン、使っても問題ない? - 千里の道をまだまだ走る~ときどきひとやすみ~]], [TIME[2024-10-19T12:41:20.000Z]] ]FIGCAPTION] >医薬系の翻訳会社(複数)から、数字と単位の間の半角スペースや治験薬コード名のハイフンには「改行しないスペース/ハイフン」を使うように指示されているため、使うのが普通かと思っていた。 ]FIG] * [CN[EM DASH]] [61] [[OpenType]] は [[em dash]] と[[打ち消し線]]の太さと位置が一致するべきとしています。 また、[CH[_]] の太さと一致するべきとしています。 [SEE[ [[yStrikeoutSize]] ]] * [CC[U+2015]] [CN[HORIZONTAL BAR]] [63] [CITE@ja[@tomo.chise.orgによる投稿 — Bluesky]], [TIME[2025-12-25T05:17:36.000Z]] >ところで、 なのだが、手元の資料での最古の例は ISO 8859-7:1986 (= ギリシアの国家標準 ELOT 928:1986; ISO-IR-126) [SNIP[]] 「HORIZONTAL BAR (Parenthetiki pavla)」とあってギリシア語における引用符(段落の先頭にある対話文を示すもの cf. greeknote.net/types-of-wor... )だったようだ。 [64] [CITE@ja[@tomo.chise.orgによる投稿 — Bluesky]], [TIME[2025-12-25T05:18:16.000Z]] >[SNIP[]]この引用符はフランス語やロシヤ語でも用いられるもので、フランス語の慣習を取り入れたものらしいが、ISO 8859-1 や ISO 8859-5 には HORIZONTAL BAR はない(「-」 で代用してた?)[SNIP[]] * 竪点 [SEE[ [[竪点]] ]] * メモ [22] [CITE@ja[ハイフン - Wikipedia]] ([TIME[2020-11-20T06:50:26.000Z]], [TIME[2020-11-30T08:43:49.039Z]]) [23] [CITE[年月をつなぐダッシュ(欧文組版の場合)]] ([TIME[2018-10-04T11:48:54.000Z]], [TIME[2021-01-28T03:49:12.451Z]]) [24] [CITE[二分ダーシ - JAGAT]], [TIME[2020-03-27T05:47:34.000Z]], [TIME[2022-09-03T09:41:07.205Z]] [14] [CITE@ja[93651301_01.pdf]], [TIME[2022-08-22T08:37:01.000Z]], [TIME[2024-10-19T07:51:16.587Z]] [FIG(quote)[ [FIGCAPTION[ [1] [CITE@ja[2020年、東京五輪の『サマータイム』は是か非か?(神田敏晶) - 個人 - Yahoo!ニュース]] ([TIME[2018-08-12 13:53:56 +09:00]]) ]FIGCAPTION] > 「ハイフォン(-)」 ]FIG] [2] [[ハイフン付け]] -[5] [CITE@ja[欧文組版のマナー実例: ダーシはハイフンと違う : デザインの現場 小林章の「タイプディレクターの眼」]], [[type_director]], [TIME[2020-12-29T09:23:47.000Z]] - [6] [CITE@ja[欧文組版のマナー実例: ダーシはハイフンと違う(2) : デザインの現場 小林章の「タイプディレクターの眼」]], [[type_director]], [TIME[2020-12-29T09:24:35.000Z]] - [8] [CITE@ja[欧文組版のマナー実例: ダーシはハイフンと違う(3) : デザインの現場 小林章の「タイプディレクターの眼」]], [[type_director]], [TIME[2020-12-29T10:04:32.000Z]] [7] [CITE[92235001_01.pdf]], [TIME[2020-05-14T01:00:03.000Z]], [TIME[2020-12-29T09:55:15.183Z]] [9] [CITE@ja[大学生協の食堂の英語が適当で気になる話 – みんな重力のせい]], [TIME[2023-04-04T06:53:56.000Z]] >[B[ミックススロー]]が載っています。キャベツを中心にニンジンやら玉ねぎやらを刻んだサラダです。上に “[B[MIX SURO-]]" と書いてあり、下には “[B[MIKKUSU SURO-]]" とあります。この投げやり感のある “[B[SURO-]]" がなんとも言えない雰囲気を醸し出しています。 (「上」は英語表記、「下」はローマ字表記) [FIG(short list data)[ [[文字]] :[F[文字]]:[CH[‐]] :[F[関連]]:[CH[対]] :[F[関連]]:[CH[の]] ]FIG] [36] [CITE@ja[輝-Akira- - Wikipedia]] ([TIME[2016-12-21 19:01:12 +09:00]]) [37] [CITE@ja[ats- - Wikipedia]] ([TIME[2016-12-27 14:41:35 +09:00]]) [38] [CITE@ja[AYA -絢- - Wikipedia]] ([TIME[2016-12-24 16:50:19 +09:00]]) [39] [CITE@ja[COSMOS-keyboards trio- - Wikipedia]] ([TIME[2016-12-21 19:06:12 +09:00]]) [40] [CITE@ja[KOBUDO -古武道- - Wikipedia]] ([TIME[2016-12-21 19:06:31 +09:00]]) [41] [CITE[Unicodeにあるハイフン/マイナス/長音符/波線/チルダのコレクション | hydroculのメモ]] ([TIME[2015-06-09 23:15:03 +09:00]] 版) [42] [CITE[4-6月期GDP 年率ー27.8% リーマン後超え 最大の落ち込みに | 新型コロナ 経済影響 | NHKニュース]] ([[日本放送協会]]著, [TIME[2020-08-17 11:39:37 +09:00]]) 1個目の横線は [CODE(charname)@en[HYPHEN-MINUS]]。 2個目の横線は [CODE[U+30FC]] [CODE(charname)@en[KATAKANA-HIRAGANA PROLONGED SOUND MARK]]。 意味的には2個目は [CODE(charname)@en[MINUS SIGN]] でなければならないはずだが... [43] [CITE@en[The confusion between U+2014 and U+2015.]], [[Eric Muller]], [TIME[2011-09-29 08:05:47 +09:00]], [TIME[2020-01-17T22:50:07.000Z]], [TIME[2020-10-31T03:34:21.019Z]] [FIG(quote)[ [FIGCAPTION[ [44] [CITE@en[Template:Zero width joiner em dash zero width non joiner - Wikipedia]] ([TIME[2020-11-20T18:23:30.000Z]], [TIME[2020-11-21T03:16:19.027Z]]) ]FIGCAPTION] > — ]FIG] [45] いろいろな横線をたくさん列挙する記事が数年前にやたらとあちこちで作られているようなのは何なのですかね。 いっぱいあればいいみたいな感じでなんとなくそれっぽければ直線だろうが波線だろうがお構いなしなのは数を増やすためなのか? 使い分けの方法なんかも申し訳程度の説明しかなくていつどれを使うのかわからないような記事ばかり。 [46] みんなどう使い分ければいいのか (そもそも使い分けが必要なのか) わからなくて困るというのはあるのだろうけど、 それらの記事はやたらとあるわりにそうした疑問にろくに答えていないんだよな。 [47] 本当に有用な情報はたくさん列挙する系の記事ではなく少数を取り上げて比較している記事の方にありがち。 [54] ただこの問題はとても複雑なので、 - [48] [[和文組版]]でどうするべきか - [49] [[欧文組版]]でどうするべきか - [50] [[Unicode]] で標準仕様として何が望ましいとされるか - [51] 伝統的な[[情報処理]]の慣習でどう扱われているか - [52] 具体的な[[フォント]]や [[DTP]] ソフト等でどう機能するか - [53] それらの歴史的変遷 といういろいろの事情が込み入っていて、整理して俯瞰しつつ、じゃあ今どうしたらいいのか (一般利用者はどうしたらいいのか? ソフトウェア開発者はこれから何を提供するべきなのか?)、 と提言してくれるような記事があってほしい。 [55] なのに今あるのは - [56] 限られた条件での限定的な状況を述べたもの - [57] なにかのコピペに近い雑なまとめ - [58] 筆者の主観的な願望を真理のように書いたもの - [59] 出典不明の謎情報 のようなばかり... 誰も混乱を収拾しようという意思がないのである。 [62] [CITE@ja-JP[商号の【ー】長音符と【‐】ハイフン - 司法書士なごやか法務事務所]], [TIME[2025-02-26T03:49:22.000Z]]