Java Stringverarbeitung

Bei Java bin ich mir gerade nicht sicher, wie man das man besten angeht. 
In JS könnte man das hier machen: "Haaaaallo 
Juliaan".replace(/(.)\1*/g,x=>x[0]) Oder das hier: [..."Haaaaallo 
Juliaan"].reduce((a,b)=>a[a.length-1]==b?a:a+b)

In Java kenne ich keine schöne variante. Man könnte eventuell sowas 
machen:

1

#!java

2

class MyUtils {

3

  public static String dedupeString(String str){

4

    if(str == null)

5

      return null;

6

    if(str == "")

7

      return "";

8

    char[] chars = str.toCharArray();

9

    char last = chars[0];

10

    String result = last+"";

11

    for(int i=1,n=chars.length; i<n; i++)

12

      if(last != chars[i])

13

        result += last = chars[i];

14

    return result;

15

  }

16

}

Vermutlich funktioniert das aber alles bei längeren unicode Zeichen 
nicht mehr richtig.

Interessant wäre jetzt als test case "🐧🐧". Schlägt sicher überall fehl.

DPA schrieb:
> Interessant wäre jetzt als test case "🐧🐧". Schlägt sicher
> überall fehl.

Java kann UTF-8.

Gerade ausprobiert. Mit dem Regex (wenn man . stat \\w nimmt), geht 
tatsächlich auch "🐧🐧" in java. Wobei sowas "👨‍👩‍👧‍👦👨‍👩‍👧‍👦" würde auch 
wieder nicht mehr funktionieren.

Die JavaScript Varianten kommen mit beidem nicht klar. Eine variante, 
die bei JS geht, wäre: 
[..."🐧🐧"].reduce((a,b)=>a[a.length-1]==b?a:[...a,b],[]).join('')

Auch die geht aber bei "👨‍👩‍👧‍👦👨‍👩‍👧‍👦" nicht mehr. Liegt aber zwar eher 
daran, dass es sehr kompliziert und manchmal unklar ist, wann in unicode 
etwas ein glyph ist, und wann nicht.

🐧 DPA 🐧 schrieb:

Berichtige:
Sourcecode ist UTF-8 obwohl man das per -D Schalter iirc ändern kann.

Strings sind sogar UTF-16:
https://docs.oracle.com/javase/10/docs/api/java/lang/Character.html#unicode


https://stackoverflow.com/questions/5729806/encode-string-to-utf-8

88
In Java7 you can use:

1

import static java.nio.charset.StandardCharsets.*;

2

3

byte[] ptext = myString.getBytes(ISO_8859_1); 

4

String value = new String(ptext, UTF_8);

This has the advantage over getBytes(String) that it does not declare 
throws UnsupportedEncodingException.

If you're using an older Java version you can declare the charset 
constants yourself:

1

import java.nio.charset.Charset;

2

3

public class StandardCharsets {

4

    public static final Charset ISO_8859_1 = Charset.forName("ISO-8859-1");

5

    public static final Charset UTF_8 = Charset.forName("UTF-8");

6

    //....

7

}

Markus L. schrieb:
>  Unicode in Java hat eine fixe Länge.
Wenn nur Zeichen vorhanden sind die alle in eine 1-byte Zeichensatz 
passen, dann wird der intern verwendet, das passiert dynamisch.

http://tutorials.jenkov.com/java/strings.html#internal-string-representation

Das Problem beim Java sind die "Unicode planes".

Ursprünglich gab es nur 2^16 Unicode Zeichen. Später kamen die 
Supplementary Planes dazu.

Das Java benutzt 16 Bit für char. Als Unicode die zusätzlichen Planes 
definierte, ist Java bei 16 Bit geblieben. Die zusätzlichen Zeichen 
brauchen im String 2 char.

Wenn man die neuen Planes benutzen will, muss man auch die neuen Java 
Methoden benutzen.
char charAt(int index)
int codePointAt(int index)

War lange kein Problem. Aber jetzt hat Unicode die Emjos in eine 
Supplementary Plane gepackt. U+1F600 ...

Da sieht man wieder was für Krampf non-ASCII ist. Unicide, UTF sollte 
das mal alles lösen jetzt hat man wieder zig Varianten davon, nix 
funktioniert wie man es wollte, man muss erst wieder herumraten was das 
sein könnte wenn man nicht sicher weiss was rein kommt, ist das alles 
ein Schrott.

> nix funktioniert wie man es wollte

Na ja, besser wäre gewesen, Unicode hätte von Anfang an mehr als 2^16 
Zeichen vorgesehen.

Aber der Krampf, den das Java für die Rückwärtskompatibilität betreibt, 
funktioniert erstaunlich gut.

Solange man nur String benutzt, machen die mitgelieferten Libraries 
alles richtig. Nur wenn du String.toCharArray() oder String.charAt() 
aufruft, musst du dran denken, ein Zeichen kann 1 oder 2 char haben.

Hatten mal einen Bugreport, Emjos funktionieren nicht. Da stellte sich 
heraus, unser Programm und alle Libraries machten alles richtig, nur die 
Mysql hatte als Default ein Encoding, in dem die neuen Planes nicht 
funktionierten.