Schreibweisen-Konverter
Text zwischen camelCase, snake_case, kebab-case, Title Case und mehr umwandeln, mit sprachabhängiger Schreibung und Zeilenwerkzeugen.
Schreibweisen
- UPPERCASE
XMLHTTPREQUEST HANDLER FOR ISTANBUL CITY GUIDE - lowercase
xmlhttprequest handler for istanbul city guide - Title Case
Xmlhttprequest Handler For Istanbul City Guide - Sentence case
Xmlhttprequest handler for istanbul city guide - camelCase
xmlHttpRequestHandlerForIstanbulCityGuide - PascalCase
XmlHttpRequestHandlerForIstanbulCityGuide - snake_case
xml_http_request_handler_for_istanbul_city_guide - kebab-case
xml-http-request-handler-for-istanbul-city-guide - CONSTANT_CASE
XML_HTTP_REQUEST_HANDLER_FOR_ISTANBUL_CITY_GUIDE - dot.case
xml.http.request.handler.for.istanbul.city.guide
Zeilenoperationen
XMLHttpRequest handler for istanbul city guideZeilen: 1
Eine Worttrennung, zehn Schreibweisen
Die Schreibweise eines Textes zu ändern wirkt wie das Einfachste, was ein Programm tun kann, und ist die Quelle erstaunlich vieler echter Fehler. Ein Grund dafür ist, dass „Groß- und Kleinschreibung“ in Wahrheit zwei verschiedene Probleme unter einem Namen sind. Einen Text in UPPERCASE oder lowercase zu bringen ist eine zeichenweise Zuordnung, die Unicode festlegt. Ihn in camelCase oder snake_case zu bringen ist etwas ganz anderes: Zuerst muss entschieden werden, wo die Wörter liegen, und erst danach wird umgeschrieben und wieder zusammengesetzt. Dieses Werkzeug macht beides, zeigt alle Ergebnisse auf einmal und sagt vor allem, welche der Antworten von einer Spracheinstellung abhängen.
Alle sechs Programmiererformen stammen aus derselben Worttrennung, sie können sich also nie widersprechen. Das sind ihre Grenzen:
- Ein Kleinbuchstabe gefolgt von einem Großbuchstaben beginnt ein neues Wort, wodurch aus fooBar die Teile foo und Bar werden.
- Eine Folge von Großbuchstaben endet dort, wo das nächste Wort beginnt, also beim letzten Großbuchstaben vor einem Kleinbuchstaben. XMLHttpRequest ergibt XML, Http und Request; IOError ergibt IO und Error.
- Eine Ziffer gefolgt von einem Großbuchstaben beginnt ein neues Wort, deshalb ergibt html5Parser die Teile html5 und Parser.
- Alles, was weder Buchstabe noch Ziffer noch kombinierendes Zeichen ist, trennt Wörter: Leerzeichen, Unterstriche, Bindestriche, Punkte und Satzzeichen.
Ansonsten bleiben Ziffern an dem Wort hängen, das vor ihnen steht, und deshalb kommen utf8 und address2 unversehrt durch. Das ist eine bewusste Abweichung von lodash, dessen Trenner jede Ziffernfolge als eigenes Wort behandelt und aus utf8 ein utf_8 macht — technisch konsequent, aber nicht das, was jemand beim Benennen einer Variablen gemeint hat.
Die Trennung ist mit Unicode-Eigenschaften geschrieben und nicht mit einer ASCII-Zeichenklasse, sie ist also nicht auf Englisch beschränkt. Ein kyrillischer Bezeichner wird an seinen Schreibungsgrenzen genauso getrennt wie ein lateinischer. Eine Schrift ganz ohne Groß- und Kleinschreibung — Hebräisch, Arabisch, Chinesisch, Japanisch, Koreanisch — hat solche Grenzen nicht, ihre Wörter werden daher nur an Trennzeichen zerlegt, und das ist die richtige Antwort und keine Einschränkung.
Abkürzungen: zwei richtige Antworten
Sobald XMLHttpRequest in XML, Http und Request zerlegt ist, wirft das Zusammensetzen zu PascalCase eine Frage auf, die keine einzige richtige Antwort hat. Schreibt man jedes Wort neu, ergibt sich XmlHttpRequest — das, was lodash liefert und was Googles Java-Styleguide verlangt: eine Abkürzung wie ein gewöhnliches Wort behandeln, damit die Grenzen in Namen wie ParseXmlDocument sichtbar bleiben. Behält man die Folge von Großbuchstaben, ergibt sich XMLHttpRequest — der tatsächliche Name der Browser-API und die Konvention, der ein Großteil des DOM und vieles in .NET folgt.
Beides kommt in echten Codebasen vor, deshalb bietet das Werkzeug beides an und schreibt standardmäßig um. Die Option betrifft nur camelCase und PascalCase — die übrigen Formen schreiben das ganze Wort ohnehin um, sodass XMLHttpRequest in beiden Fällen xml_http_request und XML_HTTP_REQUEST ergibt.
Ein Detail steht fest und ist nicht wählbar: Das erste Wort eines camelCase-Namens wird immer vollständig kleingeschrieben, auch wenn es eine Abkürzung ist. Es zu behalten ergäbe PascalCase, es halb zu behalten ergäbe xMLHttpRequest — eine Form, die kein Styleguide empfiehlt und über die jeder Leser stolpert. Deshalb ergibt XMLHttpRequest so oder so xmlHttpRequest, während parseXMLDocument seine Abkürzung in der Mitte behält, wenn man es verlangt.
Das türkische i und warum die Sprache eine Wahl ist
JavaScript hat zwei Methoden für Großschreibung, und der Unterschied zwischen ihnen hat Produktivsysteme zu Fall gebracht. Die Methode toUpperCase wendet die sprachunabhängige Unicode-Zuordnung an: Aus dem Buchstaben i wird I. Die Methode toLocaleUpperCase wendet die Regeln einer bestimmten Sprache an, und im Türkischen und Aserbaidschanischen ist der Großbuchstabe zu i das gepunktete İ, weil diese Alphabete zusätzlich ein punktloses ı enthalten, dessen Großbuchstabe I ist. Schreiben Sie die Eingabe eines türkischen Nutzers mit dessen Sprache groß und vergleichen Sie sie mit einem Protokollschlüsselwort — der Vergleich scheitert an einem Zeichen, das fast gleich aussieht.
Das ist der häufigste Internationalisierungsfehler bei der Zeichenkettenverarbeitung, und er bleibt unsichtbar, bis er einem selbst passiert. Deshalb rät dieses Werkzeug nie. Sein Standard ist die sprachunabhängige Zuordnung — genau die, die Bezeichner, Protokoll-Token, HTTP-Header und Datenbankschlüssel brauchen. Die Wahl einer Sprache schaltet auf deren Regeln um, und sobald diese Wahl ein Ergebnis verändert, zeigt das Werkzeug die sprachunabhängige Antwort daneben, damit sichtbar wird, was die Sprache genau getan hat.
'i'.toUpperCase() // 'I'
'i'.toLocaleUpperCase('tr') // 'İ' dotted capital
'I'.toLocaleLowerCase('tr') // 'ı' dotless lowercase
'ISTANBUL'.toLocaleLowerCase('tr') // 'ıstanbul'Drei weitere Sprachen ändern die Antwort, und das Werkzeug bietet sie alle an. Das Litauische behält den Punkt über dem i, wenn ein Großbuchstabe mit einem weiteren Akzent kleingeschrieben wird: Aus Ì wird ein i, gefolgt von einem kombinierenden Punkt und einem kombinierenden Gravis, und nicht das einzelne vorgefertigte ì. Das Griechische lässt beim Großschreiben den Tonos weg, sodass άνθρωπος zu ΑΝΘΡΩΠΟΣ wird und nicht zu ΆΝΘΡΩΠΟΣ, denn im Griechischen wird der Akzent auf Großbuchstaben nicht geschrieben. Das Aserbaidschanische teilt mit dem Türkischen das i mit und ohne Punkt.
Zwei berühmte Fälle sind keine Sprachregeln, und es lohnt sich zu wissen, welcher welcher ist. Das deutsche ß wird in jeder Sprache zu SS, weil das eine SpecialCasing-Regel von Unicode ist und keine deutsche — deshalb ist die Zuordnung auch nicht umkehrbar, und SS wird wieder zu ss. Und ein griechisches Sigma am Wortende wird überall zur Endform ς statt σ: Das ist eine kontextabhängige Bedingung zur Position des Zeichens, keine Spracheinstellung. Beides ist in diesem Werkzeug schon ohne jede Sprachwahl zu sehen.
Title case und Sentence case sind hier mechanisch
Title Case schreibt in diesem Werkzeug den ersten Buchstaben jedes Wortes groß und den Rest klein. Sentence case schreibt den ersten Buchstaben des Textes und jedes folgenden Satzes groß, wobei ein Satz an einem Punkt, Ausrufezeichen, Fragezeichen oder Auslassungspunkten endet, auf die ein Leerzeichen folgt. Beide setzen die Eingabe zuerst in Kleinbuchstaben, und genau das macht sie bei Text nützlich, der IN GROSSBUCHSTABEN ankam.
Das sind absichtlich mechanische Regeln, und die Alternative verdient eine Erklärung. Die englischen Styleguides definieren die Titelschreibung darüber, welche kurzen Wörter klein bleiben — und sie widersprechen einander bei der Liste, bei der Frage, ob das Wort nach einem Doppelpunkt großgeschrieben wird, und bei Präpositionen ab vier Buchstaben. Eine davon hier anzuwenden hieße, amerikanische Zeitungskonventionen an Leser auszuliefern, die auf Hebräisch, Japanisch oder Türkisch schreiben, wo sich der Begriff überhaupt nicht überträgt. Jedes Wort großzuschreiben ist vorhersehbar, in jeder Sprache erklärbar und anschließend leicht von Hand anzupassen.
Die Leerzeichenbedingung im Sentence case verhindert, dass aus 3.5 metres ein 3.5 Metres wird, denn dort folgt auf den Punkt eine Ziffer. Abkürzungen löst sie nicht: e.g. this beginnt weiterhin einen falschen Satz, denn zu wissen, dass „e.g.“ kein Satzende ist, setzt eine Liste der Abkürzungen dieser Sprache voraus. Auch ein Apostroph innerhalb eines Wortes beginnt kein neues, deshalb wird it's einmal großgeschrieben und ergibt It's und nicht It'S.
Sortieren: alphabetische Ordnung oder Byte-Ordnung
Die Zeilenwerkzeuge kürzen, entfernen Duplikate, sortieren, kehren um und nummerieren, und das Sortieren wirft die Sprachfrage ein zweites Mal auf. Die alphabetische Ordnung ist eine Eigenschaft einer Sprache, nicht von Unicode. Das Deutsche stellt ä neben a: a, ä, z. Das Schwedische behandelt es als eigenen Buchstaben am Alphabetende: a, z, ä. Beides ist im jeweiligen Land richtig, und das Werkzeug verwendet die Sprache, die oben auf der Seite gewählt wurde.
Die andere Möglichkeit ist die Codepunkt-Ordnung, und die will man, wenn das Ergebnis zu etwas anderem passen muss. Ein Vergleich nach Codepunkt ist die Byte-Ordnung in UTF-8 und gibt daher genau das wieder, was LC_ALL=C sort, git und der Standard-Zeichenkettenvergleich der meisten Programmiersprachen liefern: alle Großbuchstaben vor allen Kleinbuchstaben, sodass B vor a steht. Wählen Sie sie, wenn Sie mit der Ausgabe eines Werkzeugs abgleichen; wählen Sie die sprachliche Sortierung, wenn ein Mensch die Liste lesen wird.
Die natürliche Zahlenreihenfolge — item2 vor item10 statt danach — ist eine Funktion der sprachlichen Sortierung und daher nur mit der alphabetischen Regel verfügbar. Die Byte-Ordnung kennt keinen Begriff einer Zahl innerhalb einer Zeichenkette, und die Sortierung, die sie nachbildet, kennt ihn ebenso wenig; beides zusammen anzubieten hieße, etwas zu versprechen, was die Ausgabe nicht halten kann.
Die Operationen laufen in einer festen Reihenfolge, und die Reihenfolge ist wichtig. Das Kürzen geschieht vor dem Entfernen von Duplikaten, sodass zwei Zeilen, die sich nur durch ein Leerzeichen am Ende unterschieden, als dieselbe erkannt werden. Das Sortieren geschieht vor dem Umkehren, sodass Umkehren immer heißt „kehre um, was ich gerade sehe“. Sowohl die Zahl der leeren Zeilen als auch die der entfernten Duplikate wird gemeldet, denn ein stilles Zählen ist genau der Weg, auf dem man nicht bemerkt, dass die Liste nicht war, was man dachte.
Wo das läuft
Alles geschieht in Ihrem Browser. Die Schreibungszuordnungen stammen aus der Unicode-Implementierung der JavaScript-Engine selbst und die Sortierung aus Intl.Collator, sodass die Antworten mit der Laufzeitumgebung übereinstimmen, die Ihre Zeichenketten tatsächlich verarbeiten wird, und nicht mit einer vor Jahren abgeschriebenen Tabelle. Nichts von dem, was Sie einfügen, wird hochgeladen, gespeichert oder protokolliert, was das Werkzeug für Namen, Logzeilen und alles andere sicher macht, das Sie nicht an einen Server schicken möchten, nur um seine Schreibweise zu ändern.
Häufig gestellte Fragen
- Wird mein Text an einen Server gesendet?
- Nein. Jede Umwandlung läuft in Ihrem Browser mit den Unicode-Schreibungszuordnungen der JavaScript-Engine selbst, und nichts von dem, was Sie einfügen, wird hochgeladen oder protokolliert.
- Warum zeigt mir die Auswahl von Türkisch zwei verschiedene Ergebnisse?
- Weil Türkisch die Antwort ändert. Sein Alphabet hat sowohl ein i mit Punkt als auch ein ı ohne, deshalb ist der Großbuchstabe zu i das İ und nicht I. Sobald eine Sprache ein Ergebnis ändert, zeigt das Werkzeug die sprachunabhängige Antwort daneben, denn die brauchen Bezeichner und Protokoll-Token.
- Soll ich die sprachunabhängige Zuordnung oder eine Sprachzuordnung verwenden?
- Verwenden Sie die sprachunabhängige Zuordnung für alles, was eine Maschine liest: Bezeichner, HTTP-Header, Datenbankschlüssel, Protokoll-Token, Dateinamen. Verwenden Sie eine Sprachzuordnung für Text, den ein Mensch in dieser Sprache liest. Beides zu verwechseln ist der klassische Fehler mit dem türkischen i.
- Warum wird XMLHttpRequest zu XmlHttpRequest?
- Weil Abkürzungen standardmäßig umgeschrieben werden, so wie lodash und mehrere große Styleguides es tun. Schalten Sie die Abkürzungsoption ein, um die Folge von Großbuchstaben zu behalten und XMLHttpRequest zurückzubekommen. Sie betrifft nur camelCase und PascalCase, da die übrigen Formen ohnehin jedes Wort umschreiben.
- Warum bleibt utf8 ein Wort, während lodash es trennt?
- Weil Ziffern hier an dem Wort hängen bleiben, das vor ihnen steht, sodass utf8 und address2 unversehrt durchkommen. Eine Ziffer gefolgt von einem Großbuchstaben beginnt sehr wohl ein neues Wort, und genau das trennt html5Parser in html5 und Parser.
- Warum schreibt Title Case auch kurze Wörter wie „of“ und „the“ groß?
- Weil die Regel bewusst mechanisch ist. Die englischen Styleguides widersprechen einander darin, welche kurzen Wörter klein bleiben, und ihre Konventionen übertragen sich nicht auf die übrigen Sprachen dieser Website. Jedes Wort großzuschreiben ist vorhersehbar und leicht von Hand anzupassen.
- Warum kann ich die natürliche Zahlenreihenfolge nicht mit der Codepunkt-Sortierung nutzen?
- Die natürliche Reihenfolge ist eine Funktion der sprachlichen Sortierung. Die Codepunkt-Ordnung ist eine Byte-Ordnung ohne jeden Begriff einer Zahl innerhalb einer Zeichenkette — und das LC_ALL=C sort, das sie nachbildet, hat ihn ebenso wenig. Beides anzubieten ergäbe eine Ausgabe, die nicht mehr zu dem nachgebildeten Werkzeug passt.
- Warum wird ß auch ohne gewählte Sprache zu SS?
- Weil diese Zuordnung eine SpecialCasing-Regel von Unicode ist und keine Regel des Deutschen, sie gilt also überall. Umkehrbar ist sie ebenfalls nicht: SS wird zu ss und nicht zurück zu ß. Das griechische Schluss-Sigma funktioniert genauso — es hängt von der Position des Buchstabens ab, nicht von einer Sprache.